Crash when launching a new game (with 32 native executor threads)

Bug Reports
1

when i launch a new game this error log appears:

2

Thanks for the report. This is the first time Iā€™m seeing:

ERROR: [NATIVE] Task system stuck trying to add new jobs to the queue
ERROR: [NATIVE] Task system stuck trying to add new jobs to the queue
ERROR: [NATIVE] Task system stuck trying to add new jobs to the queue

Iā€™ll need to investigate next week where that error print can even come from and if I can add more error checking to catch whatever the error condition is before that.

Did you get to the main menu at least? When you said ā€œwhen I launch a new gameā€ I assume the error happens after youā€™ve selected the new game settings and click start to start a new game.

3

yes, there is no problem for the title screen, but after launching a new game,the game freeze just after the loading screen

1 Like
4

Thatā€™s pretty expected. The native library is used to run all of the game physics, so it being stuck not being able to enqueue any of the physics processing jobs means the game cannot progress at all. Iā€™ll need to investigate what potential problem there might be. If you manually configure the number of native background executor threads in the Thrive performance options (to maybe 1, or if it is currently 1 then 2) that has a chance to do something about this problem.

5

it worked! I had setted up the ā€œnative side executor threadā€ to 32 before, and when i set them up to 16 it works

1 Like
6

Thatā€™s very useful information. I probably have never tried that myself so thereā€™s very likely a bug where the native side task system will just completely topple over when attempting to use 32 threads. Iā€™ll see if I can find the root cause for the lock up but if not Iā€™ll just prevent increasing the native threads above 16 or so.

Iā€™ll note as well that from my experiments it seems like performance actually decreases after native thread count is over 8.

2 Likes
7

Having more threads than hardware threads tends to have no increase/a small decrease in performance (edit: this does not apply in the slightest to non-cpu bound applications, and many well designed implementations of threadpools donā€™t exhibit this problem at all, I think .NET just pretends every CPU has 250 threads and it works fine, so this is far from a rule but it makes sense in this scenario), so 32 threads is a terrible choice for anyone who doesnā€™t have a few Xeons in their PC or somehow compiled Thrive for an ultraSPARC. I donā€™t see why having too many would crash it but honestly I have no clue about a lot of stuff including thrive source code (which I should fix some time, I could totally do bug fixes or somethibg now that I know assorted C-like languages.).

I also think I once set the to threads to 16 on my laptop with 8 hardware threads but this was I while ago. Interesting bug.

8

Turns out the fix seems pretty simple. I got the same problem when I set my native threads up to 32. And when looking for the problem I found this:

kuva
kuva893Ɨ55 7.83 KB

Removing that divide by two fixes the problem by making the task queue big enough to fit all of the tasks that 32 threads want to submit at once. And should hopefully take care of the issue permanently, at least I think so and until someone with a 64 thread CPU shows up.

Also running with 32 native threads compared to 8 is just a waste of performance. I just got some new benchmark numbers and the speed penalty wasnā€™t as bad as I remembered but still 8 threads (though it was much closer than I remembered) performs better or the same in the benchmark.

1 Like