Entire program gets extremely slow

[pHySiQuE]

I've never seen anything like what I am experiencing right now. An extra call to NewtonCreate() results in my entire program running extremely slow, like 20 seconds to execute something that should be pretty much instant, and my whole machine stops responding until it's done. It's not crashing right away, though, just going extremely slow, and all I have to do is add an extra call to NewtonCreate() to trigger an otherwise normal program to do this.

I can't find any logic or reason to this, and have never seen anything like this before. Maybe there is some kind of debugger built into Newton that is timing out? Any ideas?

[JernejL]

This isn't a very good bug report, you didn't even mention which newton library you used and what kind of scene it was..

[pHySiQuE]

Sorry, but your guess is as good as mine. I thought maybe my description would remind Julio of something strange he implemented, if it exists? I'm just including the 300 source and building it.

I'm not even getting to the program loop, just my loading code gets extremely slow...yet it still prints out values showing it is progressing. Never seen anything like this.

If I remove the extra call to NewtonCreate(), everything runs fine.

[Julio Jerez]

what do you mean and extra call to newton create?

[Julio Jerez]

It may be because now newton 300 can run concurrent with tah main thread.
I was experimenting with priorities,

I put the define into a seprate file, get lates version and in file
..\coreLibrary_300\source\core\dgWorkerThread.h

uncoment this define,
//#define DG_USE_NORMAL_PRIORITY_THREAD

If you are haviong a crash and it diuffcult to debug you cna uncmnnet this define
//#define DG_SOFTWARE_THREAD_EMULATION

and it will run the thread engine by emulation in the mai thread, this will let you trace that crash in the engine

[pHySiQuE]

uncoment this define,
//#define DG_USE_NORMAL_PRIORITY_THREAD

This fixed the problem. Even before ever calling NewtonUpdate, the entire program was executing at an extremely slow rate. Adding that define eliminated the problem. My CPU in this machine is a dual-core.

[Julio Jerez]

That is what I thought, some how balancing teh thread is difficult with the differnet hardware.
Ii wll take that out and instead make an option.

Tell me something does the SDK deme runs ok or it is very slow as well.

[pHySiQuE]

The executable newtonDemos.exe runs fine, but sometimes stops responding and crashes when I change the demo.

[Julio Jerez]

Oh how interesting. The demo use the micro thread set to high priority.
Basically the technique I am using is a large number of micro thread all doing small amount of work.
And resolving thread contention but letting then switching for another high priority thread.
I work well on quad core with share cache, but not so much on dual cores.
I will change the strategy.
The problem is that when you set a number of threads to be high priority if you do no yield, the application locks because window will not let any other thread to run unless .

In widow this can be perfectly handle by using WaitForSingleObject and a Semaphore which actually suspend the thread, but I did not want to use that because that function is a windows only thing,
Other Os do not have that functionality.
I will special case it for windows like I did for the micro thread system.

This important because if the micro thread system does no run a higher priority then each time it yield than any other OS function take it turn.


The demo will freeze yes beacuse I am debug the parallel solver. That is not the point the point is that the this parallel solve will generate the same solution than the not parallel as opposed to the parallel solve in core 200 that was using a read black coloring of the joint graph to create batch of joint than can be issue in parallel.
Coloring the grap of a matrix is a technique that is frequency use to solve Gauss Siedle and Jacoby system.
However they has a extreme nasty effect that reduce the convergence rat eto the worse possible.
I notice that in core 200 when the parallel solver produces a jittrering solution.

Basically red black coloring is elegant but is * sine it trun a Gauss Seidel converge rate into an almost Jacoby converge rate. The Newton solve organized the Graph to maximize the convergence rate in each step, so coloring is no acceptable.

This new version actually solves the converge rate problem and generate result as accurate as the no parallel solve, but it required the solution of thread contention.

The version in SVN now is no ready yet, to get I running I added an Critical section, but after I finish it then the it will a function that will iterate over the joint list an sort the in a way that will minimize classhes the collision of joints, the effect si lest thread contentions.

Anyway tonight I will add the semaphore to the engine thread instead of the Sleep(0) that will resolve the slow down issue on single and dual core systems.