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.
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.
For the average user , if i were to be totaly honest. Right now there is hardly any real use for either. Duel cores would probably help the system apear faster if the average user is switching around alot of programs ubt for the price you would pay then it is not worth your time.
64-bit well um if the average user um well runs a massive database setup but it will be more usefull soon in the x86 world (athlon 64 procesors though are excelent because of the onboard memory controler and architecture).
For the power user , well i don't think we need to explain this to the power users, In a server enviroment duel core and 64-bit computing is wonderfull for many many reasons also in workstations for many many enginering jobs.
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Mainly the difference would be found when running many apps at once. For example if you are ripping songs and playing a game simulataneously then it would be faster than a single core machine. I run many programs like proxy servers, mail servers etc. for the home LAN and also use it for games. So in this situation dual core will help me run the game lag free.
Although for the speed boost to materialize in games they will have to be coded to use both cores, so one dosent just idle away.. When more programs get SMP aware then dual core would be great!
The only problem righ now is, single core procs like amd64's can beat the crap out of dual core when tested mainly in single app environments because they have a higher clock speed.
Sad when its funny because its true. Windows pauses horrible when waiting for resources. Outlook/office when searching for printers, network shares loading for first time, removable devices, file explorer scanning a directory first time, etc.
Systems should never pause this bad, horrible design.
Has the new dual core opteron up against a quad Xeon with 8MB cache, amongst many others.
? i=2397
Well worth a read:
http://www.anandtech.com/cpuchipsets/showdoc.aspx
No Norm, those are your safety glasses; I'll wear my own thanks...
AMD64 carries more than just "bigger registers". It has more of them and the actual core is an overall improved K7 process with
- 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
Someday, I'll have a real sig.
The 64bit is for anyone with more than 2Gb of RAM + x86-64 gives you more registers besides being 64bit so it speeds up the recompiled code.
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.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
The fact is, when you have only one problem to solve, a single fast CPU is always better than an equivalent count of slower CPUs. One 1GHz CPU is better than 2 512MHz CPUs of the same design, for solving a single problem.
It's another fact that it's easiest for humans to analyze only one problem at a time. So the most straightforward way to handle any computing task it to crunch at it linearly from beginning to end.
Unfortunately, gains in raw CPU speed have always come slower than the demand for number-crunching power, which is why there have been so many parallel supercomputer designs over the past couple decades. And again unfortunately, the only way to get good performance out of those designs is by explicitly coding for parallel processing. And that's hard for humans.
The bottom line is that when you throw two 1GHz processors at a problem, your time to solution is not twice as fast as using one 1GHz processor. There are overhead costs associated with reallocating the problem and managing the increased number of processors. But, it *is* still faster than using one 1 GHz processor.
Scale the numbers up as appropriate.
Still, it was fun watching the blinking lights on our Connection Machine, a decade or so ago...
-- *My* journal is more interesting than *yours*...
.... Me work for AMD? Ha!
... and does it without getting to 50C or so...
;-)
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
Someday, I'll have a real sig.
Hi, my older PC was a T-Bird@850Mhz with 256 RAM, 160GB HDD- PATA133 (CPU was working at 50 deg C)
Now I have Athlon64 3000+ (233x8 = 2000MHz) (s939) with 1GB RAM, 200GB HDD- SATA150 (CPU does not go beyond 37 deg C)
The difference is that with the older pc I compiled and installed LinuxFromScratch in 4 days (well I drank a lot of caffeine products),
while when I switched to the A64 PC I did the job IN ONLY 4 Hours!
Unfortunately I was unable to compile a stable x86_64 toolchain to complile a x86_64 Linux and now I have i386/i686 GNU Linux but hell it is fast and I love it!
sex is better than war!
For benchmarks relating to serious DB and web use, see this review by Anand Shempi: http://www.anandtech.com/cpuchipsets/showdoc.aspx? i=2397
or these two at FiringSquad:
http://www.firingsquad.com/hardware/amd_dual-core_ opteron_875/
and http://www.firingsquad.com/hardware/colfax_dual_op teron/
"My opinions are my own, and I've got *lots* of them!"
Extremetech have a review of AMD opteron dual core http://www.extremetech.com/article2/0,1558,1788685 ,00.asp?kc=ETRSS02129TX1K0000532
Comment removed based on user account deletion
Actually several of the articles do mention heat and the answer is this. Total thermal output from the top end dual core opteron is no more than for the top end single core processor (95 watts max). This has been achieved by using more energy efficient (and slightly lower perfomance) transistor designs in certain areas. AMD appears not to be doing any thermal throttling either.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
Firefox might not be such a bad benchmark. Go a bunch of Japanese pages with status bar scrollers (in japanese) then open up about 20+ tabs. I do this every day, and the CPU usage on Linux can go up to a sustained 70-90% or more. If gcc is working in the background, the system can really lack responsiveness (and I'm on an AthonXP 3000 with 1Gb of RAM). Out of all the apps I use, Firefox and Mame take the cake in CPU usage.
That's NUMA - if your OS is NUMA aware it should try to place processes on the same processor as the memory that contains their data.
But yes, you're right, processes accessing memory on a different processor will suffer a latency (and to some extent bandwidth) hit. A well designed OS will help to mitigate it to some of the extent, but it's one of the reason that CPUs don't scale linearly.
Actually, the opposite. Two processes that communicate quite heavily SHOULD be run together on two processors, especially since they will share memory and thus cache lines, plus they can spend time spinning on a lock instead of swapping threads. Given short locks and equal speed, they can work a whole lot more efficient on a dual-core than on a single-core.
FYI, it's called Gang Scheduling and has been described for quite some time.