Refactoring joints

[d.l.i.w]

I just happened to come by and tried it out. I assume you are talking about the articulated joints demo?

On Linux with release settings for the latest revision I get:
gcc 4.8.5: 1.7 - 2.0ms
gcc 7.3.0: 1.9 - 2.0ms

CPU: Intel i7, 3.3GHz, 8 core

Debug crashes with assertion

Code: Select all

sdkDemos/DemoEntityManager.cpp:308: DemoEntityManager::DemoEntityManager(): Assertion `0' failed

[Julio Jerez]

Ha excellent, 2 nd can be used as the bench mark to measure how much better it will be when the solver is multithreaded.
I predict some gain, but the point is that the performance will gain stability.
For example the cost per model goes down, but a single model will have that dis cost.
It would be nice if the cost was less, but that's a futile effort. Better to put the effort in using the hardware resources.

[Julio Jerez]

Ok I now added the hexapod again using the new joint system

I only the hinge so far, by that one is sufficient to recreate all the demos.

when I walk around and start manipulation the creature around, it actually scare me, I fipple around an the leg got out of the circle and the move as if the creature was actually alive.

I Only nee to add a other control se the different speed between leg and right and left leg so that if can turn, or I can make a turn animation that can be blended, almost anything is possible with this system.

Before moving on to make the biped I will finish all the other demos that I have commend out so that I can re upload a Newton 3.14a stable release.

[Julio Jerez]

Ok I now added a more fair representation for a typical vehicle, and
box with 4 tire, controlled by joint and few joint to control some mechanism, it has 12 joints in total
and I am getting
VS 2015: 0.08 - 0.15ms

On Window I7 4820z 3.7 Gz release :

This is a relatively powerful machine, so I do not expect something around 0.2 ms on some of the main stream system.
The vehicle do not do anything yet because is all glued with actuators joints so they act like fix joints or a compound collision.

[Sweenie]

For the latest Forklift scene I get about 0.015 - 0.020ms on AMD Ryzen 5 1600 (6-core) 3.2GHz

Oddly enough if I increase the worker threads to 4 or more I get 0.300ms.
Why is that? Is it thread synchronization overhead?

[JoeJ]

Forklift:
0.02ms
0.01ms with 4 threads

old i7 930 @ 2.8 GHz

Can't find the box car demo(?)

Oddly enough if I increase the worker threads to 4 or more I get 0.300ms.
Why is that? Is it thread synchronization overhead?

I wish they would release an optimization guide... all we have is rumors

[Julio Jerez]

I too has seen that with multithread, The only thing that I can attribute to is that naïve support for thread is C++ use defaults with high overhead for task switch.

I have seen few projects an people who also are of the same opinion and I though is was a superstition but now I think is true.
We still have the pthread source floating in some older version, after we are done with the the code update we should try adding as an optional alternative.

Pthread uses the native window interface, so it has access to many more tuning functionality like for example, when I was using threads the worker thread were set to a current plus one priority, so they execute without interruption from any lower of equal thread, C++ 11 threads do not have that all threads are equal priority which I think is part of the problem.

Anyway let us not worry about thread for now and complete all the demos.

[JoeJ]

I assume the problem is slower communication between CPU modules.
Further i assume Intel will do it this way too in the future: better yields, more flexibility.
In the worst case fine grained sync is not future proof, and we should use large independent workloads instead (which of course is not always possible, but would be good to know.)
This would explain Ryzens better application performance, because applications mostly do this already.

[Julio Jerez]

I agree, even if pThread could be better, in the long run at some point windows native support will be cut, and even pthread will have to use the high lever support.
This is a price will just simple have to pay,

In fact basically, we were getting more performance in window because a loophole that only widow allow, which is that thread task switching has a low cost between applications and high cost among different apps, that no allow in OSX and Linux, so multithread is always slower.
the answer is that thread soudl have high low like you say Joe.

I am guessing someday they will fix that, but I beleive is a mistake goidn back to pthread, onless thsi prove to be unbearble.

also joe, the are no car yet that will start next week, what I said is that the forklift has the complexity of a regular four wheel vehicle. so whe can use as a measure stick for performance of vehicles.

[Julio Jerez]

I almost completed the fork lift demo, only one thing pending, the engine motor I copied and pasted from th articulation demo and is using the worn axis to connect to the tires, once that done and the power is tuned, that will be all for that demo.

I have to decide were to go next, it could be one of three things.
-the high performance vehicle
-the self balance character
-the parallel solver.

I see most people her have high core count systems.
My system is 4 core, 8 threads.
I am tenting to get a new ryzen with 16 cores, and make my current system a linux box.

Newton is footing point limited, so in theory and core will run slower, however in practice I am yet to see a difference that is worth the price difference.

Plus what I have plans for the parallel solver it will benefit more from more cores than form faster cores.

The parallel solver will be set to run in many many thread like 4 time the number of cores or more.
Not like it is now that more thread do not necessarily yield better performance.
The penalty for this is that the convergence will not be as good as the single island per thread, so it will need more passes, hence it will need twice as many cores to make up for the poor convergence.

My estimation is that given an island of any size, the parallel solver will need two cores to break even with the single core per island solver. But we are now in the era of more cores, and other is not going back.

[JoeJ]

My estimation is that given an island of any size, the parallel solver will need two cores to break even with the single core per island solver. But we are now in the era of more cores, and other is not going back.

http://store.steampowered.com/hwsurvey

According to this the average user core count is 3.
But even if we have many cores, we would still probably be faster using the current solver if we have enough other work async along physics.
E.g. we use 2 cores for physics, which you say is as fast as parallel solver would be with 4 cores?
This means we get 2 cores for free by not using the parallel solver, and can use those for graphics, AI or whatever?

If i get this right i would keep the parallel solver on the bottom of todo list for a long time
(You should keep both options for an even longer time probably, so maintaining more stuff...)

[Julio Jerez]

Yes those points are right when dealing with a small number of cores, once you get 8, 10, 16, ... Plus hyper treading, it is a different game.
For example a ps4 has 8 cores, and developers has a hard time keeping the busy, most games 100% run in one or two cores, and the rest are used from 5 to 10% by third party libraries.

one core out of three, is a huge % of the system, but 1 core out 8 is not that mich and the core count is only getting bigger.
There is a second benefit, and this is that more cores stabilize the performance, it act as the inertial of the system.
But in any case, the current system will not change, unless the new is so much better that it will render the old opsolite, which it wouldn't but that the theory.

[Julio Jerez]

ok guys one final test.

I completed the two robots made with servo joints, gear joints, motor, and all the basic joints.
I believe these two demo cover almost completee range of joints. wi the expection of the very spcialized ones like the Inverse dinamic and some other.

one is a typical articaulte objcet that any game can use, and the other is ridiculous complex.
I could not find a set of parame to make the trhed vehicle go to sleep, but I am no too worry about that.

some day later afte all teh oteh stuff is more complete I can come back and do tow things.
Made the gipper 6dof instead of tow liek is is now, and see if I cna set the joints link more relax.
also see how I can prevent the wood slab for getting beteen the tread and the wheels.

so if you play the demo and thsi happens do no panic you will see a huge force or even an explosion but that is not the point of the demos. the point is that teh emgine can be use for no real time acurate and complex simulation, is we simulate at 250 or even 1000 fps like all the robot simulation application that do not use newton do, this will be far better. because our will be near perfect while theirs is not even close to what we do in real time at 60 or 120 fps.
If funny those packages has come up wither another pseudo theology turn, "Real time scale"
whatever very that means, but you never hear the mention that small problem.

Also at that rate the collision system get far better an can preven the slaps from getting into the tracks, and also in real life if that happens and the slab is not crushed, then the thread will most likely break.

In another vain, is is quite cool to see how the vehicle is now so reponsive when driving over the pile of rubber, no like before that was strugging no matter hwo much power was applied.

ok now on to the next task.

[Julio Jerez]

one thing that we already see, is how difficult is to orient the gripper, each time we set and orientation is actually use less, what is need it, is a small script tha calculate that given teh orientation, calculate the gripper parameter to keep it as mush as is can. kind of liek a on bone OK rotations.

I am no sue if real lifter vehicle has that functionality. that will sure it make look nicer.
It will try that later tonight.

[Julio Jerez]

I could not resist to try yet another gyro test called phitop
https://www.youtube.com/watch?v=1Tx7FgZuV3U

It is amassing hwo is can be reproduce bu the book, notice how teh start fast and as the rise they a little of angular velocity, by then thank to her explanation this is not a bug is actually conservation of energy, and the top rises it gain potential energy because there center of mass goes up, so teh onel way to get thet energy from is from the angular keneti energy, why will make the object slow down.

The secund reason that slo down is that as it rises it chnge its from an axis with lowes inerta to teh axis with large inretia, so angula velocity soul goes down to make constant.
Thes physics stuff make thing that people will see as a bug very perculiar and interesting.

but once you see it an undertand it, this the intutive way no longer makes sence.

I could not recreate the tiptop one, I made with a ball and a small cylinder, but that does not do it,
The trick of the type top is that is hollow, so the inertia is concentrate on the surface, and the small pin make a large influence, a solid sphere the pin has almost not effect and it aligns sideways, later
I will see if I can model the hollow inertia, which can no be done easy with the compound but can be done from the elements. Tha was we will recreate all edge cases.
I always wnat to simulate these stuff.