Slashdot Mirror
Dual Cores Taken for a Spin in Multitasking
Vigile writes "While dual cores are just now starting to hit the scene from processor vendors, PC Perspective has taken the first offering from Intel, the Extreme Edition 840, through the paces in single- and multi-tasking environments. It seems that those two cores can make quite a difference if you have as many applications open and working as the author does in the test." It's worth noting that each scenario consists of only desktop applications, and it'd still be interesting to see some common server benchmarks, such as a database or web server.
I'm still bumming around with a sub-gigahertz chip, specifically an Athlon T-Bird. I've been out of the loop for too long, can anyone tell me the benifits of using a dual core system (and while we are at it, a 64-bit chip)? Any problems to look out for if I decide to jump on the wagon in my next upgrade?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
What this test really was missing was a direct comparison to SMP systems which really for me makes the results entierly boring and expected .
If he had shoved in a duel opteron set-up and a duel xeon set-up then it may have been a little more intresting , though as it stands its like stating the obvious.
The only things certain in war are Propaganda and Death. You can never be sure which is which though
...and I'm not quite sure if it's a good one, but for desktops:
The foreground program has a dedicated core. If you switch programs, put the old on the "other" core. The new moved from the "other" core. Essentially, your current program has full responsiveness (assuming you don't do things that lock up the application itself), no context switches, no other programs that can run some weird blocking call (on a single core machine, it certainly looks that way at least, especially CD-ROM operations).
Granted you could end up with your fg processor being idle most of the time. But the way many people work with the computer, the foreground program is the ONLY time-critical application.
Kjella
Live today, because you never know what tomorrow brings
That last page raised my eyebrows. 291 Watts under load, that's some serious power draw compared to what I'm used to. And that had to be kicking out some serious heat, too.
Anybody know what is the draw for a 4x Xeon system? I'd be interested in seeing how they compare.
I wonder at what point the facilities people will want to use the server farm to heat the building, too. A weird convergence, the PC world is becoming more like the old mainframe world.
"Well..here I am..." - Jubal Early
I feel a good use for Dual-core systems is to put the OS on one core, including all explorer.exe instances and threads.
The operating system shoul employ a smart system of monitoring CPU usage per thread and move the high- usage threads to the other core.
I wonder though, on a slightly different topic - heat dispersion: nobody seems to talk about it - but two cores mean twice as much heat. How the hell do they do away with the heat? It dissapointing but they might be speedstepping/downclocking the cores dynamically at peak load.
This certain warrants discussion.
Dual Bus memory still doesn't cut it.
Each Opteron has a dual bus memory controller on board (granted, only DDR400)... but as I increase the number of CPUs, the number of memory busses increases.
The 4 CPU boxes I'm working on have 8 independent DDR400 memory busses.
The only obvious way to get your memory bandwidth to scale is to have your memory controllers per CPU (or even better, on the CPU itself).
There's this interview with Tim Sweeney, the leading developer behind the Unreal 3 engine.
They're working on a multithreaded engine for unreal 3, exciting stuff.
Like you said, AI is a logical chunk of processing that should be on a separate thread. Other logical chunks he mentions are physics, animation updates, the renderer's scene traversal loop, sound updates, and content streaming.
So at least one multi-threaded game engine is in the pipe. This is good because we don't really have a chicken and egg problem.
So I agree games will improve a lot with multi-core.
But for other apps I'm not as excited. I don't know what other apps I use regularly could be sped up with a multi-threaded rewrite. Virus scanning? Searching? Media playback? eMule? SETI? Maybe lots of apps can be sped up, but will any of them do it? In the interview I linked Tim says a multi-threaded system takes 2-3 times longer to write and test.
I don't use most of the apps that have a lot to gain from multi-cores (Media creation apps, server apps). Maybe I'll start doing more things at once. Or maybe run a dual-head system. Maybe.
It seems games are the only resource pig apps I've ever really run, so they're the only apps that will prompt me to upgrade to multi-core. Maybe once dual cores are common non-game developers will start to exploit them. And maybe some app will suprise me but I'm not holding my breath.
Until then a single CPU serves my needs fine. Sometimes I come across situations where I close one app to give another a boost. Such as shutting down apps to make the game faster. With a dual core I could probably run everything, but for now I'll settle for shutting extra stuff down.
In the future when playing a multi-threaded game on a multi-core PC I'll probably still shut down extra apps just to squeeze out the extra fps.
Well you're right about what you were saying, those words would arbit a good deal of flames. But everything has its place and there's a place for everything. Lemme explain.
Clockspeed is the easiest race, if you want to think of the CPU industry as a continuous race. All you have to do to crank out a faster CPU is continually shrink the die (because smaller gates flip faster), and make sure that everything is arranged neatly on the chip. When you hit thermal walls like we are now, it's simply time to reduce the voltage, and shrink the die again.
The only problem is, Intel's flagship for doing this now, happens to be one with a lot of baggage. The Netburst core design pretty much dictates there is to be at least two of everything, and both of them should be running all the time, especially if Hyperthreading is on. This effectively doubles your transistor count (though in reality it is less than that; there's only a single copy of bus administration, micro-op decode, etc). Keeping them on all of the time also helps jump the heat production.
But here's a truth; their CPU clock game could still be running if they would like it to. The Pentium-M is still running extremely cool. Shrink it to a 90 micron core, use SOI, strained silicon, more of their substrata magic, and a healthy dose of SpeedStep, and you could see a Pentium-M hitting 3.5GHz clockspeeds that would put both the Athlon 64 and the Pentium 4 to shame. Sadly, to build this processor is to admit defeat with the Netburst core, and Intel's being very stubborn.
On the other hand, I believe AMD's got some magic they haven't used yet up their sleeve. Though honestly I couldn't tell you what it is. There has to be a reason they aren't playing up the Turion more other than the fact it isn't scaling down as far as the Pentium-M can. I'm also surprised they're being so slow about ramping their clockspeeds, but this is probably just so their thermal profiles look superior to Intel's. A 3GHz Opteron could easily decimate a dual Xeon setup, but at the same time would probably produce just as much heat, and I think AMD would see that as a defeat.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush