Conclusion

Writing multithreaded code means much higher software development costs while CPU development gets easier and thus cheaper (compared to even more complex superscalar CPUs). No wonder that the CPU developers are very motivated to hype the multi-core route, but the software development community is probably less enthusiastic.

Intel and other manufacturers should not simply push the costs of getting higher performance onto the software developers. Because, in the end, it will be the consumer who will pay the final price: either more money or buggier software with more crashes and hangs. One way that Intel and others can help to keep multithreaded development costs under control while offering increasing CPU performance is to keep investing in ILP and thus higher IPC cores; another option is to improve the interCPU communications.

The easiest part of multithreading is using threads that are running completely independent, that don't share any data. But this source of threading is probably already being used almost to the fullest. In order to tap into a new source of multithreading, such as the largely unused potential of multithreaded AI, Phyics and animation, it is important that developers don't have to worry about interthread messaging and synchronization lowering performance.

Very fast interprocessor communications to make sure that thread synchronization comes with little overhead will give a bigger incentive to developers to invest the extra time in multithreading.

Gabriele Svelto:[4]
"Most of the current multi-threaded software is developed with an eye at keeping inter-thread messaging and synchronization as low as possible because both have a significant cost. This cost will be lowered by an ordered of magnitude by multiple cores on a single die giving in turn more flexibility for the programmers.

Applications which got low speed-ups by going multi-threaded due to the overhead of fine-grained locking mechanisms will be able to exploit multiple-processors with fast interprocessor communications much better."
The Pentium-D and Pressler are examples of how not to do it: just slap two CPUs on the same die and call it a day. High clocked single cores like the upcoming Athlon 64 FX-57 will eat these massive chips for lunch in almost all benchmarks while consuming less energy. With the exception of some special far-fetched benchmarks, it will be pretty hard to justify the reason behind these dual cores.

Luckily, Intel's Yonah and AMD's Dual Athlon 64 cores show that better multi-core CPUs are on the way. At that point in time, we are entering the multi-core engine for real. And we can only applaud that because it unleashes a massive amount of CPU power upon the developers.

References

[1] Intel multi-core briefing
Stephen L. Smith, Vice President Digital Enterprise group, IDF Spring 2005

[2] Unreal 3 engine
http://www.unrealtechnology.com/html/technology/ue30.shtml

[3] Galactiv Cilivisations
http://www.galciv.com/index.asp?c=1&u=0

[4] Gabriele Svelto on dualcore CPUs
http://www.aceshardware.com/forums/read_post.jsp?id=20270&forumid=2

Threads & Gaming
Comments Locked

49 Comments

View All Comments

  • at80eighty - Monday, March 14, 2005 - link

    lame jokes aside... i agree... thats is some serious graphics... im gonna bust a nut or two to have a machine running a game like that at full steam : (
  • at80eighty - Monday, March 14, 2005 - link

    ksherman

    DEFINE 'sexy' ?

    : )
  • knitecrow - Monday, March 14, 2005 - link

    dual-cored GPUs are stupid

    given the parallel nature of graphics, it makes more sense to just add another pipeline at very little design cost.
  • xsilver - Monday, March 14, 2005 - link

    isnt dual cores also coming to GPU's --- would it be any easier to code for this? eg. one GPU can be assaigned textures and the other GPU the lighting?

    multi cpu will be definitley hard to code for
  • tygrus - Monday, March 14, 2005 - link

    The 124% is misleading but can be explained as valid.
    Intel said 124% more frames per second for a single task from a group of three; not 124% faster for all three tasks. Having the two video encoding running on a separate CPU most of the time could allow the game to have 3x the CPU time while the two video encoding threads get slightly more time. These advantages still have to be reduced because of CPU speed reduction, Mem, disk IO and other bottlenecks. If the required CPU cycles for video encoding, games sound, IO control is almost the same then almost 100% of the extra CPU cycles can be devoted to speeding up the game. I'm sure Intel have the OS and software benchmark to prove it.
  • knitecrow - Monday, March 14, 2005 - link

    In summary, dual core products for the consumer market is hype.

    One thing I know, is that developers want to minimize development costs. Given the immense complexity involved, I expect dual cores taking a VERY VERY long time to catch on... even then it'll be a half assed job.


  • wien - Monday, March 14, 2005 - link

    Ah yes.. Great times for us programmers. I can't want to start debugging those highly multithreaded applications.

    Thanks a lot Intel and AMD!
  • ksherman - Monday, March 14, 2005 - link

    That Unreal Engine is sexy, no?
  • Jynx980 - Monday, March 14, 2005 - link

    This will surely drive up the cost of games, not to mention that you would need a new cpu(s) to take full advantage. Its going to be a tough market to push.

Log in

Don't have an account? Sign up now