Slashdot Log In
Dual Cores Taken for a Spin in Multitasking
Posted by
CowboyNeal
on Fri Apr 22, 2005 04:53 AM
from the burn-up-testing dept.
from the burn-up-testing dept.
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.
This discussion has been archived.
No new comments can be posted.
Dual Cores Taken for a Spin in Multitasking
|
Log In/Create an Account
| Top
| 221 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Newsflash... (Score:5, Funny)
(http://www.jawtheshark.com/ | Last Journal: Sunday November 11, @08:53PM)
(Dual core is the same as an SMP system, except the cores can communicate a bit faster with each other)
Re:Newsflash... (Score:5, Insightful)
(http://www.beezly.org.uk/)
I know this article is talking about Intel dual core chips, but for well-designed CPUs with integrated memory controllers (Power5, Ultrasparc IV, Opteron), the difference between a single dual-core CPU and two single-core CPUs is significant.
On chips with built in memory controllers, as you increase the number of cores on a chip the memory bandwidth per core decreases, however as you increase the number of chips in a system, the memory bandwidth per core remains the same and the number of cores increases.
That can amount to a big performance difference when running memory-intensive jobs.
Intel seem to be really losing the plot here at the moment. In multichip configurations, Intel's memory bandwidth already sucks compared to Opteron. Multicore per chip is only going to make it FAR worse.
shared FSB (intel) or not (AMD); other benchmarks (Score:5, Informative)
(http://www.baronams.com/staff/coats/)
For benchmarks relating to serious DB and web use, see this review by Anand Shempi: http://www.anandtech.com/cpuchipsets/showdoc.aspx? i=2397 [anandtech.com]
or these two at FiringSquad:
http://www.firingsquad.com/hardware/amd_dual-core_ opteron_875/ [firingsquad.com]
and http://www.firingsquad.com/hardware/colfax_dual_op teron/ [firingsquad.com]
Re:Newsflash... (Score:5, Informative)
(Last Journal: Tuesday April 12 2005, @07:06AM)
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.
Re:Newsflash... (Score:4, Informative)
FYI, it's called Gang Scheduling and has been described for quite some time.
A matter of time. (Score:5, Insightful)
(http://slashdot.org/)
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.
Re:A matter of time. (Score:4, Insightful)
Very few applications, and OS's in particular, are idle most of the time. I don't know the exact profiling characteristics of Windows, but I do know that in linux the kernel rarely, if ever, takes up 100% of a CPU's, and never does for a prolonged period of time.
If you locked one CPU and made that for OS tasks only you'd be wasting a lot of clock cycles that another application could happily use. Same would go for locking just about any application to a cpu.
Well... (Score:5, Interesting)
(http://keleus.freeshell.org/ | Last Journal: Sunday October 28, @02:17PM)
Re:Well... (Score:5, Informative)
(http://libtom.org/)
- Slightly longer scheduling buffers
- 128-bit L1 cache bus
- Larger instruction window (means it can feed the alus better when constants/etc are found)
- more registers [and they're bigger]
They also run cooler and takes less power than their k7 brothers.
Tom
Re:Well... (Score:5, Informative)
(http://libtom.org/)
No, I'm just a happy loyal user. I have both a Prescott P4 3.2Ghz and an AMD64 Newcastle 2.2Ghz...
For what I do [building software] the AMD64 smokes the P4
The AMD approach is just common sense. Be more efficient at what you do and gradually do it faster. Intel went the market route and said "slow clockrate is for pansies!".
So you end up with a cpu that has a higher clock rate but it doesn't win because the efficency is too low.
AES on my AMD64 ranges around 260 [or so] cycles/block. On the P4 with Intels compiler I get around 410 cycles/block. If you scale 3.2Ghz to 2.2 Ghz that's still effectively 281 cycles [at 2.2Ghz]. Doesn't seem like much but keep in mind to get this speed they had to draw more power and run at a higher clock rate.
I did a benchmark a week ago where I built LibTomCrypt with/without hyperthreading and it took the prescott with hyperthreading at 3.2Ghz to even come close to matching the AMD64 speed. That's only on ~45,000 lines of code.
Now multiply that by say five or ten to get a larger project.
I'm not saying the Prescott isn't a neat design. Overall it's efficient enough to be useful. Just the AMD64 eats it's breakfast and spanks it's mother is all I'm saying.
Tom
Re:Well... (Score:5, Informative)
Dual core means simply you have TWO processors running. Rember old reviews on SMP dual celeron A and other such reviews. It gives little for games, lots for certain multithreaded applications. As you have two processors running and doing things. And multitasking applications, like being able to run interactive application (doom 3), while system is doing some multihour compilation on background.
Anyway, it mainly keeps system more responsive when you have some thread or application takes CPU.
Also with lesser degree helps in some other similar situation, where CPU is tied up with something EXACLY same moment you would wan't it to deal with UI stuff.
Well? (Score:5, Funny)
Re:Well? (Score:5, Funny)
(http://www.epscylonb.com/)
Something missing (Score:5, Interesting)
(Last Journal: Wednesday July 26 2006, @04:50AM)
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.
Anandtech (Score:5, Informative)
(http://www.ringtones-database.com/)
Well worth a read:
http://www.anandtech.com/cpuchipsets/showdoc.aspx
One thought I had... (Score:5, Interesting)
(http://slashdot.org/)
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
Useful benchmarks (Score:1)
Their tests, doing such things as Anti-virus scans while performing other cpu-intensive tasks (e.g. Doom 3
Has anyone seen the various chip manufacturers roadmaps, with regard to the demise of their current ranges? My point is, I was amazed at how fast the AMD64 range replaced the Athlon XP. I wonder how long - realistically - it'll be before multi-core is "the norm"... less than a year?
JJ
Will my Spyware support these? (Score:2, Funny)
Yours,
Gator Fan.
Real comparison? (Score:1)
Sluuuurp..... (Score:3, Interesting)
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.
How 'bout some Adobe CS benchmarks? (Score:5, Insightful)
(http://www.designpoolstudio.com/)
if you ask me, the people that desperately need the ability to multitask are folks in the creative industry. Every 5 minutes bounce back and forth between massive applications rendering huge files.
Nothing sucks more then opening a 400dpi photoshop document and not having InDesign respond since your single core CPU is being bogarted.
SMP is probably the only reason I still find my crusty old Dual 450 g4 useful. It does things slowly, but it doesn't "feel" slow. If something is taking its sweet ass time, I can usually do something else without waiting years for windows and menus to draw.
Re:How 'bout some Adobe CS benchmarks? (Score:4, Funny)
And no, I'm not being sarcastic. Although I rarely do all of that at once, it has been known to happen. And don't even get me started about what happens when I have something compiling behind all of that. I'm just thankful, in a way, that since I don't do 3D work I'm not tossing Maya into that mix.
It's bad news, actually... (Score:5, Insightful)
(http://vlsicad.cs.binghamton.edu/~pmadden | Last Journal: Sunday October 09 2005, @10:00PM)
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.)
Re:It's bad news, actually... (Score:4, Interesting)
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.
Built in coffee pot! (Score:1)
"the XE 840 almost hits the 300 watts level under one"
Another plus! Demand for dual core laptops should give battery technology a new push.
Dual Core CPU's (Score:2, Interesting)
(http://www.antivoid.za.net/)
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.
OP Misses the point (Score:2, Insightful)
Except that this is a desktop processor, that won't be shipping in server systems. So in actual fact it's worth noting that the entire point is that each scenario consists of only desktop applications.
who cares? (Score:1)
why all the speculation and hoopla? (Score:2)
All these questions about whether Windows will usurp one of the cores or how to schedule the two cores seem positively bizarre, given that the answer is no different from dual processor machines.
There could be multi-core designs that can get better performance than multi-processor designs (cell attempts to be one), but this doesn't seem to be one of those.
Absolutely Perfect for multi-user systems (Score:1)
(http://opensensesolutions.com/)
These dual-cores are just another reason we feel that multi-user computing is going to be the efficient choice of the future, instead of everyone having their own high-powered machine. Single user machines will probably not take full advantage of the dual-cores for some time
These are great for our local multi-user approach, but will also help networked thin client approaches like LTSP. Having one processor or core per user isn't even necessary, just having the second core will do a lot to lower latency when one cpu is busy with a thread.
We can't wait to start putting them in our http://groovix.com/ [groovix.com] systems in June...
Simple (Score:2)
(http://www.google.com/ | Last Journal: Sunday December 08 2002, @02:00PM)
Memory bandwidth (Score:1)
some crazy thoughts (Score:1)
Re:Fundamental question about dual core (Score:2, Insightful)
(http://www.ronniesahlberg.com/)
The total number of cpy cycles are the same, but the average queue-length for a process waiting for the CPU is half, i.e. the latency before your process is scheduled is lower making it "feel" faster.
I don't understand what you're saying.. (Score:1)