SupCom on many core processors?
Ever since I first heard that SupCom would be multi threaded, I have been wondering how well it will scale as newer processors come out. It is likely that in a few years time, 8 and 16 core processors will be available and probably not too expensive. So how well will SupCom perform on these machines? Will we be able to run 8 player free for alls on 80×80 km maps at +10 speed with no slowdown?
Sadly, the answer appears to be no. While SupCom is written to take advantage of two cores, it just does not scale well beyond that. The reason for this is that the vast majority of processing in SupCom is separated into just 2 threads – one for rendering, and one for physics, AI, and the like. There are additional threads, such as one for sound, but these require only a tiny fraction of any one core’s processing power. Basically, this means that the first 2 cores in any given setup will be fully or nearly fully utilized, but any additional cores will be mostly unused. Since individual cores are not going to be getting a lot faster, this means that computers a couple years from now will not be much better off playing SupCom than computers today.
Unfortunately, due to the technical difficulty of recoding SupCom to be more multithreaded, it is unlikely that this situation will change. So, a few years from now, that beastly 16 core processor you get with your new computer will likely offer only relatively modest gains over the current high-end dual core processors. Don’t fret too much, though, because even current processors can still handle some incredible battles!
March 16th, 2007 at 4:11 pm
Yeah but you’ll be able to encode a movie, use skype, and find a cure for cancer without interrupting your game.
I agree that it’s too bad, but for gaming, the development required to have coded some of the single threaded processes to be multi threaded would not be a very good return on investment since 16-cores won’t be around until the game is on the $5 shelf (I hope there’s a new version by then). Also, it would add needless overhead for those with single-core processors.
March 16th, 2007 at 4:43 pm
I hope and pray we have something better than SupCom by that time. With all these crashes I’m seriously thinking about going back to TA for a while. That game still doesn’t bore me. :P
March 16th, 2007 at 4:48 pm
Well, I’ve only ever experienced one crash with Supreme Commander, so I’m guessing that the problem isn’t with SupCom, but rather, a sinister synergy between Supcom and Windows Vista. I guess you know what to do :-P
March 17th, 2007 at 12:36 pm
Pardon my cynicism : )
March 31st, 2007 at 8:45 pm
You’re saying two cores only will be utilized effectively, but according to the benchmarks hardocp.com did, 4 processor cores DO make a difference in supcom framerates.
http://enthusiast.hardocp.com/article.html?art=MTMwNiw2LCxoZW50aHVzaWFzdA==
March 31st, 2007 at 8:49 pm
The way the load is spread out is that the first core gets a certain task and the other cores split up the remaining tasks. It’s not perfectly load-balanced, so each added core faces diminishing returns. So adding more cores doesn’t increase performance by as much as you might think it would.
April 3rd, 2007 at 10:09 am
It is untrue that a program cannot be made to take advantage of multi processors without avoiding overhead on single-core processors.
From using purely functional languages to disabling or outright patching out synchronization calls on single-cores, the options are too many to mention here. Also, if GPG was interested in making the game avoid overhead, they wouldn’t have used an interpreted language for the scripting. There are other, equally high-level options that run far faster. ;)
Now, then. It’s true that the current implementation of the game doesn’t take significant advantage of more than two cores, but it might not be as hard to change as you think. While there’s only one “OS thread” running the simulation – which can thus only run on one core – that thread contains hundreds or thousands of lightweight threads/coroutines. It would require quite a bit of work to (a) make a concurrent version of Lua, and (b) add synchronization to the scripts it runs, but it’s doable.
Something for Supcom 2, certainly.