Games just don't uses multiple CPU cores?

[V8VENOM]

So why aren't developers investing the time and money into producing a better end user experience by utilizing multiple cores?

Multiple CPU systems have been around for a long long long time, why have developers (and those companies paying the developers) NOT included specific support for multi-core systems?

Here is the problem:

CPU makers, can't really go much faster (Ghz) without power/heat issues
Software engineers, we wanna code support for multiple CPUs, but the bean counters say "NO, it takes longer and is more expensive". So what are we left with ??

A hardware industry saying "this is the future", a software industry saying "we can't spend the time/money to support"-- the end result?? Clunking slow games (Microsoft's FSX comes to mind) that under-utilize the current hardware.

This is a pretty significant problem and the software engineers don't appear to be agreeing with the hardware engineers.

Microsoft don't care, their mission is clear "generate revenue for the least amount of work and go leverage it" -- so where does that leave the consumer -- the XBOX360, PS3? Is this the death PC gaming will receive?

Rob.

 

[darious00777]

Well, the latest title in my collection would be Battlefield 2142, and when I wasn't maxing out my dual core processor with BOINC, it seemed to me that both cores were being partially utilized by the game. One core was around 60%, and the other around 40%. So I can tell you that these games do exist, you just might not be looking hard enough.

 

[NaDa]

Yes Battlefield 2142 is a wonderfull example of bad coding.

AMD officially started shipping the Athlon 64 X2 at Computex, on 1 June 2005. That is almost two years and the crappy battlefield engine doesnt support multithreading.
I play this game a lot and it's reallyu great but it's a real cpu hog.
I need to overclock my athlon64 x2 and my memory to their limits to get good frame rates.

 

[mrmez]

There is a system out there that matches h/ware and s/ware....
Its called a Mac :lol: :lol: :lol:

Seriously tho... game development right now is behind h/ware dev. Just look at DX10. Having said that most of the decent games that have been around for 6 months or more DO infact utilize at least some part of the 2nd core. I know this from the bar graph on my G15 KB.

I also know that games like Oblivion arent REALLY optimised for dual core.... (or anything less than 8800GTX).

Given the fact a game MAY be in development for some time be4 we hear about it... it can be a tought choice.

Keep going single core?
Start over and make for dual core?
Get half way thru DC ver then hear abt DX10... start over for DX10 Ver?
Get DX10 half way done... find out Intel is selling Quads for $200... start over with quad ver?

IBM/PC has ALWAYS had poorly matched s/ware and h/ware, but i think its getting better.

 

[darious00777]

No there is a difference. Those Games are CPU intensive but the only reason they use both cores is that windows is passing the extra load off to the 2nd core. In multi threaded apps the program uses both cores at the same time. So if your running a dual core CPU with 2 GHz on each core the program will be running like it's on a 4 GHz CPU. Both cores will be running at the same percentage of load at the same time. Each core will be handling half the calculations pushing out the end result twice as fast. I’m sure someone else can explain it better then I can.

Didn't seem that way to me, but if you've got a way to back that up, I'll be convinced.

 

[bullaRh]

i agree with jack there.. and we will probably see more multicore threaded games in 2007 :b its the future.

 

[mannwhite]

http://www.gamespot.com/features/6166198/p-6.html

Check this page out. The benchmarks show a lower-clocked quad-core handily beating a higher-clocked dual-core by quite a bit. Whoever is saying multi-core applications don't exist is living on another planet. Have you tried runninf either Supreme Commander or Company of heroes with full physics on a single-core? Try it and watch your CPU check in for post-traumatic disorder. hehe.

 

[bullaRh]

we might get more ghz and faster cpu's but we will need more cores anyway, a 4.5 ghz quadcore sounds pretty nice 2 me tho.

 

[SSS_DDK]

Graphics programming on a multithreaded base is a bit complicated due to race hazards between the GFX card and the cores. On a code level, most games utilize game engines which they purchase for like 300 000$ (per game title) and these evolve every two years or even more (the original Unreal Engine is still in use today). Most of the CPU intensive code is integrated in the engine itself (collision, rendering, etc...), so newer games need to rely on "older" graphics "middleware" aka Gaming engines.
And you have to understand, that usually, if a developer doesn't go multithreaded, it might just mean he doesn't have to (he gets enough output from a single core).
PS: even though multithreaded applications are supposed to run on multiple cores without modification, there are some coding practices that prevent this behavior (bad synch of the CPU cache, etc...)..

 

[djgandy]

So why aren't developers investing the time and money into producing a better end user experience by utilizing multiple cores?

Multiple CPU systems have been around for a long long long time, why have developers (and those companies paying the developers) NOT included specific support for multi-core systems?

Here is the problem:

CPU makers, can't really go much faster (Ghz) without power/heat issues
Software engineers, we wanna code support for multiple CPUs, but the bean counters say "NO, it takes longer and is more expensive". So what are we left with ??

A hardware industry saying "this is the future", a software industry saying "we can't spend the time/money to support"-- the end result?? Clunking slow games (Microsoft's FSX comes to mind) that under-utilize the current hardware.

This is a pretty significant problem and the software engineers don't appear to be agreeing with the hardware engineers.

Microsoft don't care, their mission is clear "generate revenue for the least amount of work and go leverage it" -- so where does that leave the consumer -- the XBOX360, PS3? Is this the death PC gaming will receive?

Rob.

Because development isnt a case of clicking the multicore button. There is work to be done.
Software is millions of lines of code. You can't just make it multi core compatible over night.

Yes multi cpu has been around a long time, but not in the mainstream. Server software like apache, mysql, that can run multi-core.

 

[mitch074]

For those seeing multiple core use on current processors:
- if you see a core busy at 60% and the other at 40%, it means that threads are indeed separated and allocated to different cores, however each thread is waiting on the other - as such overall the program goes no faster than a 100% single core.
- if you see a 110-115% cumulative load, don't forget you have an antivirus running, an OS, an integrated disk controller and sound chip: those use up a few percent of completely separated processes - above applies.

Right now, apps are merely thread-safe (meaning you have much less interprocess timing problems) but not yet multithreaded (meaning it runs several processes that don't depend on each other).

 

[Cabletwitch]

SSS_DK has a good point here. With multiple thread programming you have to avoid a few spurious events happening, known as Race Conditions and Deadlocks. You also get a lot of waiting around. I'll try and explain then below.

When you have 2 processors working on a shared task, you might find that one processor is completeing its tasks faster than the 2nd core, so it spends a lot of its time waiting around. In situations like these, the speed increas on a multicore system isnt anywhere near the amount you;d think. In some cases, you're seeing very little increase, but usually, you're lookit at no more than 50% (Seeing as half the time, the other core is idle).

A Race condition is where you get both cores requesting the same data, and modifying it for later use. An example (Which I've pinched from Custom PC magazine) is say you have 2 AI routines running in a game. Each AI runs on its own core. When an AI charactor shoots you, it fetches your health as a value, removes one point from it, then updates the value so you see your overall health decrease... Now what happens when both shoot you at the same time?

Start with a health of 2. Both AI's shoot you. Core 1 grabs the current health value, then does it calculations on it. HOWEVER... before Core 1 has a chance to store and update that value, Core 2 has already read it. Both cores are now working on the original value, and both subtract 1. Core 1 stores, then Core 2 stores. The result is you are still alive, when the damage done should have killed you. Fun, yes? You can lock individual threads with a MUTEX (Mutual Exclusion) wich prevents one thread from reading data until another thread has finished with it, but then you're running in serial, and you get way less performance from your dual core setup. However, careless use of MUTEX's leads to...

Deadlocks, which are even more fun. Ok, so in your game, the enemies health is displayed next to your crosshairs, along with your own health score, right? You wave it over the enemy, and the graphics engine runs the routine to update the health meter, yours first, locking the data it need to run it with a MUTEX. The AI routine, however, has run its own routine which decides wether or not to attack you based on its own health compared to yours. It cant read your health data currently, so it enters a blocked state for the time being, waiting for the MUTEX to finish.

Now the fun begins... The graphics engine now needs to read the health value of the enemy AI to finish its routine. However, the AI is running its own routine to compare health, so its locked the data representing its own health value, so it can finish its own calculation. The Graphics engine then enters a blocked state, waiting for the AI routine to finish.

See the problem here? Both are now locked, waiting for the other to finish to access each others data. The result? Frozen harder than Outlook on a Patch Tuesday.

In literally millions of lines of code, you have to make sure this never happens. In serial code, sure, easy enough. Sequential code is nice, fas and easy to sort out, compared to parallel code which might not even bring up the same bugs twice in a row. Hell, you might only get it one time in a thousand. But ts still there, and its a bastard to solve.

Despite everything I've written, I'm not a programmer. It took me a long time to understand everything above, and I might not have put it clearly (Any programmers, tell me if I went wrong anywhere). But thats the basic gist of things, and thats why massivley parallel games arent everywhere.

 

[jamiepotter]

Maybe someone can answer a couple of questions for me? I think I grasp that you've literally got to recode a piece of software in order for it to be multi-threaded with parallel execution. (Btw, the number of _processes_ would not increase in a genuinely multi-core app). It must take quite a bit of ingenuity in order to figure out how one could spread the load so that one core can genuinely get on with something another core was going to do.

But what I don't get is the following:
1. Will it be much more hassle to code for 8 cores (say)? I mean, are we going to face this delay every time the market starts to move towards more cores? Are we going to have this ridiculous situation where everyone's got 8 cores, and the only multi-core software uses 2 cores at the most?
2. Why are Intel banging on about quad-core gaming? Stuff like Company of Heroes, fair enough. But for a lot of games, aren't you just going to have 4 cores waiting around for the GFX?

 

[jamiepotter]

That's bloody well explained. I was reading about 'race conditions' and hadn't understood a word!

It seems to suggest that programmers will have to code for a specific number of parallel execution threads, which is probably going to be stuck at 2 for a long old time, if that.

Intel will probably still sell quad-core on marketing alone!

 

[JAYDEEJOHN]

Whats missing here is, as apps go multi threaded, as stated above, 50% more/faster on a dual core can be read possibly 100% for a quad. Right?

 

[bullaRh]

if u read a little valve is more excited about quad than dual core

 

[jamiepotter]

Whats missing here is, as apps go multi threaded, as stated above, 50% more/faster on a dual core can be read possibly 100% for a quad. Right?

I don't understand. What's your point :?:

 

[JAYDEEJOHN]

I read, Ive read til Im red in the face. I was making a point. Anyone whos ever had a PC has used multi threaded apps even on a single core, or multitasked. Duo is good for multi tasking, but quad rulz for multithreading

 

[Cabletwitch]

No. 50% is pretty much an average maxiumum for good code. On a quad core system, you'd run dual proc code slower, as you're only utilising 2 cores, instead of all 4 (Bear in mind that the more cores you have, the slower they are likely to be clocked, hence the speed loss overall).

The big trap people keep falling into is assuming more cores = more power.

If the code is coarse threaded, then the programs dont scale well. With a ratio of one core to one thread, sure, you get speed, but its not the best use of resources. Currently, most games tend to use coarse threading, if they use it at all. The Half-Life 2 Engine uses a mixture of couarse and fine threading, which while not as good as 100% fine, gives a better mix and allows the engine to dole out tasks to certain cores as the need arises, while keeping the cores busy with a semi-dedicated task as well.

Games suffer from the fact that all these threads need to be synched every frame. If you're running at 60fps, then every 1/60th of a second, your threads need to know whats going on. In contrast, something like Folding@Home doesnt need to synch threads, as each one takes its data, and runs until finished, regardless of what the others are doing.

So, ultimatly, unless the game is A) multithreaded and 2) uses a good threading method, then iii) you wont see much improvement on a 4 core or 8 core system over a dual core.

Hell, even todays single core systems are more than capable of running pretty much all the games out there. The main speed increase you see when running on a dual proc machine is that the OS takes one core, and the game uses the other. Less task switching, = more speed.

And for the record, Windows XP is pretty damn good at making sure things like this happens. Dont forget your OS is also a vital part of the speed increase stage. If your OS cant allocate tasks to multiple cores efficiently, it doesnt matter how many you have, it just wont be very good. I imagine Linux can do the same fairly well?

 

[jamiepotter]

Good stuff CableTwitch. Can you answer my questions at all? For fine-threading, will programmers design for a specific number of cores, or will they leave it fairly open or program ahead?

For instance, one could fine-thread a program into 16 threads that run in parallel (avoiding any race problems or deadlocks), and then a single-core system would run them all in sequence (or time-slice them, whatever). a duo-core would run 8 on one; 8 on another, a quad-core would run 4 on each etc.

Or instead will they just think: feck it, let's just design for 2 cores. We'll worry about programming for 4 or 8 when we have to.

What I'm basically interested in is whether it is simply the move to parallel execution multi-threading that creates the programming problems; or if it is always going to be a huge decision how many cores one should optimise the program for.

 

[Cabletwitch]

As far as I'm aware, fine threading can adapt to the number of cores, and dosh out threads to cores as-and-when the need arises.

As for the race and Deadlocks... thats down to bug squashing, not just making sure certain threads dont run with others. In fact, from what I can see, you're more likely to encounter them with the more threads you run, so the problem becomes proportinal to the number of cores you're running.

I could be wrong, so its best to double check this. But from what I've managed to make out from this, thats what I can see happening.

Also, whereabouts in the UK are you, out of curiosity? Reading-based loonatic here....

 

[JAYDEEJOHN]

Linux is great, but underused. Vista allows for better multi threading and hopefully the next M$ product due out in 2 years, will even be better yet. One question I do have is, is it better to write (in general) multi or in 64?

 

[bullaRh]

http://techreport.com/etc/2006q4/source-multicore/index.x?pg=2

there u can see multicore performance benchmark in the source engine

 

[yakyb]

i read this very same article and a great article it was to. it explains very clearly the dificulties behind multithreading an application (through the example of a game) however Mpilchfamily, jumping jack and MrMez have hit the nail on the head

yes most games released in the past year have been on going projects of which some will have had the game almost ready for a year already (not to mention the code behind the engine which could be very old indeed) and just gone under level making, testing and tweaking. If you think about the old Duke nukem forever analogy, if every project decided that when a new tech came out to redesign it never would come out

and as MrMez mentioned this is exactly the case with DX10(last week 10.1 was announced at Cebit along with a little discussion of DX11)
we will start seeing DX10 games coming along shortly Cryisis, UT3, patch for FSX (which im not sure why that is taking so long as surely MS want to get DX10 rolling as soon as possible, my best guess really bad driver issues in actually implementing DX10) and also the patch for Sup com

however i dont quite agree with the statement that Game development is behind Hardware development i dont see it as simple as that. firslty how can you program for a multi core enviroment if no multicores exist therefore game development will always be behind hardware. however it took Gpu hardware 8 months to catch up with Oblivion, and even people with qx6700's are still complainging of slowdowns in SupCom.

Now as Jack correctly put it things are begining to filter through quake4 call of duty2 , supcom, crysis, alan wake(later) and even the revised source engine so development is happening but its just delayed by the reasons pu forward

my own take is that anyone (myself included) wanting to build now should wait until some of this development comes to fruition.therefore getting 20% extra performance at no extra cost .im using Crysis as the basis of my build so im going to wait until that is out then compare benchmarks over a variety of systems and games (and other programs) to come up with a proposed build. whether it be AMD or Intel, AMD or Nvidia quad core or dual core, i will weigh it up when the time comes. if by then Dx10 still isnt getting decent results i may have to re-evaluate. but at least ill be able to make an informed desicion. and whilst the 8800GTX performs dx9 brilliantly it is still unclear as to how well it will perform DX10. now i dont want this to happen but it is very possible that 8800 will perform DX10 badly leaving people with essentially great DX9 cards

anyway im going off topic but basically development can only really start once a tech is in place. put it this way you cant design a house before you have a look at what the area you building on is like

 

[bullaRh]

the next MS product in 2 years? and what kinda OS should that be?