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.

Comments

Newsflash...

[jawtheshark]

SMP system performs better when applications are multithreaded...

(Dual core is the same as an SMP system, except the cores can communicate a bit faster with each other)

Re:Newsflash...

[The New Andy]

... assuming the OS chooses which threads are executed on which core well enough. If two threads depend on each other heavily and they are running on different cores, you can get really crappy performance.

So the obvious answer would be to move one of the processes to the other core. However, this isn't trivial. You either have one scheduler per core or one scheduler per operating system. (You can't have a single thread sent to both cores easily - if both cores run the same thing at the same time there will be chaos)

If you have one per core, then the scheduler trying to get rid of the thread will have to synchronise with the other core, waiting for the other scheduler to come into context, it then has to tell it to add this new process. Obviously, there is a fair bit of overhead, and if my memory serves me correctly, each core in the current chip has its own cache - so now all the stuff which was cached has to be sent to memory (since it is in the wrong cache) and now there is nothing in the cache, making every memory access slow for the next little while. End result - you can transfer a thread between CPUs, but it is costly.

It is possible to have a single scheduler which can then just dispatch threads to each core as it gets run by each core. The big one here is making the scheduler threadsafe - both CPUs could run the scheduler at the same time, so you have to make sure they don't crap on each other. This is a problem which we have solved already with common synchro-primitives. But, if you just lock the list of threads to run (*), then you will get a whole lot of CPU time wasted just waiting to run the scheduler. It might be acceptable for 2 cores, but it doesn't scale at all.

(*) You may realise (just as I realised) that a scheduler is more than just a list of threads to run (it is typically implemented as a couple of lists for each priority). The same problem still occurs with more than one list of threads, it is just a bit harder for me to express (proof by bad English skills).

Finally, I'm expecting someone to tell me that I'm wrong about something I just said. That person is probably correct. My only experience with this stuff is a 3rd year undergrad operating systems course where we played around with OS161 (a toy operating system basically). But, hopefully the end conclusion will be the same: twice the number of processors won't equal twice as much performance, and it is tough to get a fast algorithm that will scale.

A matter of time.

[Renraku]

How long before applications start figuring that they should have an entire core dedicated to them?

Windows, for example. What if the next version of Windows requires a dual-core processor to be usable? You know..Windows gets one core to idle at 80% of its capacity..and spills over into the other core when loading a text file.

If things stayed the way they were now, and the entire other core could be kept separate from the OS and used for gaming/other applications, it would be a great idea.

But guess what.

Well?

[Anonymous Coward]

Does this mean my Windows XP machine wont pause when I put in a floppy or Cdrom? Wow, sign me up.

Anandtech

[iamthemoog]

Has the new dual core opteron up against a quad Xeon with 8MB cache, amongst many others.

Well worth a read:

http://www.anandtech.com/cpuchipsets/showdoc.aspx? i=2397

It's bad news, actually...

[pmadden]

I'll probably get flamed for this....

Increased performance in CPUs has normally come from faster clock rates and more complex circuitry. As we all know, Intel (and the others) have bailed out on faster clocks. If you add more complex circuitry, the logic delay increases--to keep the clock rate up, you have to burn power.

What does this mean? The old-fashioned ways of getting more performance are dead--if you try it, the chip will burn up. It's easier to build two 1X MIP cores than one 2X MIP core. Like it or not, dual cores are the only solution; with transistor scaling, we'll have to go to 4, 8, and 16 cores in the next few years. IBM went dual-core with the PowerPC in 2001. Intel, AMD, and Sun are just following suit.

Not bummed out yet? Massive parallelism works well for people doing scientific computing, but for the average joe, it's useless. I don't care how fast a processor is--I usually have one task that will crush it--but rarely do I have two time-critical things to worry about at the same time. In the article referenced, they had to work hard to find things that would test the dual-core features. Parallel computing and multiple cores sounds great. History buffs will know about Thinking Machines, Meiko, Kendell Square, MasPar, NCUBE, Sequent, Transputer, Parsytec, Cray, and so on.... Not a happy ending.

So.... we can't get more single processor performance without bursting into flames. And parallel machines are only useful to a small market. IMO, it's gonna get grim. (And before anyone says new paradigm of computing to take advantage of the parallel resource, put down the crack pipe and think about it--we've been waiting for that paradigm for about 40 years. Remember occam? I thought not.)