Gr8Apes writes "AMD has showcased their new 65nm Barcelona quad-core CPU. It is labeled a quad-core Opteron, but according to Infoworld's Tom Yeager, is really a redefinition of x86. Each core has a new vector math processing unit (SSE128), separate integer and floating point schedulers, and new nested paging tables (to vastly improve hardware virtualization). According to AMD, the new vector math units alone should improve floating point operation by 80%. Some analysts are skeptical, waiting for benchmarks. Will AMD dethrone Intel again? Only time will tell."
Things have come a long way since the heady days of bit slice processors. The first microcode I wrote was for an XOR operation - I could not think of anything simpler, that would actually do something useful...
SSE+ operations up until now were operated on 64 bit at a time within the processor. SSE128 just means the new AMD chip will complete a SSE instruction in one pass.
This was pretty much the reason why most people only bothered with MMX optimizations in their applications.
SSE+ operations up until now were operated on 64 bit at a time within the processor
Hmm...do you mean specifically on AMD's hardware? That stopped being true for Intel starting with the Core, which has 1-cycle latency on SSE instructions.
Hmm...do you mean specifically on AMD's hardware? That stopped being true for Intel starting with the Core, which has 1-cycle latency on SSE instructions.
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency. Most of these instructions still take 3-5 cycles to generate results, which is similar to the Pentium M, but now a vector of results finishes every cycle, instead of every two or four cycles.
An important consequence of this is that if your instructions are poorly scheduled by the compiler (or assembly programmer) and the processor spends too much time waiting for results of previous operations, the advantages of single-cycle throughput mostly disappear.
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency
Well, certainly you won't be able to get a square root through in one clock cycle, but many/most of the simple integer arithmetic, bitwise, and MOV SSE instructions on the Core 2 really do have single cycle latency. source [agner.org]. None do on the AMD64, which supports the theory that SSE128 means more "new for us" than "new for everyone." Not to put AMD down - many of the other features sound promising (but the article is long on breathlessness and light on details, alas).
When Intel first added SSE to the Pentium 3 chips, they did it with a 64bit setup to save die size on the then 350nm parts. Even when they moved to the newer smaller designs, they left it that way. The Core2 was the first chip to incorporate a single issue SSE engine. Therefore, with the Core2, it loads the instruction, then executes it. With the other chips, you have to load the first part(if it's a full 128bit instruction, or if it's multiple instructions added together), save, load, save, add, execute. This is where the Core2 kicks butt. I've been saying that the Barcelona would move to that design, since it's the biggest reason Intel has been beating AMD in the benchmarks. This will re-level the playing field. There have been lots of articles about this. Google it
With the other chips, you have to load the first part(if it's a full 128bit instruction, or if it's multiple instructions added together), save, load, save, add, execute.
Please explain this. Do I understand correctly that you think some SSE instuctions are 16 bytes? Issuing is one thing, and latency another. In most cases I've found AMD/Intel can issue 1 mulps/shufps/adds per cycle, the *ss instructions at 2 per (AMD sometimes 3 per cycle). If you mean that only the first 64-bits, 2 components, are
No but a good hard, well aimed, holding nothing back kick in the nuts can leave them impotent, so they'll have to do some ugly procedures to survive it in the long run. A couple of identical blows in the meantime could leave them sterile, so if the current setups begin to die out. And Intel had no more babies waiting anymore, they will not be dethrowned, but will be getting an hounerable mention in the history books.
As long as AMD and Intel continue to chase each other in the x86 market, high end chips become low end in the span of six months. Just keep buying 6 months behind the press releases and you get great processors for next to nothing.
It is labeled a quad-core Opteron, but according to Infoworld's Tom Yeager, is really a redefinition of x86.
I don't get the surprise or disapointment here. It appears that the submiter thinks x86 isn't an opertron or something. As far as i know, the opertron is the same thing- IE and extention to the x86 that can handle 64 bit extentions.
Keeping in scientific fact, how much heat has to be generated for 1 MIPS? The fact is, absolutely none. It has been shown that only the destruction of information via AND and like instructions create entropy (heat). As long as you use only 3 types of gates (pass through, not, xor), you can create a heat-free CPU. Provided we do want to check for bit errors, we could maintain a very low heat via ECC like checking. Estimates on that are 10^8 lower than present.
We could keep 98% of our efficiency of current day
Heat-free?
Did you forget the Second Law? Or did you just forget about pure friction itself? Moving ANYTHING is going to involve friction. Nothing moves without SOME force, and friction will happen.
---That sounds very interesting. Would you mind providing a link to the literature that discusses that ? I have some trouble figuring out the thermodynamics of this. Perpetum mobile and such, you know....
Of course. It, at first, sounds too good, but here you go.
Rolf Landauer showed in 1961 that reversible logic operations could be performed by neither using energy or taking heat out. The same could not be said for irreversible logic operations.
"Irreversibility and Heat Generation in the Computing Process" IBM Journal of Research Development 17 (1973): 525-32, IBM PDF [ibm.com]
___
In 1973, Charles Bennett proved that any computation could be derived from purely reversible computing.
Charles H. Bennett "Logical Reversibility of Computation" IBM PDF [ibm.com]
___
Later on, Fredkin and Toffoli presented a review of the ideas of reversible computing. The essential idea is that you can save all intermediary states between an algorithm to get the answer, and then reverse the process so that no energy is used, and generated no heat. Fredkin also indicates that if we switched from irreversible to reversible computing, we would expect to lose no more than 1% efficiency.
International Journal of Theoretical Physics 21 (1982):219-53 PDF [digitalphilosophy.org]
___
And as an unsubstantiated claim, I remember hearing that due to heat/radiation sources, that volatile memory gains errors of 1 bit per billion with a time from 1 minute to 1 day ( I forget the exact time). To correct this would only require the entropy of deleting that incorrect bit. In other words, 10^8 or so magnitude heat shrinkage. But trust the stuff above.
(Many of these ideas were taken from "The Singularity is Near" by Ray Kurzweil from page 130)
And how exactly is your reversible computing going to reduce the resistance of millions and millions of conductors to 0. You are confusing a theoretical issue relating to computer science (and very relevant to quantum computing) with a practical problem of a CPU design. Just moving information around _without_ deleting it will generate heat.
Or did you actually think that those "stupid" CPU designers for all this years, battling with heat dissipation, never thought of, oh.. simply replacing the nand gates with reversible Fredkin and Toffoli gates and 'poof' magically all the heat issues are gone, processors will run @ hundreds of GHz, the wold's electrical power consumption will go down and the geeks won't be able to boast about their huge ass sinks anymore...
In my own benchmarks (generic C integer and floating point scientific code) I have found that the Core Duo and Core 2 Duo aren't all that quick compared with an AMD64. Clock for clock the AMD64 Opterons we have are about 50% quicker than an equivalent Core 2 Duo for integer work. I know this doesn't agree with all the usual magazine benchmarks but they are heavily biased towards using SSE instructions where possible and it is SSE where the Core 2 Duo has been a real improvement over previous Intel designs and also bests the AMD chips. Hopefully, AMD has recognised this and the new SSE implementation will bring them back on par with Intel for these benchmarks but even today an AMD64 processor is a beast and more than a match for anything Intel produces.
Care to publish your numbers that debunk all the other hardware sites that are typically AMD-biased anyways? And pointing out that it isn't fair to compare because a Core2 duo already executes the full SSE instruction in one pass vs. the 2 clocks for a curret AMD64 is the same as saying it's not fair to compare the on-die memory controller on AMD's vs. Intel's FSB. But people didn't seem to care when the numbers went in AMD's favor.
I'd really be interested in seeing your numbers, your programs, and what com
"Care to publish your numbers that debunk all the other hardware sites that are typically AMD-biased anyways?"
OK. I can't give you the code but it is my own implementation of a pretty standard bioinformatics sequence comparison program which doesn't use SSE/MMX type instructions and is single threaded. On all platforms it was compiled using gcc with -O3 optimisation. I have tried adding other optimisations but it doesn't really make much difference to these numbers (no more than a couple of percent at best).
AMD Opteron 2.0Ghz (HP wx9300) - 205 Million calculations per second Intel Core 2 Duo 2.66Ghz (Mac Pro) - 146 Million Intel Core Duo 2.0 Ghz (MacBook Pro) - 94 Million IBM G5 PPC 2.3 Ghz (Apple Xserve) - 81 Million Motorola G4 PPC 1.42 Ghz (Mac mini) - 72 Million Intel P4 2.0 Ghz (Dell desktop) - 61 Million Intel PIII 1.0 Ghz (Toshiba laptop) - 45 Million
Interesting things about these numbers. The Core Duo is clearly a close relative of the PIII since the performance at 2Ghz is roughly twice that of the PIII at 1Ghz. The P4 at 2Ghz is really very poor indeed which isn't a huge surprise as it was never very efficient. The G4 PPC puts in a reasonable result easily beating the much higher clocked P4 (what, the Mac people were right? Shock!) although I have to say that the performance of the G5 is disappointing. The Core 2 Duo isn't a bad performer although it does have the highest clock speed of any processor in this set but it is seriously beaten by the Opteron. From these numbers, a Core 2 Duo at 2Ghz would be about half as quick as an Opteron at the same speed.
OK. I can't give you the code but it is my own implementation of a pretty standard bioinformatics sequence comparison program which doesn't use SSE/MMX type instructions and is single threaded. On all platforms it was compiled using gcc with -O3 optimisation. I have tried adding other optimisations but it doesn't really make much difference to these numbers (no more than a couple of percent at best).
When you say you've tried "adding other optimizations," are you referring only to other GCC optimization flags? If your program's algorithms have any moderate degree of parallelism and you haven't tried vectorization either by compiler (GCC and ICC can both do this) or by hand, the benchmark you've done is not unlike a race where no one is allowed to shift out of first gear. Can you go into any more specifics about how this program does sequence comparisons?
Also, the disappointing numbers from the G5 may be partially explained by the fact that its integer unit has higher latency than the other desktop processors in that list. The G5 isn't exactly known for blistering integer performance, anyway.
AMD64 is not a processor, it is an instruction set. So you need to clarify whether you compiled your programs using 32-bit or 64-bit x86 instructions. I am not a gcc user, but I'm assuming that it chooses the default architecture based on your environment settings, thus AMD64 on 64-bit Linux. Since you've included a PowerPC processor, its really not obvious. When the Core2 was released, benchmarks made it clear that Intel did not optimize for 64-bit performance. They have the architecture, but they pushed th
"The P3 you list looks a Coppermine, I suspect a P3 Tualatin would perform much better."
Pretty sure it is a Tualatin since it is a 1Ghz PIII Mobile which I bought in early 2002 (http://www.theregister.co.uk/2001/01/31/chipzilla _readies_1ghz_mobile_piii would seem to support this).
Given that it is a Tualatin, then the peformance of the Core Duo at 2Ghz looks about right. The Core 2 Duo gets about 10% better performance clock for clock from all the blurb I have read except when it comes to SSE where it is about twice as fast so the performance figure of 146 million also looks pretty much on the mark too as a 2Ghz Core 2 Duo should be able to manage about 110 million if you scale the figure for clock speed and that is (surprise) ~10% quicker than the Core Duo at 2Ghz (94 million) so the basic integer performance of the Core 2 Duo is better than the Core Duo but doesn't compare with the 205 million the 2.0Ghz Opteron manages.
"Actually I was thinking more about benchmarking/coding flaws than lying from your part." Certainly a possibility. In my defense I would like to point out that all benchmarks are open to question. I know my own code, I know what it does and it doesn't do much but it does a lot of it so the performance figures are what they are. I originally wrote this code on an SGI, ported it to Linux on a 486, SPARC, Alpha, PPC and so on. Its old and simple but does real work. While I could make it faster using SSE an
"This guys little application does tons of random memory reads" If only that was the case but actually it is very linear. The application can hold the whole of its memory requirements in cache these days so it hardly has to touch main memory and it was designed to do all the inner loop code using only registers. Heck, I doubled the size of the inner loop just to avoid a single register copy because it made a significant performance increase.
The reason I like this code is that it shows how many operations y
"perhaps you need to write some more cache efficient code to test with. goto BLAS can feed the beast like no other." goto BLAS uses SSE so doesn't count. It has already been acknowledged that the SSE implementation of Core 2 Duo is very good. The new AMD chips may address this but we won't know until we see the benchmarks. For non-SSE the Core 2 Duo is a little better than the Core Duo which was similar to the PIII/PII/PentiumPro clock for clock. The current Opteron is much quicker clock for clock for no
I dont think I've ever read such an admiring review of a CPU design. Last time I remember a chip sounds so fantastic was the Alpha or something like ten years ago. If a lot of all the new things really work the way they sound in theory, well then yeah I guess it's evident this Barcelona thing is really going to be something else.
The design for VW performance sounds extra interesting
Each of Barcelona's four cores incorporates a new vector math unit referred to as SSE128
SSE has always been 128bit (the 64bit simd extensions were called MMX). AMD used to funnel the instructions through a 64bit execution unit by splitting the work into two halves, the new core has a full 128bit SSE pipeline so doesn't need split the operations. Nothing new here, just a faster internal implementation. Can this deliver and 80% improvevment in benchmark performance? - quite possibly. Take a look at the Core2 FP perfromance numbers - it also has a full 128bit implementation of SSE.
And separating integer and floating-point schedulers also accelerates this thing called virtualization
Huh. Hardware virtualization affects how the processor handles certain instructions such as priviledged operations. FP instruction execution is unaffected. Virtualized workloads will benefit no more than non-virtualized workloads. Separate issue queues are good but does it specifically benefit virtualization? - no.
Barcelona blacks out power to individual portions of the chip that are idled, from in-core execution units to on-die bus controllers. This hasn't made it into PCs before...
Barcelona is genius, a genuinely new CPU that frees itself entirely of the millstone of the Pentium legacy.
Barcelona is a new CPU, not a doubling of cores and not extensions strapped on here and there.
Barcelona is an Opteron, with a doubling of cores and some extensions strapped on here and there.
I'm not meaning to detract from AMD here - the fact that they have still not had to make any radical changes to the opteron micro-architecture is a testament to the quality of the original design.
They are slightly ahead of the game on virtualization - they're going to beat Intel to nested page tables - but other than that this chip is playing catchup. Overall this is going to be a very nice piece of kit to work with. But nothing radical and new here.
Actually, if you go waaaay back to the Socket 7 days you could have L3 cache as well. The AMD K6 and K6-2 CPUs only had on-die L1, and the L2 cache was on the mainbaord. But the K6-3 CPU had 256KB or 512KB of on-die L2 and was compatible with the same mainboards. So when you put that K6-3 in a socket 7 mainboard the mainboard's cache actually functioned as L3. Sure it wasn't on-chip, but L3 cache
I fully agree, the article is mainly empty of information - it took words from AMD briefings and produced a meaningless salad. Now, as far as some claims, in detangled order:
FPU boost: this seems to be based on several things - one is the obvious widening of SSE2 issues. Others are increasing instruction fetch from 16B/cycle to 32B/cycle, making the FPU scheduler 128bit, unaligned loads and a doubling of cache bandwidth.
Virtualization: Nested page tables and reduces witching times for the hypervisor.
Nested paging tables is a per-core feature that will light the afterburners on x86 hardware virtualization. A paging table holds the map that translates virtual memory addresses to physical memory addresses, and each CPU core has only one. Virtual machines have to load and store their page tables as they get and lose their slice of the CPU. AMD solved the problem with nested paging tables. Simplified, each VM maintains its own paging table that stays fixed in place. Instead of loading and saving paging tables as your system flips from VM to VM, your system just supplies Barcelona with the ID of the virtual machine being activated. The CPU core flips page tables automatically and transparently. This is another feature that's implemented for each core.
Context-switching has long been the weakest design point for x86 in "PCs", especially servers. x86 arch is rooted in single-user, single-threaded, single-context apps. The in-core registers that CPU operations execute directly against have to be swapped out for each context switch. In *nix, that means every time a different process gets a timeslice, it's got to execute two slow copies between registers and at best cache RAM, at worst offchip RAM (over some offchip bus). If the register count is larger than the bus width (even onchip), that's another multiple on that slow cycle. That context-switch overhead can be larger than the timeslice allocated to each process's "turn" in the schedule for lower-latency / higher-response (lower "nice") processes, approaching realtime.
Unix was designed for multiusers, context-switching from the beginning. The chips it's run on coevolved with it. Linux arrived when x86 CPUs ran fast enough that context-switching was OK, but still a big waste compared with, say, MicroVAX multiple register sets. Windows architecture is rooted in the x86 architecture that DOS was designed for, though perhaps Vista has finally lost all of the old design baggage originated in the 8088/8086, but its long history of UI multitasking means it's context-switching all the time, which will gain in speed. The MacOS switch to BSD means it's got lots of power bound up in the context switches that could be released with Barcelona.
So while low-level benchmarks might show something like 80% FPU improvement, the high level (application) performance could improve quite a lot more. Recompiling apps to machine code that exploits more registers without the context-switching penalties could find multiples, especially apps with realtime multimedia that run concurrently with other apps. Intel's hyperthreading already gets past some of these bottlenecks in distributing tasks among multiple cores, but the Barcelona paging tables go even deeper, for likely extra performance (on top of Barcelona's own hyperthreading and new L3 cache).
Aside from the marketing "vapormarks" we'll surely see out of AMD (and their sockpuppets) before it's actually released "midyear", I'm looking forward to seeing how this thing really runs in multitasking apps. I'm expecting "like a greased snake across a griddle".
I don't care if it's 65nm, 45nm or 10mm - that's a completely irrelevant (to me as a user and purchaser) implementation detail. I care about the results - how fast is it for my workloads? How much is it? How much power does it use?
Obsession about process size is sillier than obsession over clock speeds.
If AMD can produce a better performing chip at 65nm, then who the hell cares if Intel - or anyone else - move to a 45nm process?
I would care. POWER CONSUMPTION/EFFICIENCY. If I want a space heater, I'll stick with a 3.4 GHz P4 with HyperThreading. I DON'T WANT ONE.
As it is, for what I like doing and for what I want to do, current-gen processors work just fine. I can play my games, make my music, draw shit, upload data, and check out sites like this, while maintaining my bank account, talk with other people, and more, at the same time.
I got over the clock speed thing the second I actually owned a G3. Granted, Windows emulation su
Clock speed doesn't mean crap anyways. It's all in the code. I see guitar tuning programs for the computer... TEN megs in size, slow as hell, and inaccurate! I believe APTuner is FAR smaller than most, faster and far more accurate. People just don't know how to code, plus the fastest ways to code are copyrighted, which they shouldn't be since they'd be utterly obvious to any programer with that standard "ordinary" knowledge in that language, so one has to make workarounds that inevitably end up being slower
the fastest ways to code are copyrighted, which they shouldn't be since they'd be utterly obvious to any programer with that standard "ordinary" knowledge in that language
An individual implementation can be copyrighted. A way of doing something can't be covered by copyright, and needs to be patented. That's what you meant, right?
I don't care if it's 65nm, 45nm or 10mm - that's a completely irrelevant (to me as a user and purchaser) implementation detail.
This is Slashdot. We care about those details. You can read more about the "super fast, super cool, super cheap!" market speak on the company's official press releases section.
If AMD can produce a better performing chip at 65nm, then who the hell cares if Intel - or anyone else - move to a 45nm process?
Feature size has denominated progress (as measure either by raw performance or performance per watt) over an unbroken 30 year period. Do you recall the very passionate debates about RISC vs CISC? Did a RISC design at one feature size ever beat a CISC design at the next shrink? I think not. Design has never mattered anywhere near as much as feature size. Not that you can't get design wrong. But then you can get a shrink wrong, too, and end up with 1% yields. AMD managed briefly to remain competitive with Intel playing a full shrink behind when Intel did that rather stupid marketron-driven face-plant into the thermal wall (against good advice from their Israel team, who later came to the rescue with Core Duo).
With the recent skyrocket of leakage current, the holy grail of feature size is somewhat tarnished, but it still dominates the performance curve. You completely missed the relationship between feature shrinks and the performance crown. If Intel has better process technology than AMD (almost always) and AMD has a better design (most of the time since the Athlon was first launched) and both companies shrink every 18 months following the Moore projection (that unbroken 30 year historical trend) and AMD always shrinks 9 months behind Intel, then the performance crown will pass back and forth exactly as often as either company announces their next product.
So I agree with you: feature size has no importance to the customer who wants performance for their dollar. Except that you can set your clock by it and project ten years into the future effective performance levels of shrinks we haven't even seen yet. Except for that part, yeah, I'm with you.
If AMD can produce a better performing chip at 65nm, then who the hell cares if Intel - or anyone else - move to a 45nm process?
They care. Just moving the chip from 65 nm to 45 nm means you can produce twice as much on the same silicon wafer. Also, if a 65 nm chip performs well, then a 45 nm version of it (with slight modifications of course) will work even better.
45nm is not inherently "better" than 65nm any more than 3Ghz is inherently "better" than 1Ghz. A smaller process size is a means to an end, it's not an end in itself.
The end is the delicate balance of improving power / watt while increasing overall performance and keeping the price down. If AMD can deliver a chip that does a better job of that at 65nm than an Intel 45nm one, then the AMD chip is not somehow "worse" than the Intel one just because it doesn't use 45nm. That's just stupid.
I'm not saying AMD can do that, but I think that criticizing them for not being ready for 45nm yet is more than premature. AMD's actually guilty of the same flawed logic though - their criticism of Intel's 4 core processor being just 2 dual cores stuck together is just as pointless. It doesn't matter what matters is how well the processor meets the requirements of its target market.
Likely Intel has an edge because they are [almost] ready for 45nm process, while AMD is just getting started on 65nm. But it is interesting to see the two companies approach the problem from different ends. Do you improve the silicon process or do you alter the architecture and instruction set? I bet you the best answer will be to do both.
quad cores that actually share cache would be nice. these double duals kind of suck because architecturally they can never share cache. although AMD and Intel don't have ve
The problem I have with performance/watt is that it distorts the true "value" to the system owner. You NEED to break it down, because while power usage is important, the real issue comes down to "is the higher performance WORTH the extra power the chip draws". I personally don't CARE about performance/watt, except when the power draw is excessive, and I believe that is how MOST people will look at it. Most laptop processors have a higher performance/watt than desktop processors because they are designed
Actually, from the important perspective of the difficulty of building a new machine around it, the Intel "dual-dual" core chips really are quad core -- they drop into the same socket as the previous dual core chip, placing four cores into the socket. That certainly helped speed the time to market for the chip.
by Anonymous Coward
on Saturday February 10 2007, @03:54AM (#17960940)
Three quad cores for the pasty-nerds under the sky, Seven for the WoW-nerds in their halls of stone, Nine for Diablo Men doomed to die, One for the Dark Nerd on his dark throne In the Land of Silicon where the corporations lie. One quad core to rule them all, One quad core to find them, One quad core to bring them all and in the darkness bind them In the Land of Silicon where the corporations lie. He paused, and then said in a deep voice, This is the Master-quad core, the One quad core to rule them all.
I will not surprised if AMD dethrones Intel again. It is a classical Intel vs. AMD battle...
I am not sure Intel ever did beat out AMD.
I went down to Best Buy where the Intel rep was hard peddling a Code Duo 2 machine and compared his $1500 machine to a AMD X2 clearance one for $600. I had nothing to do that day but be a clown, so I went and got a DVD with software on it, and said these are both XP right? Copy the contents to the hard drive and compress it. I am going to measure it. Core Duo 2 result
Bit Slice (Score:2)
But SSE is already 128 bits! (Score:2)
Re:But SSE is already 128 bits! (Score:5, Informative)
This was pretty much the reason why most people only bothered with MMX optimizations in their applications.
Parent
Re: (Score:2, Interesting)
SSE+ operations up until now were operated on 64 bit at a time within the processor
Hmm...do you mean specifically on AMD's hardware? That stopped being true for Intel starting with the Core, which has 1-cycle latency on SSE instructions.
Re:But SSE is already 128 bits! (Score:5, Informative)
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency. Most of these instructions still take 3-5 cycles to generate results, which is similar to the Pentium M, but now a vector of results finishes every cycle, instead of every two or four cycles.
An important consequence of this is that if your instructions are poorly scheduled by the compiler (or assembly programmer) and the processor spends too much time waiting for results of previous operations, the advantages of single-cycle throughput mostly disappear.
Parent
Re:But SSE is already 128 bits! (Score:5, Informative)
Core2 has single-cycle throughput on most SSE instructions, not single-cycle latency
Well, certainly you won't be able to get a square root through in one clock cycle, but many/most of the simple integer arithmetic, bitwise, and MOV SSE instructions on the Core 2 really do have single cycle latency. source [agner.org]. None do on the AMD64, which supports the theory that SSE128 means more "new for us" than "new for everyone." Not to put AMD down - many of the other features sound promising (but the article is long on breathlessness and light on details, alas).
Parent
Re:But SSE is already 128 bits! (Score:5, Informative)
Parent
Re: (Score:3, Interesting)
Please explain this. Do I understand correctly that you think some SSE instuctions are 16 bytes? Issuing is one thing, and latency another. In most cases I've found AMD/Intel can issue 1 mulps/shufps/adds per cycle, the *ss instructions at 2 per (AMD sometimes 3 per cycle). If you mean that only the first 64-bits, 2 components, are
Dethrone? No. (Score:2, Insightful)
Re: (Score:2, Interesting)
so they'll have to do some ugly procedures to survive it in the long run. A couple of identical
blows in the meantime could leave them sterile, so if the current setups begin to die out.
And Intel had no more babies waiting anymore, they will not be dethrowned, but will be getting
an hounerable mention in the history books.
GPU not CPU - Re:Dethrone? No. (Score:3, Insightful)
Is dethroning Intel the point? (Score:5, Insightful)
As long as AMD and Intel continue to chase each other in the x86 market, high end chips become low end in the span of six months. Just keep buying 6 months behind the press releases and you get great processors for next to nothing.
Huh? (Score:2)
Am i missing something or am i completly wrong?
Well.... (Score:2, Interesting)
The fact is, absolutely none. It has been shown that only the destruction of information via AND and like instructions create entropy (heat). As long as you use only 3 types of gates (pass through, not, xor), you can create a heat-free CPU. Provided we do want to check for bit errors, we could maintain a very low heat via ECC like checking. Estimates on that are 10^8 lower than present.
We could keep 98% of our efficiency of current day
Re: (Score:2)
Re: (Score:3, Informative)
Re:Well.... (Score:4, Interesting)
Of course. It, at first, sounds too good, but here you go.
Rolf Landauer showed in 1961 that reversible logic operations could be performed by neither using energy or taking heat out. The same could not be said for irreversible logic operations.
"Irreversibility and Heat Generation in the Computing Process" IBM Journal of Research Development 17 (1973): 525-32, IBM PDF [ibm.com]
___
In 1973, Charles Bennett proved that any computation could be derived from purely reversible computing.
Charles H. Bennett "Logical Reversibility of Computation" IBM PDF [ibm.com]
___
Later on, Fredkin and Toffoli presented a review of the ideas of reversible computing. The essential idea is that you can save all intermediary states between an algorithm to get the answer, and then reverse the process so that no energy is used, and generated no heat. Fredkin also indicates that if we switched from irreversible to reversible computing, we would expect to lose no more than 1% efficiency.
International Journal of Theoretical Physics 21 (1982):219-53 PDF [digitalphilosophy.org]
___
And as an unsubstantiated claim, I remember hearing that due to heat/radiation sources, that volatile memory gains errors of 1 bit per billion with a time from 1 minute to 1 day ( I forget the exact time). To correct this would only require the entropy of deleting that incorrect bit. In other words, 10^8 or so magnitude heat shrinkage. But trust the stuff above.
(Many of these ideas were taken from "The Singularity is Near" by Ray Kurzweil from page 130)
Parent
Re:Well.... (Score:5, Insightful)
Or did you actually think that those "stupid" CPU designers for all this years, battling with heat dissipation, never thought of, oh.. simply replacing the nand gates with reversible Fredkin and Toffoli gates and 'poof' magically all the heat issues are gone, processors will run @ hundreds of GHz, the wold's electrical power consumption will go down and the geeks won't be able to boast about their huge ass sinks anymore...
Parent
AMD64 is very fast (Score:5, Interesting)
Re: (Score:3, Informative)
And pointing out that it isn't fair to compare because a Core2 duo already executes the full SSE instruction in one pass vs. the 2 clocks for a curret AMD64 is the same as saying it's not fair to compare the on-die memory controller on AMD's vs. Intel's FSB. But people didn't seem to care when the numbers went in AMD's favor.
I'd really be interested in seeing your numbers, your programs, and what com
Re:AMD64 is very fast (Score:5, Informative)
OK. I can't give you the code but it is my own implementation of a pretty standard bioinformatics sequence comparison program which doesn't use SSE/MMX type instructions and is single threaded. On all platforms it was compiled using gcc with -O3 optimisation. I have tried adding other optimisations but it doesn't really make much difference to these numbers (no more than a couple of percent at best).
AMD Opteron 2.0Ghz (HP wx9300) - 205 Million calculations per second
Intel Core 2 Duo 2.66Ghz (Mac Pro) - 146 Million
Intel Core Duo 2.0 Ghz (MacBook Pro) - 94 Million
IBM G5 PPC 2.3 Ghz (Apple Xserve) - 81 Million
Motorola G4 PPC 1.42 Ghz (Mac mini) - 72 Million
Intel P4 2.0 Ghz (Dell desktop) - 61 Million
Intel PIII 1.0 Ghz (Toshiba laptop) - 45 Million
Interesting things about these numbers. The Core Duo is clearly a close relative of the PIII since the performance at 2Ghz is roughly twice that of the PIII at 1Ghz. The P4 at 2Ghz is really very poor indeed which isn't a huge surprise as it was never very efficient. The G4 PPC puts in a reasonable result easily beating the much higher clocked P4 (what, the Mac people were right? Shock!) although I have to say that the performance of the G5 is disappointing. The Core 2 Duo isn't a bad performer although it does have the highest clock speed of any processor in this set but it is seriously beaten by the Opteron. From these numbers, a Core 2 Duo at 2Ghz would be about half as quick as an Opteron at the same speed.
Parent
Re:AMD64 is very fast (Score:4, Insightful)
When you say you've tried "adding other optimizations," are you referring only to other GCC optimization flags? If your program's algorithms have any moderate degree of parallelism and you haven't tried vectorization either by compiler (GCC and ICC can both do this) or by hand, the benchmark you've done is not unlike a race where no one is allowed to shift out of first gear. Can you go into any more specifics about how this program does sequence comparisons?
Also, the disappointing numbers from the G5 may be partially explained by the fact that its integer unit has higher latency than the other desktop processors in that list. The G5 isn't exactly known for blistering integer performance, anyway.
Parent
Re: (Score:3, Interesting)
When the Core2 was released, benchmarks made it clear that Intel did not optimize for 64-bit performance. They have the architecture, but they pushed th
Re:AMD64 is very fast (Score:4, Informative)
Pretty sure it is a Tualatin since it is a 1Ghz PIII Mobile which I bought in early 2002 (http://www.theregister.co.uk/2001/01/31/chipzill
Given that it is a Tualatin, then the peformance of the Core Duo at 2Ghz looks about right. The Core 2 Duo gets about 10% better performance clock for clock from all the blurb I have read except when it comes to SSE where it is about twice as fast so the performance figure of 146 million also looks pretty much on the mark too as a 2Ghz Core 2 Duo should be able to manage about 110 million if you scale the figure for clock speed and that is (surprise) ~10% quicker than the Core Duo at 2Ghz (94 million) so the basic integer performance of the Core 2 Duo is better than the Core Duo but doesn't compare with the 205 million the 2.0Ghz Opteron manages.
Parent
Re: (Score:3)
Certainly a possibility. In my defense I would like to point out that all benchmarks are open to question. I know my own code, I know what it does and it doesn't do much but it does a lot of it so the performance figures are what they are. I originally wrote this code on an SGI, ported it to Linux on a 486, SPARC, Alpha, PPC and so on. Its old and simple but does real work. While I could make it faster using SSE an
Re: (Score:3, Informative)
If only that was the case but actually it is very linear. The application can hold the whole of its memory requirements in cache these days so it hardly has to touch main memory and it was designed to do all the inner loop code using only registers. Heck, I doubled the size of the inner loop just to avoid a single register copy because it made a significant performance increase.
The reason I like this code is that it shows how many operations y
that's what we all run though, and it can be OK (Score:3, Interesting)
I'm using Linux, with single-threaded apps, but so what? I run lots of things at once:
X, window manager, xterm, editor -- that is 4, plus the kernel
X, xterm, tar, gzip -- that is 4, plus the kernel
X, xterm, make, bash, cc1, cc1, cc1, gas, gas, ld... -- that's a lot of things!
Re: (Score:2)
goto BLAS uses SSE so doesn't count. It has already been acknowledged that the SSE implementation of Core 2 Duo is very good. The new AMD chips may address this but we won't know until we see the benchmarks. For non-SSE the Core 2 Duo is a little better than the Core Duo which was similar to the PIII/PII/PentiumPro clock for clock. The current Opteron is much quicker clock for clock for no
Wow (Score:2)
The design for VW performance sounds extra interesting
Great (Score:3, Funny)
Junk article, full of inaccuracies. (Score:5, Informative)
- Each of Barcelona's four cores incorporates a new vector math unit referred to as SSE128
SSE has always been 128bit (the 64bit simd extensions were called MMX). AMD used to funnel the instructions through a 64bit execution unit by splitting the work into two halves, the new core has a full 128bit SSE pipeline so doesn't need split the operations. Nothing new here, just a faster internal implementation. Can this deliver and 80% improvevment in benchmark performance? - quite possibly. Take a look at the Core2 FP perfromance numbers - it also has a full 128bit implementation of SSE.- And separating integer and floating-point schedulers also accelerates this thing called virtualization
Huh. Hardware virtualization affects how the processor handles certain instructions such as priviledged operations. FP instruction execution is unaffected. Virtualized workloads will benefit no more than non-virtualized workloads. Separate issue queues are good but does it specifically benefit virtualization? - no.- Barcelona blacks out power to individual portions of the chip that are idled, from in-core execution units to on-die bus controllers. This hasn't made it into PCs before
...
Intel call this 'intelligent power capability'.http://www.intel.com/technology/magazine/computin
- Barcelona adds Level 3 cache, a newcomer to the x86
Xeons have featured L3 caches for years. http://en.wikipedia.org/wiki/List_of_Intel_Xeon_m- Barcelona is genius, a genuinely new CPU that frees itself entirely of the millstone of the Pentium legacy.
- Barcelona is a new CPU, not a doubling of cores and not extensions strapped on here and there.
Barcelona is an Opteron, with a doubling of cores and some extensions strapped on here and there.I'm not meaning to detract from AMD here - the fact that they have still not had to make any radical changes to the opteron micro-architecture is a testament to the quality of the original design. They are slightly ahead of the game on virtualization - they're going to beat Intel to nested page tables - but other than that this chip is playing catchup. Overall this is going to be a very nice piece of kit to work with. But nothing radical and new here.
G.
Re: (Score:3, Informative)
Actually, if you go waaaay back to the Socket 7 days you could have L3 cache as well. The AMD K6 and K6-2 CPUs only had on-die L1, and the L2 cache was on the mainbaord. But the K6-3 CPU had 256KB or 512KB of on-die L2 and was compatible with the same mainboards. So when you put that K6-3 in a socket 7 mainboard the mainboard's cache actually functioned as L3. Sure it wasn't on-chip, but L3 cache
Re: (Score:3, Informative)
Now, as far as some claims, in detangled order:
Paging Tables (Score:5, Informative)
Context-switching has long been the weakest design point for x86 in "PCs", especially servers. x86 arch is rooted in single-user, single-threaded, single-context apps. The in-core registers that CPU operations execute directly against have to be swapped out for each context switch. In *nix, that means every time a different process gets a timeslice, it's got to execute two slow copies between registers and at best cache RAM, at worst offchip RAM (over some offchip bus). If the register count is larger than the bus width (even onchip), that's another multiple on that slow cycle. That context-switch overhead can be larger than the timeslice allocated to each process's "turn" in the schedule for lower-latency / higher-response (lower "nice") processes, approaching realtime.
Unix was designed for multiusers, context-switching from the beginning. The chips it's run on coevolved with it. Linux arrived when x86 CPUs ran fast enough that context-switching was OK, but still a big waste compared with, say, MicroVAX multiple register sets. Windows architecture is rooted in the x86 architecture that DOS was designed for, though perhaps Vista has finally lost all of the old design baggage originated in the 8088/8086, but its long history of UI multitasking means it's context-switching all the time, which will gain in speed. The MacOS switch to BSD means it's got lots of power bound up in the context switches that could be released with Barcelona.
So while low-level benchmarks might show something like 80% FPU improvement, the high level (application) performance could improve quite a lot more. Recompiling apps to machine code that exploits more registers without the context-switching penalties could find multiples, especially apps with realtime multimedia that run concurrently with other apps. Intel's hyperthreading already gets past some of these bottlenecks in distributing tasks among multiple cores, but the Barcelona paging tables go even deeper, for likely extra performance (on top of Barcelona's own hyperthreading and new L3 cache).
Aside from the marketing "vapormarks" we'll surely see out of AMD (and their sockpuppets) before it's actually released "midyear", I'm looking forward to seeing how this thing really runs in multitasking apps. I'm expecting "like a greased snake across a griddle".
Re:Honestly... (Score:5, Insightful)
Obsession about process size is sillier than obsession over clock speeds.
If AMD can produce a better performing chip at 65nm, then who the hell cares if Intel - or anyone else - move to a 45nm process?
Parent
Re: (Score:2)
I neglected to mention something else... (Score:3, Interesting)
Re: (Score:2)
An individual implementation can be copyrighted. A way of doing something can't be covered by copyright, and needs to be patented. That's what you meant, right?
Re: (Score:2)
This is Slashdot. We care about those details. You can read more about the "super fast, super cool, super cheap!" market speak on the company's official press releases section.
Re:Honestly... (Score:5, Insightful)
Feature size has denominated progress (as measure either by raw performance or performance per watt) over an unbroken 30 year period. Do you recall the very passionate debates about RISC vs CISC? Did a RISC design at one feature size ever beat a CISC design at the next shrink? I think not. Design has never mattered anywhere near as much as feature size. Not that you can't get design wrong. But then you can get a shrink wrong, too, and end up with 1% yields. AMD managed briefly to remain competitive with Intel playing a full shrink behind when Intel did that rather stupid marketron-driven face-plant into the thermal wall (against good advice from their Israel team, who later came to the rescue with Core Duo).
With the recent skyrocket of leakage current, the holy grail of feature size is somewhat tarnished, but it still dominates the performance curve. You completely missed the relationship between feature shrinks and the performance crown. If Intel has better process technology than AMD (almost always) and AMD has a better design (most of the time since the Athlon was first launched) and both companies shrink every 18 months following the Moore projection (that unbroken 30 year historical trend) and AMD always shrinks 9 months behind Intel, then the performance crown will pass back and forth exactly as often as either company announces their next product.
So I agree with you: feature size has no importance to the customer who wants performance for their dollar. Except that you can set your clock by it and project ten years into the future effective performance levels of shrinks we haven't even seen yet. Except for that part, yeah, I'm with you.
Parent
Re: (Score:3, Interesting)
They care. Just moving the chip from 65 nm to 45 nm means you can produce twice as much on the same silicon wafer. Also, if a 65 nm chip performs well, then a 45 nm version of it (with slight modifications of course) will work even better.
Re:Honestly... (Score:5, Insightful)
The end is the delicate balance of improving power / watt while increasing overall performance and keeping the price down. If AMD can deliver a chip that does a better job of that at 65nm than an Intel 45nm one, then the AMD chip is not somehow "worse" than the Intel one just because it doesn't use 45nm. That's just stupid.
I'm not saying AMD can do that, but I think that criticizing them for not being ready for 45nm yet is more than premature.
AMD's actually guilty of the same flawed logic though - their criticism of Intel's 4 core processor being just 2 dual cores stuck together is just as pointless. It doesn't matter what matters is how well the processor meets the requirements of its target market.
Parent
Re: (Score:3, Interesting)
But it is interesting to see the two companies approach the problem from different ends. Do you improve the silicon process or do you alter the architecture and instruction set? I bet you the best answer will be to do both.
quad cores that actually share cache would be nice. these double duals kind of suck because architecturally they can never share cache. although AMD and Intel don't have ve
Re: (Score:3, Interesting)
Most laptop processors have a higher performance/watt than desktop processors because they are designed
Quad Core (Score:3, Interesting)
Re:Intel's Responds (Score:5, Interesting)
Oh, here's one [sun.com]. Though it's been out since before Intel had quad-core chips.
Parent
Re: (Score:3, Informative)
(this was anonymous for a reason)
Re:If its true (Score:5, Funny)
Seven for the WoW-nerds in their halls of stone,
Nine for Diablo Men doomed to die,
One for the Dark Nerd on his dark throne
In the Land of Silicon where the corporations lie.
One quad core to rule them all, One quad core to find them,
One quad core to bring them all and in the darkness bind them
In the Land of Silicon where the corporations lie.
He paused, and then said in a deep voice,
This is the Master-quad core, the One quad core to rule them all.
Parent
Re: (Score:2)
Re: (Score:3, Interesting)
I will not surprised if AMD dethrones Intel again. It is a classical Intel vs. AMD battle...
I am not sure Intel ever did beat out AMD.
I went down to Best Buy where the Intel rep was hard peddling a Code Duo 2 machine and compared his $1500 machine to a AMD X2 clearance one for $600. I had nothing to do that day but be a clown, so I went and got a DVD with software on it, and said these are both XP right? Copy the contents to the hard drive and compress it. I am going to measure it. Core Duo 2 result