Slashdot Mirror
AMD Demos Dual-Core Athlon 64
DigitumDei writes "Dual core chips came closer to reality as AMD demonstrated their Athlon64 dual-core offering. The 90nm technology chip will use the same 939-pin infrastructure and cooling solutions as the current Athlon 64 chips, meaning that upgrading to a dual-core chip from your current AMD64 will require little more than a BIOS update. Available in the second half of this year, the chip will be added to AMD's current line (Athlon64, Athlon FX, Sempron)."
HT is a way of letting one processing unit work with mulitple threads at once. Multi-core technology is identical to SMP, meaning more physical processors actually doing work, so it isn't token.
However, expect lower clockspeeds, two cores in that proximity causes a severe power/heat problem that would mandate reduced clock over single processor solution.
XML is like violence. If it doesn't solve the problem, use more.
Before you buy one of these dual-core processors for your server, make sure that your software vendor isn't going to double your price on you.
Oracle and others have announced plans to increase their revenue by charging people for multiple cores in their single processor.
I'm a big tall mofo.
You should probably get your terms right before you comment on it. HT is simply Intel's name for SMT (simultaneous multithreading). They didn't choose an optimal implementation and people shouldn't expect the same performance from it as you would from dual processors. SMT is simply an extension of the superscalar idea. Disconnect the dispatch mechanisms from the execution mechanisms and you can run an out of order processor a lot faster than an in order. Make multiple execution units and multiple fetches per cycle and you now have an n-way superscalar. A few more additions (mostly replication of units in the processor) and you can grab instructions from multiple threads instead of from the same thread (it is difficult to get lots of instructions per cycle from the same thread because of the high frequencies of branches in the code stream - and branch prediction isn't perfect). Dual core is completely different, they simply put two processors on the same chip. Dual core has the problem that it cannot share the same resources between the two threads. The resources (execution units, queues, etc.) are partitioned x amount for thread 1 and x amount for thread 2. The designs are really very different, depending on the use, sometimes dual core is better, sometimes SMT is better. AMD's planning on bring out Dual Core SMT where each core will have 2 threads running through it for a total of 4 thread running simultaneous. If you want more information about this "throughput computing" google for Sun's Niagara chip.
they don't offer much of any performance benefit in most apps (particularly games)
Ah, rejoice irresponsible youth! Right now a $25,000 8 CPU machine that can no longer keep up with a decent sized corporate database needs to be replaced with a $60,000 16-CPU machine. After dual core hits the market, it can be upgraded for the price of 8 new dual-core CPUs and a BIOS flash. Less money for hardware == more money for bonuses... W00T! W00T!
meaning they don't offer much of any performance benefit in most apps (particularly games). They draw more power, they run at higher temperatures, etc.
from TFA:
For example, a processor with dual 2.0-GHz cores can deliver performance not all that different from a single-core 3.5-GHz part. More important, such a dual-core part will hold down power dissipation to a figure closer to that of a standalone 2.0-GHz CPU, allowing processing throughput to effectively double for not much more power.
and
At such speeds, single-CPU processors can often dissipate more than 150 W.
The dual-core Athlon 64 runs at a clock-speed of 2.4 GHz and has a maximum power dissipation of 100 W.
hack a day
Typically 517 of those threads are asleep waiting for IO or a signal, and the one piece of information that you are currently waiting for is being processed in the single remaining active thread.
You can use an affinity tool to put your process on a single processor alone, and everything else on the other. This all but eliminates context switches in your program's context, while all other processes can continue to run on the other core(s). The only thing that consumes a lot of CPU that is not typically multithreaded is game software. Eventually, this too will be multithreaded, as we see more multi-core systems out there.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Now, also, how many OSs (and applications) are prepared for dual-core support? Are there any available systems that are stable and do that?
Microsoft Windows 2000 and XP support 2.
Apple OSX supports 2.
FreeBSD support 4 (or more?). NetBSD supports 2 (or more?). OpenBSD is working on it (last I knew).
Linux 2.4.x and 2.6.x support 2+.
Sun Solaris has support 2+ for as long as I know.
AIX, HPUX, SCO Unix and all those support 2+.
Did I miss any?
Almost all OSes for the last several years have supported multiple processors natively. At worst these OSes would need a patch to update their SMP awareness.
Applications on the other hand, well they've been slower to change to a multithreaded moddel. Many server grade programs are ready. Most common desktop programs are not.
I have used a dual Athlon MP system for a long time now. The biggest difference I can tell you between dual 1.6GHz and single 3.2Ghz is that one process can not take over the processor. Even with modern preemption I can tell the difference when I have a second CPU processing my clicks and keystrokes. All I can say is "try one for a while, you'll get hooked".
FreeBSD: The Power to Serve!
The main problem with this is that the processors share a clock tree and arbitration logic - if the clock multiplier is contained in the arbitration logic, then having one core at one speed and another at a different speed would be impossible.
If the clock multiplier is contained separately in each core, it would be possible - however, having different clock ratios on each core would considerably complicate the arbitration logic, since it would have to deal with different setup and hold timings when sending data to one core vs. the other - this would probably greatly increase your chances of inducing a processor error.
Trying to do this could also require a great deal more design difference between the two cores, which might cause many problems. It also would make it much more difficult to sell single core versions of dual core chips (i.e. one core fails, the other core is good - blow a few fuses to get the chip to look like a single core chip, and sell at as a single core)
>Money would be better spent on RAID, rather than dual core or dual processor.
You're right about that.
Unlike CPUs which become worthless in less than 2 years, RAID h/w last a bit longer.
Some five years ago I bought an Ultra2Wide SCSI 320 card and a (at the time big) 8GB HDD - I paid $400 for the card and $250 for the HDD.
I still use the card - I haven't checked but it should be as fast as SATA II I guess - and the SCSI disk works too (although it's quite useless - I use it as dedicated swap disk).
In the meantime I went thru 3-4 generations of motherboards and CPUs (consecutive 100% wipeouts) and my RAID stuff still rocks...
By year's end I'll go not for a dual core CPU system but for what's today top of the line nForce4 system. Screw the hype.