Multitasking Scenario 5: Compiling

Our final non-gaming multitasking scenario is quite possibly our most strenuous. It involves the following background tasks: iTunes playing a playlist, Firefox with the same 13 tabs open as in our other tests, and Newsleecher updating newsgroup headers. On top of those tasks, we compiled Firefox as well as ran our DVD Shrink operation on the "Star Wars Episode VI" DVD. Firefox remained the application in focus during the test.

The results were fairly interesting. First, let's look at how long it took us to compile Firefox:

The Athlon 64 X2 4400+ was stronger than either of the Intel CPUs in compiler performance, so it is no surprise that it is faster here. You'll notice that the single core Athlon 64 FX-55 isn't present in this chart - you'll find out why in a moment, but first, let's look at the performance of our DVD Shrink task that also ran in the background:

Once again, AMD is ahead of the competition, thanks to better general performance as well as all of the benefits of their low latency architecture. As for why the single core Athlon 64 FX-55 wasn't included here, well in this particular test, the DVD Shrink operation would have taken over 13 hours - which doesn't exactly fit with our graph's scale. The compiler operation also took significantly longer to complete. Whichever task completed first would eventually have let the other finish sooner, but we didn't care to find out as it was already ridiculously longer than any of the dual core solutions.

"It's odd that some picture game developers immediately supporting the PhysX chip as soon as it's available, but think they'll drag their feet to take advantage of another whole CPU core at their disposal."

It's basically about the implementation differences of the two. You can be relatively certain that PhysX is going to be shipping their chips/cards with libraries that allow game devs to just speed up certain processing with special function calls (ie, calculate_particle_spread()). Multi-threading requires that you design your application from the very start to take advantage of it (mostly - I would wager splitting off the background music to its own thread is reasonably straightforward).

Game logic doesn't always lend itself to multi-threading, either. If I shoot my gun, I want to hear the sound next. I don't want it to be thrown at the sound thread, where it may or may not execute next. Threading introduces latency, in other words, unless you so tightly bind your threads together that you may as well not use multi-threading.

#83 Get a clue, a single core 3500+ is faster than the quivelant Opteron at the same speed. Why? Unregistered memory and tigher memory timinings. ECC memory comes with a 2-4% performance penalty but the big difference comes with the command speed, 2T for the Opteron and 1T 3500+, the AMD64 thrives on lower lower latancies that can make as big as an 10% performance difference and that is BEFORE we start to even think about raising the FSB speed which makes a significant difference to overall system perfomance. 15% is in no way unrealistic with a mild overclock and lower latancies, if you don't believe me then email Anand and ask him. Reply

#40 (Doormat):
You're forgetting that the size of a dual-core is (roughly) double that of a single-core. So, assuming 1000 cores/wafer, 70% defect rate per core, then a single-core wafer (with an ASP of $500) will net AMD 700*500 = $350K.

The same wafer with dual-cores will produce (approximately) 1000/2 * (0.7)^2 = 245 CPUs. So, to get the same amount of cash per wafer, AMD needs an ASP of $1429, or the second core costing 85% more than the first core.

Of course, it's not quite this simple ("bad" chips running OK at lower speeds, etc) but it's not entirely unreasonable to see dual-cores with prices ~3 times that of a single core at the same speed grade. Intel is almost dumping (in the economic sense of the word) dual-core chips.Reply

Anyway, yes they both use c syntax, however thats pretty much irrelevent given that Java also uses c syntax (as does Managed c++ which incidently IS the .net language directly based on c++) and I've never heard anyone call it related to c++. Beyond (some) syntax heritage and the fact that they're both OO langauges, they're very different beasts.

""C# is directly related to C and C++. This is not just an idea, this is real. As you recall C is a root for C++ and C++ is a superset of C. C and C++ shares several syntax, library and functionality." Quoted from above.

L8r."

Err yeah c++ is mostly a superset of c++. Thats neither here nor there. Just try and use the c/c++ preprocessor in c# and you'll see very quickly what the difference is. Or try using c++ multiple inherritance. You'll find that just because you took java and added operator overloading and made binding static by default, its not c++.Reply