CPU usage, cores and what not.

[MadTommy]

I'm curious about how the game uses your CPU & its cores.

 

I have an E8400 dual core running at 3.6Ghz. My understanding is that DSC-A10c uses two cores , one for the game engine & one for the sound engine. Is this correct?

 

From the FAQ

Q: Will DCS: A-10C use all cores on my CPU?

A: Not fully. It does include the new sound engine which operates in a separate thread, and does take advantage of some DirectX threading features when running on Windows Vista or 7.

 

I'm on Windows 7 (x64)

 

I have a couple of questions?

 

Is there any advantage to having more than 2 cores when running DCS? It appears to me there is not, has anyone witnessed different?

 

Is my CPU basically better at running this game than an i7 running at 2.8 Ghz for example?

 

Are there plans to support true multiple CPU support in the future?

 

Thanks.

[EtherealN]

Is there any advantage to having more than 2 cores when running DCS? It appears to me there is not, has anyone witnessed different?

 

If you have scheduled events, such as antivirus scans and other maintenance jobs, having extra cores usually means you don't have to worry about them while playing since they'll use the free cores. There are other gains as well of course depending on your habits. As an example, I watch a Starcraft 2 commentator called Husky quite a lot, and he uses an i7 920 (if my memory serves). For him there's no problem at all running SC2, Livestreaming software and video encoding software all at the same time - since they spread out to different cores they don't degrade each other that much.

 

Is my CPU basically better at running this game than an i7 running at 2.8 Ghz for example?

 

No. GHz is not everything, and can only really be a useful comparison between processors of similar design and type. So you can compare C2D's through clock speed, but Nehalem and later is very different silicon and clock speed becomes a very fuzzy comparison. The newer processors get more job done per clock cycle, meaning that a 3GHz i7 will be "faster" than a 3GHz Core2.

 

Are there plans to support true multiple CPU support in the future?

 

Over time, as each subsystem gets reworked, all components would be investigated for ways to improve their basic design, and splitting them to separate threads would be one of the ways investigated. It'll happen, but it'll take time, since re-writing code to be multithreaded is a very non-trivial thing. (For example, if the devs were to say "let's just make DCS:A-10C fully multhithreaded" it would delay the product with probably years without adding much in the way of features.)

Edited February 1, 2011 by EtherealN

[Steel Jaw]

I think that only very high-end software that employs huge dev budgets, say for example US DOD software, could be made multi threaded in a reasonable amount of time. If the money and resources are there, I am sure it could be done quickly. But a game dev is of course a different matter, with limited resources and budgets.

[EtherealN]

Aye, as is the saying:

 

Quick, Cheap, Good: choose any two.

 

Credits go to sobek. :)

[MadTommy]

Thanks EtherealN

 

Personally i never have schedule tasks set, all maintenance and such like i do manually, even if i had 20 core i don't think this would change, old habits and all that.

 

Also if I'm flying don't generally have anything else running, trackir, TS3 and maybe the odd time winamp, never antivirus or such like. My CPU seems to cope well at the minute.

 

Am i correct in my assumption that DCS only ever uses 2 cores then?

[EtherealN]

Ouf, that's generally true. It depends basically on what DirectX does, since the driver does a lot of smaller funcy stuff. But generally speaking, 2 cores, yeah.

[Headspace]

Husky

H to the usky Husky?

I think that only very high-end software that employs huge dev budgets, say for example US DOD software, could be made multi threaded in a reasonable amount of time. If the money and resources are there, I am sure it could be done quickly. But a game dev is of course a different matter, with limited resources and budgets.

Plenty of games are multithreaded. Even TARS is multithreaded (then again, it's not the hugest piece of software). Multithreaded programming is an order of magnitude more difficult in many cases due to all of the pitfalls involved, but it's not impossible. The key is that from the beginning, the design has to account for it, or there will be problems. Going from a single threaded design (for anything, really) and then, after you've written part of it, swapping into the multithreaded world and sharing resources can be very problematic.

Edited February 1, 2011 by Headspace

[EtherealN]

H to the usky Husky ftw. :P

 

And yeah, from what I have understood (and I've never seen any of the source code nor am I really in the loop about what the engineers are thinking so I'm making educated guesses) it basically came down to a choice of either trying to convert stuff into multithreaded operation, or just "replacing" bits as you go along. So for example when the new sound engine was completed, it was by design made to run in it's own thread and the old engine simply excised from the codebase.

 

Seems like the best method to me, even though it does mean that it'll take time to fully migrate the codebase to a multithreaded implementation. But since we are talking about a fairly major chunk of code and a small and independent developer with no major publishers to woo for bailouts... It might even be the only way that works without sending the company into bankruptcy.

 

So it's coming, but not as fast as those of us fortunate enough to not have to do the programming might want. :P