CMx2 Engine & Dual-Core Processors

[cassh]

Will the new CMx2 engine take full advantage of dual-core processing technology?

It will make the game run much more quickly, but only if it has been configured with dual-core processing in the code.

With potentially twice the processing power - running two threads at once - some very complicated and complex calculations can be achieved. This could allow for much of the detailed modelling touched on in multiple posts here such as ammo count modelling, LOS modelling etc.

[Vanir Ausf B]

Will the new CMx2 engine take full advantage of dual-core processing technology?

No. At least that's what they told us last year.

[Colin]

Honestly, I'm not sure why they wouldn't reevaluate that descison. Designing with the same chipset in mind for both platforms is a bit nicer anyway. It seems like Intel figured out that you can only clock so high with todays metallics so they are adding more cores. They are really pushing MP designs with multi-core notebooks and even consumer machines have Core Duo's for media apps. The Mac Mini and iMac for example.

Unless something major has changed turn crunching was always CPU intense and this real time thing will make it even more difficult. I have no idea about the coding standpoint, but I think it could be worth while.

That said I am on a G4, I just think one should make a game support the features it needs to make it complete. I trust BFC here of course.

[Sixxkiller]

God I hope so as I will be making a new computer to play this game. I would love this option as it will hopefully last a couple of years before I will need to upgrade en masse.

[Vanir Ausf B]

Originally posted by Colin:

I have no idea about the coding standpoint, but I think it could be worth while.

Coding for multi-core is very difficult, and I suspect this more than anything is why.

[Colin]

Okay well I lied I do have some idea about it.

Coding for multi-core isn't that much harder then coding for single core. It's not like it's a different syntax or anything. It's all about the API's for interaction of the threads. The problem has always been the limited support. It was difficult to implement because of the limited return. It used to be that you'd only really hit a small target market with SMP optimizations. Now we're potentially looking at a large number of users with more then one core available. With the CM engine's stretching over a number of games usually I could see this being beneficial.

Does anyone know if it's a Universal Binary?

Edit: It will be UB. However it isn't coming out simultaneously for Mac and PC. Bah, I must wait to play LAN games then!!!

[Redwolf]

"Optimizations" for SMP systems are a lot of work when done on a codebase not originally designed for SMP. In general, the only halfway easy thing to do is fine some "side" work for a second processor, so that the second processor plugs away on something different than the first.

True design for SMP will make all processors the same work, and 4 or 8 of them when available, so that you don't have to wait until you have "an idea" what to have the second processor do.

No matter which variant, it is a good amount of work.

The problem is not that threaded programming is so complicated, the problem is that it introduces a new class of errors which single-thread programs do not have. Deadlocks and data corruption from lack of a lock are common problems. Multithreaded proograms are harder to debug. Doing QA on multithreaded programs is a can of works, in particular because there is different timing involved depending on the number of processors. You multithreaded program that works fine on two processors might hang on a customer's machine with 4 processors. To guard against that, QA would need to do separate tests on all number of processors. Even if you find bugs, locking problems are harder to "freeze-frame" compared to e.g. segmentation faults that generally allow you to backtrace and find the offending code easily. With data corrupted from lack of a thread lock, who knows when and why it ws corrupted.

For a development shop like BFC, which is basically using one single programmer there is no way in hell they can come up with a SMP-aware engine unless it has been designed for it from scratch.

[Vanir Ausf B]

Originally posted by Colin:

Coding for multi-core isn't that much harder then coding for single core.

Not being a programmer myself, I can only go by what others have to say on the subject...

Tim Sweeney:

"Implementing a multithreaded system requires two to three times the development and testing effort of implementing a comparable non-multithreaded system, so it's vital that developers focus on self-contained systems that offer the highest effort-to-reward ratio."

...

"Writing multithreaded software is very hard; it's about as unnatural to support multithreading in C++ as it was to write object-oriented software in assembly language. The whole industry is starting to do it now, but it's pretty clear that a new programming model is needed if we're going to scale to ever more parallel architectures."

...

"These are hard problems, certainly not the kind of problems every game industry programmer is going to want to tackle."

Link

[Redwolf]

In case I didn't point that out clearly enough:

The user will also have to endure the mistakes made in early mtulti-threaded games.

Deadlock and data corruption will make it into the end product. While bigger software houses might assign programmers to debugging them after the release, in BFC basically only one programmer ever sees the source code. And that one programmer will do CMx2 the second game by the time your 8-core Opteron experiences hangs.