Ultra Poor Performance - Lack of SMT

[Bobs]

I have to admit I'm rather disappointed... I've recently re-started playing Creeper World4, after a hefty system upgrade... However, I'm still running into the issues with complex maps etc of <10fps... I check system stats and my CPU is <15% and GPU <30%...

Diving into CPU use and it appears that Only 1 thread is being heavily taxed at ~80% (fluctuating between ~60-85%)... Then 2 other threads are fluctuating between 25-50%... The remaining 13 threads are <5% taxed!

Is there no way to code in a reliable way to use SMT within this game... as it Desperately needs it!!!!

[Karsten75]

Firstly, let me address a point of pedantry. :) 

SMT mostly refer to hardware as opposed to software techniques that exploit multithreading. :)

Multithreading in applications is complex. It involves the creation of threads, then assigning work to those threads, then ensuring that the work finally waiting for all threads to arrive (complete) at a point of consistency. There are additional complications in ensuring that access to data and memory are synchronized and that one thread will not overwrite or corrupt data required by multiple threads. Finally there is the issue of preventing deadlocks between threads when one thread is holding one or more resources required by another thread. 


This makes it so that not all applications can take advantage of multithreading within the same application.  Sometimes the above activities represent a cost in instruction cycles that is more than can be saved by running in parallel. 

In some processor-intensive areas, CW4 does multithread. One notable example is the Creeper simulation that is executed my multiple threads and then consolidated at the end of each frame. 

One area  of execution that is difficult and with uncertain benefits is the area of custom units and the built-in scripting language (4RPL). Interactions between units mean they are not thread-safe without significant additional work and perhaps a skill and understanding of multi-threading that is not within the scope of gamers creating custom levels and units. 

So, I'm willing to bet that you have found these performance issues on custom levels with many units and complex scripts - some far beyond what was envisaged as the design goal for the game.^* The scripts and custom units are also less optimized than the built-in units, since they have to call into the 4RPL interface for every command, whereas built-in units are optimized with custom code.

Unless each and every map maker is willing to learn how to write multi-threading code, and unless the game developer even have the resources and time available to implement thread-safe code, these is how it will be - for this game and for future games.  I can tell you that for the next game we are looking at attempting to optimize some scripting operations by "packaging" a complete function, such as acquiring an enemy; targeting it; and firing at it as a single function call, thus traversing the API interface only once. While it does not multi-thread the code, this does mean that some operations might be optimized. However, it also means that all units are essentially equivalent, and thus all units will take a performance penalty. We're still not far enough in the development of the game to assess if this is worthwhile of not, though.

^* Writing completely different game modes and extensive custom units would fall into this category.