Newton4 freezing again

[Bird]

Hi Julio,

I'm hitting some problem with Newton4 freezing up when stress testing with stacks of lots of instances. In this video, there's 12,000 instances. If I start with 24,000 instances, Newton doesn't run at all as the ndBodyNotify never gets called. This is an intermittent problem. Sometimes the simulation completes and sometimes it freezes. https://youtu.be/u-4DZAAcP2o

Intel(R) Core(TM) i9-12900KF 3.20 GHz with 16 cores
RAM 64.0 GB
Windows 11 pro
NVIDIA Geforce RTX 3090 with 24 GB

I tried to reproduce in a Newton test but could not find any problem. I made a pull request for the new test in case you want to add it to the existing tests

[Julio Jerez]

ok I merged the request.
I see the demo, only use 1000.0 instances.

plus use default setting, which mean only one thread.

is there anything I should do to repro what you are seeng?

[Julio Jerez]

ok, I was looking that the demo.
I see you make one body, then repeat it a number of times in a tall stack.

the setting in the demos say 1000 time, and the step in 2.0 meters separation.
that will make the last object 2 km high.

but you say you are setting the count at 12000, and that seem to pass, but when you set it to 24,000
you get a hung in the sdk. Am I getting it correct?

I added the new test to cmake, and committed.
thank for the new test, it is really cool the community is making these tests without me.
lot of thanks goes to user Oliver Nagy who set it all up.

[Bird]

D'uh! Sorry this turned out to be my bug. I have a class similar to the ndPhysicsWorld but was passing in a continuously increasing value for the timestep for the AdvanceTime() call and that was preventing Update to be called at some points, which I thought was Newton freezing. I can't believe how long it took me to notice this bug!

All works well now, even with 32,000 cows

Yes, the tests are very helpful. He did a great job of making them as simple as possible.

I sent the instance count to 1000 in the test I submitted because if I set it much higher then the EXPECT_NEAR test would fail. I'm not sure why that is happening.

In my own test I could make 100,000 bunny instances using 16 threads without any problems.

[Julio Jerez]

In my own test I could make 100,000 bunny instances using 16 threads without any problems.

hikes,
on the cores, the engine is set up so that it only uses no more than have the hardware Theard in the systems. so in you case it will be using 12 cores I guess.
I found that when maximizing the tread just for one task, on average you get bad diminishing return,
and I think the reason is that since the tread a very balanced,
all eh tread are doing more or less the same amount of work,
so when one tread finishes it task, it has to wait idle for the rest to complete.
the effect of this is that it is the slower thread that determine the speed of the engine.

so if a program assign all as many or more thread as there are cores in the system, you get the effect that the OS preempt at random some tread almost every tick, and since all thread are expected to complete it task, is one slow down, all the other also slow down by the same amount.
so it is good to leave thread to the OS and the rest of that app to do thier work.

I sent the instance count to 1000 in the test I submitted because if I set it much higher then the EXPECT_NEAR test would fail. I'm not sure why that is happening.

yes that's something that has been in my sight for some time.

the problem is that when the engine Detert free falling bodies, it takes a shortcut and using teh same old simplicity integrator instead of the RK4.
I am going to fix that issue tonight. It has been bothering me for some time.