[Linux kernel 3.16.7] Performances [Spring 104.0.1-287] ]

Greetings !!

I read a lot of posts concerning the poor performances concerning some of the campaign maps... this even if we had
an 8core computer with a quite good GPU.

For me I use a AMD FX-8370E running at 3300MHz and a R7-370MX.

I was surprised about the fact the computer was blowing once any maps where started... I took the time to monitor the system
and realized that Spring was a simple "process" that uses 137% of the processor, each core was set to 100% one by one.

I take a tour on the different forums and I learned that Spring was 15 years old and seemly that wasn't enough features to hold
a multithreaded environnement. As far as I know to reduce the weight of a process, principaly concerning loops, in single or multi threading programming, you "just" need a little nanosleep of 10 ms, and your core start from 100% to less than 10 once the scheduler
took the relay... depending on the way you are programming and the quality of the langage you use to devellop.

As I have not yet learned the way spring works, I downloaded the source code yesterday, I decided to find a way to obtain a better
behaviour of the computer when playing Zero-K under Linux environment.

Changing the priority of the process seems to give more FPS but I didn't tested with very complicated "maps" in the campaign.
I set the scheduler to be CFQ/NOOP (not yet tested with deadline) with a priority close to RT, the fan is still blowing like crazy
because one core at least is set to 100% but I got FPS near 40 at minimum in all the "maps" I tested from little to middle.

I'll keep you in touch concerning the "big maps" in coop style where the performances where diving quick (less than 24 FPS).

This is the script I used to obtain better performances with graphical settings set to LOW.

launchGame()
{
mono --desktop --optimize=all Zero-K.exe & renice -n -20 -p $(pgrep mono)
sleep 35
renice -n -20 -p $(pgrep spring)
kill -9 $(pgrep mono)
echo "$(date) KILLED"
exit 0
}
launchGame

It must be a shell script and this one must be set executable with chmod +x run-zerok.sh
I'm pretty sure if we could change the processor to process timeslice we could fix this issue.

This script kills the launcher that never exits when the Zero-k is closed.

I have a better question. Why are you using such an old Kernel? I am running Debian 9 (stretch) the stable release and my kernel is 4.9.0-6-amd64 and I am thinking about upgrading so I can have a newer 32 bit graphics stack so I can both run Zero-K and Wine. The non-backport version of the kernel is 3.16.63.

quote: I have a better question. Why are you using such an old Kernel? I am running Debian 9 (stretch) the stable release and my kernel is 4.9.0-6-amd64 and I am thinking about upgrading so I can have a newer 32 bit graphics stack so I can both run Zero-K and Wine. The non-backport version of the kernel is 3.16.63.

Because I have so much tunings for my kernel that I fear to update it ^^
But I know that the new kernel provides a lot of improvements concerning the GPU stack. I would/should update the kernel.

The standard nice under my linux distro is 10 with renice -20 I go to -10 and the RT couldn't be reached with my kernel using renice.
I put some limits... but I effectively saw no improvements in the processor/unique core charge (it switches more quickly from one to one but stays at 105% that is a little too much ^^)

I tested it on a 4 core laptop with the most recent kernel, I did not experienced the same behaviour so I have to first back up all my works before upgrading the kernel...

I experienced something strange today, I was about to try for the 158th time a campaign, I launched the game and it downloaded a new version but since then I could no more save/load my games :{ that is frustrating :{ hopefully I succeeded to buss out the enemies ^^

hurukan did you check plain spring engine without chobby with flobby?