Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD's Showcases Quad-Core Barcelona CPU

Zonk posted more than 7 years ago | from the four-times-the-fun dept.

AMD 190

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."

Sorry! There are no comments related to the filter you selected.

If its true (-1, Offtopic)

Broken scope (973885) | more than 7 years ago | (#17960566)

Then this could be a neat little chip.

Re:If its true (5, Funny)

Anonymous Coward | more than 7 years ago | (#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.

Honestly... (-1)

Khyber (864651) | more than 7 years ago | (#17960572)

Dethroning happens all the time. We're talking about 65nm when we're already gearing up for 45. Wake me up when either company does 1nm processors.

Re:Honestly... (5, Insightful)

mabinogi (74033) | more than 7 years ago | (#17960600)

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?

Re:Honestly... (-1)

Anonymous Coward | more than 7 years ago | (#17960730)

Indeed, for people like you this detail does not matter and I'm not sure why you post on this site either. You should be all over pcconnection and other retailers.

Everybody else knows that 45 nm _IS_ better than 65 nm therefore the processor will get a performance boost just by using that technology.

Fire on, I'm a flamebait.

Re:Honestly... (4, Insightful)

mabinogi (74033) | more than 7 years ago | (#17960858)

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.

Re:Honestly... (2, Interesting)

OrangeTide (124937) | more than 7 years ago | (#17961442)

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 very dual cores that can even share cache with-in themselves. (although I think Intel is releasing one soon?)

Re:Honestly... (1)

l3v1 (787564) | more than 7 years ago | (#17961506)

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.

I don't think it's about that. I mean, since Intel quickly pumped out something which seems like being 4 core cpu which took far shorter than to develop a new quad core design cpu makes them seem to lag behind, so what can you do to explain ? Not much really, besides what they said above, that Intel got quicker because it's not really a quad core design. Everyone will have their own multicore designed cpus sooner or later, so it won't really matter.
 

Re:Honestly... (1)

Gr8Apes (679165) | more than 7 years ago | (#17961884)

I guess you're still running that 4GHz P4 then?

Re:Honestly... (1)

Khyber (864651) | more than 7 years ago | (#17960796)

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 sucked balls, but what was made for that computer, it once again, did what I wanted it to do. Sometimes better, sometimes worse. YMMV. If anyone wants bragging rights of ANY sort, the technology to shrink the die-size is the way to go. Go read a book called "Nanotime," IIRC. THAT is what I'd like to see, minus superdense C4 that's equivalent to a mini tacnuke, and those insane driving laws and shit.

Re:Honestly... (1)

Dahamma (304068) | more than 7 years ago | (#17961450)

You haven't really added much from your original post. Die shrink is an implementation detail, probably something you read that sounded "futuristic"... The real goals are performance, and (usually secondarily) power consumption. Doesn't really matter how they achieve those goals.

I agree with you on one point - I think as with your requirements, the goal for the average non-technical home consumer should be focused more on efficiency than multi-core 64 bit 4MB cache, etc. But not everyone spends 95% of their time browsing the web and typing in their casserole recipes. Try to run a parallel make on a large project and you immediately appreciate a processor with a high clock rate, multiple cores, and huge cache. I don't need to read sci fi to know what I need to do my REAL job.

I neglected to mention something else... (2, Interesting)

Khyber (864651) | more than 7 years ago | (#17960848)

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. No more oldskool hacker ethic, now it's greed.

Re:I neglected to mention something else... (1)

cduffy (652) | more than 7 years ago | (#17961000)

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?

Re:I neglected to mention something else... (1)

lazarus corporation (701348) | more than 7 years ago | (#17961174)

Correct, so long as you're only talking about the US and not about Europe, where software patents don't restrict innovation (yet).

Re:Honestly... (0)

Anonymous Coward | more than 7 years ago | (#17960856)

Insightful? Just because you can't correlate die size to benefits doesn't mean the rest of us can't. Get off "news for nerds" and go to "news for regular Joe" intead.

Less power dissipation, higher clock speed....

Re:Honestly... (1)

suv4x4 (956391) | more than 7 years ago | (#17961022)

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.

Re:Honestly... (0)

Anonymous Coward | more than 7 years ago | (#17961062)

Why? it seems to me that there's far more interesting about the design of this chip than the process size.

Re:Honestly... (4, Insightful)

epine (68316) | more than 7 years ago | (#17961160)

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.

Re:Honestly... (2, Interesting)

jmv (93421) | more than 7 years ago | (#17961440)

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.

Re:Honestly... (1)

zCyl (14362) | more than 7 years ago | (#17961718)

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.

But how much does this really affect the retail price of a cpu? From randomly googling around, it looks like silicon wafer cost only translates to a dollar or two per cpu, so who cares if they can drop this expense by half? Surely other factors would be more important for cost, such as design expense, manufacturing time, and the cost of the fabrication equipment (which would increase if more manufacturing units are needed due to longer manufacturing time).

Power loss and speed seem to be complicated things, and I really doubt this continues to get better as the fabrication process keeps going to infinitesimally small sizes. It seems to be getting hard to keep the electrons confined at these small sizes, and that's going to have to start having a dominant negative impact at some point.

Re:Honestly... (0)

Anonymous Coward | more than 7 years ago | (#17961468)

As an investor in the semi business I very much care about process sizes. One of the larger reasons Intel make money while AMD does not is because Intel can produce more chips at less cost.

Re:Honestly... (1)

Charcharodon (611187) | more than 7 years ago | (#17961868)

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?

The best way of looking at things. I started off Intel and stuck with them up to about 1Ghz, jumped ship stayed with AMD untill my X2 3800, now I'm back to Intel with a Duo 2 6600. We'll see in 1-2 years who'll I'll be with next. The same goes for video cards and soda. Pepsi vs Coke, Nvidia vs ATI. Doesn't matter which ever gives me what I want at the lowest price.

Of course companies spend billions trying to convince you otherwise, but all products are just commodities and are practically the same in the end.

Re:Honestly... (1)

tedpearson (910434) | more than 7 years ago | (#17960726)

... and you can wake me up when the processors themselves are smaller than a square millimeter. I need them for my new thumb-top computer design.

Bit Slice (1)

flyingfsck (986395) | more than 7 years ago | (#17960580)

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...

But SSE is already 128 bits! (1)

pammon (831694) | more than 7 years ago | (#17960582)

Anyone know what "SSE128" means? SSE registers have been 128 bit from day one.

Re:But SSE is already 128 bits! (5, Informative)

Zenki (31868) | more than 7 years ago | (#17960622)

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.

Re:But SSE is already 128 bits! (1, Interesting)

pammon (831694) | more than 7 years ago | (#17960674)

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! (5, Informative)

waaka! (681130) | more than 7 years ago | (#17961192)

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.

Re:But SSE is already 128 bits! (4, Informative)

pammon (831694) | more than 7 years ago | (#17961332)

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).

Re:But SSE is already 128 bits! (0)

Anonymous Coward | more than 7 years ago | (#17960788)

IIRC the Core Duo also has 128bit processing width for SSE instructions. There should be an article on Ars Technica about the architecture.

Re:But SSE is already 128 bits! (5, Informative)

larrystotler (998217) | more than 7 years ago | (#17960650)

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

Re:But SSE is already 128 bits! (2, Interesting)

adam31 (817930) | more than 7 years ago | (#17960944)

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 computed in a cycle and the next 2 components in the next cycle, okay. Except that vmx does 4 component multiply-add in a single cycle, which would mean that SSE sucks at its GHz.

wrong section (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17960602)

Zonk, didn't you get the memo? This slashvertisement belongs in the Special advertising section [slashdot.org]

Re:wrong section (1)

Khyber (864651) | more than 7 years ago | (#17960962)

Who says news can't come from an advertising section? It's stil a source of information.....

Dethrone? No. (2, Insightful)

NXprime (573188) | more than 7 years ago | (#17960604)

"Will AMD dethrone Intel again?" Dear AMD, meet Larrabee. http://www.theinquirer.net/default.aspx?article=37 548 [theinquirer.net] AMD might kick Intel in the nuts a little but definitely not dethrone.

Re:Dethrone? No. (2, Interesting)

robinvanleeuwen (1009809) | more than 7 years ago | (#17960844)

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.

GPU not CPU - Re:Dethrone? No. (2, Insightful)

dave1g (680091) | more than 7 years ago | (#17960920)

read the article, that is an x86 GPU it wouldn't be able to compete with general purpose CPUs

troFlL (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#17960636)

or a public club, that have raged of FrreBSD Usenet later ssen in in ratio of 5 to

Is dethroning Intel the point? (5, Insightful)

Weaselmancer (533834) | more than 7 years ago | (#17960654)

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.

Re:Is dethroning Intel the point? (1, Funny)

Anonymous Coward | more than 7 years ago | (#17960954)

Ahh, I just spent $985 on a QX6700. In 6 months you're going to love it!

Intel's Responds (1, Redundant)

isieo (1049808) | more than 7 years ago | (#17960670)

"Lets make a Octa-core processor!"

Re:Intel's Responds (4, Interesting)

pchan- (118053) | more than 7 years ago | (#17960822)

"Lets make a Octa-core processor!"

Oh, here's one [sun.com] . Though it's been out since before Intel had quad-core chips.

Re:Intel's Responds (3, Informative)

Anonymous Coward | more than 7 years ago | (#17961466)

8 core (two quad core chips in a single package) is already on Intel's internal roadmaps.

(this was anonymous for a reason)

I'm going to need one of these (0)

Anonymous Coward | more than 7 years ago | (#17960696)

I read the Tom Yager piece and I started drooling so much I shorted out my computer.

I'll just hit the Submit button now and see if I can get this posted to Slashdot before the drool shorts out this computer too.

Huh? (1)

sumdumass (711423) | more than 7 years ago | (#17960704)

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.

Am i missing something or am i completly wrong?

Re:Huh? (0, Redundant)

l3v1 (787564) | more than 7 years ago | (#17961606)

Am i missing something or am i completly wrong?

Uhmm... yes.

Well.... (2, Interesting)

Creepy Crawler (680178) | more than 7 years ago | (#17960734)

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 chips if we switched to this method.

Re:Well.... (1)

Gori (526248) | more than 7 years ago | (#17960758)

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....

Re:Well.... (4, Interesting)

Creepy Crawler (680178) | more than 7 years ago | (#17960916)

---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)

Re:Well.... (1)

Gori (526248) | more than 7 years ago | (#17961052)

Very interesting indeed. Thanks for the pointers. Im definitely going to read up on the papers you suggested in greater detail. After a quick scan, they are really interesting

My research is in complex adaptive systems in a socio-technical setting, e.g. industrial network evolution etc. These things are about as far removed from equilibria and reversibility as they can be. They are all path dependent, and intractable ( as are all evolutionary processes). Think dissipative structures ala Prigogine etc.
So it is truly fascinating to think of a computation that can be fully reversible / adiabatic. Is there no work being performed ? If you reverse the computation, are you still "allowed" to know the answer ?

Goes to show how truly different information is, compared to matter and energy.

What I still do not understand it whether this can be practically built, and if so, why do not we have it already ? Global warming and all of that ?

Would it require radically different software? I would think so...

Anyway, your comment was one of the most enlightening ones I have ever seen on slashdot. Chapeau !

Re:Well.... (1)

rbarreira (836272) | more than 7 years ago | (#17961228)

If you reverse the computation, are you still "allowed" to know the answer ?

As far as I remember reading, outputting answers adds a bit of heat output to the equation, but doesn't prevent you from using reversible circuits.

Re:Well.... (4, Insightful)

drgonzo59 (747139) | more than 7 years ago | (#17961066)

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...

grandparent was interesting, your comment isn't (0)

Anonymous Coward | more than 7 years ago | (#17961244)

Look. He's talking about something interesting, and the conversation started on the theoretical limits of computation. Thus being in theory land is not unreasonable. Unless you actually have something interesting to say with some actual data to back you up, quit bashing someone who actually DOES have ideas and knows what the fuck they're talking about.

A few years ago people would've said that it was impossible to pull data from below the noise floor in radio channels, but we do it routinly now. People said that OOP was just theoretical wankery, but now java is (to my dismay) one of the most popular languages aroudn. Same for relativity, but we have satalites. Where do you think processors started? You think someone went out and said "I think I'll make a few micron thick wafer of silicon and get a processor". All of our advancements in science have started out as theoretical concepts, and slowly they've become practiced, then practical, and then commonplace.

To be fair, I suspect that the resulting information from the computation itself carries... well... information. As all good computer scientists know information has a direct corolation to entropy, and in fact this is how we define randomness. How much entropy is a simple function of the information actually obtained (I.E. how acuratly we can predict each bit). Given how closely all of these things are tied I would be surprised if this entropy didn't somehow "count" towards the physical entropy of the system. Still, if it took a long complex computation to get those bits, it's not that much entropy lost to information (like say it's a yes, no answer to a very difficult exponentially difficult problem on a large N). It SEEMS like if you reverse the process it should take energy to do so. But I don't know, it also seems like light shouldn't interfere with light, and dark matter should run into other dark matter, and you shouldn't be able to do computation by repeatedly not looking at bits until you have what you want (I.E. Quantum computation, which we can already do, just only 5 bits at a time). Who knows... maybe this is feasable, unless you've got the physical background to prove him wrong, or make a useful contribution, quit pointlessly spewing shit at people who have useful things to say.

Re:grandparent was interesting, your comment isn't (1, Offtopic)

drgonzo59 (747139) | more than 7 years ago | (#17961326)

...the conversation started on the theoretical limits of computation.

Mr. Coward, in case you have not read the article, the conversation actually is about AMD's new processor, which is a real processor. That processor will generate some amount of heat ... real heat, not theoretical heat.

A few years ago people would've ...

What are you referring to? I never mentioned OOP, relativity, or satalites (sic) in my post.

To be fair, I suspect that the resulting information from the computation itself carries... well... information.

You are a coward but at least you are fair, that's good to know. A fair coward is better than a regular, run-of-the-mill coward, at least in my book. Yes, information carries information. Do you want a Nobel prize for that? O perhaps an honorary PhD degree?

All good computer scientists know information has a direct corolation (sic) to entropy

And even better computer scientists know how to spell, or at least use a spell checker.

It seems like you need to listen to your own advice and : quit pointlessly spewing shit at people who have useful things to say.

Re:Well.... (1)

chthon (580889) | more than 7 years ago | (#17961796)

Yeah, I think there was an article back in 1993 or 1994 in Byte about such processors. It seems that in practice, the theory doesn't add up.

Re:Well.... (1)

alphamugwump (918799) | more than 7 years ago | (#17961522)

I am not a physicist. However, I know that there are other physical processes that do not change entropy, for example, mechanical and some electrical ones. So, I suppose it makes sense that computational processes can be reversible, as all you are doing is twiddling bits anyway. However, just as mechanical systems must be ultimately powered by heat engines, computers must ultimately do IO. Sure, you could use your computer to find the trillionth Ramsey number, but that wouldn't have anything to do with the physical world. I imagine that as IO needs increase, we'll have a giant pile of supporting junk around a single, ultrafast processor. The processor would be relatively cool, but the IO would generate heat, due to the quantum effects of trying to measure stuff. Otherwise, you could get around the second law by predicting the future. ( I imagine that statistical thermodynamics and quantum mechanics must apply to macroscopic stuff too, like human populations). I think you already see this with things that really do generate enormous amounts of data, like particle accelerators. The energy for processing the data is not negligible, but it's a hell of a lot less than the energy to run the accelerator. Conversely, taking 3D data that the computer understands, and flattening it down to 2D without losing very much is also very intensive, relative to the amount of computation that goes into game physics, for example. But this is just me bullshitting.

Re:Well.... (1)

DimGeo (694000) | more than 7 years ago | (#17960878)

If memory serves right, you need the constant 1 and xor to for a Boolean base with xor.

Re:Well.... (2, Informative)

Khyber (864651) | more than 7 years ago | (#17960914)

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.

Re:Well.... (1)

OrangeTide (124937) | more than 7 years ago | (#17961476)

electrical resistance formulas cannot be derived from friction formulas. friction is a macroscopic thing that is the statistically accumulation of many microscopic effects.

Re:Well.... (1)

caramelcarrot (778148) | more than 7 years ago | (#17961682)

Surely constructing logic-destructive gates out of these non-destructive gates would have the same entropy effect... unless you somehow manage to program entirely in non-destructive functions (probably very wasteful in terms of storage/area)

The proof of the pudding.... (1)

15Bit (940730) | more than 7 years ago | (#17960746)

....is in the eating. Until we see benchmarks everything is just ignorant speculation.

AMD64 is very fast (5, Interesting)

GreatDrok (684119) | more than 7 years ago | (#17960760)

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.

Re:AMD64 is very fast (2, Informative)

pjbass (144318) | more than 7 years ago | (#17960814)

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 compiler options you passed when building on each platform (as well as type of memory, mobo chipset, etc., in each machine).

Re:AMD64 is very fast (5, Informative)

GreatDrok (684119) | more than 7 years ago | (#17960946)

"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.

Re:AMD64 is very fast (1)

timelessroguestar (920772) | more than 7 years ago | (#17961152)

The P3 you list looks a Coppermine, I suspect a P3 Tualatin would perform much better. At least every test and regular usage that I did seemed to indicate it was 33% faster than the Coppermine. It's interesting to see that the Core Duo on par with a Coppermine, I can't see how they could have gone so wrong there. My own testing of the Core 2 seems to indicate it is about 74% faster than the Tualatin clock for clock. My user experience doesn't seem to deny it. I'd expect to see a 2.66 GHz Core 2 closer to 275 Million, which would be similar to the Opteron you list. I'm not sure what's wrong with this picture, but something doesn't add up her.

I'm not sure how valid any of our anecdotal tests are. It's very hard to stress a chip like the Core 2 properly. The task manager will report it at 100% utilization and it will reach X degrees of heat, but if you run something like thermal analysis tool (TAT) it will go way beyond in temperature increase and 100% utilization, using all branches and transistor I would guess.

Re:AMD64 is very fast (3, Informative)

GreatDrok (684119) | more than 7 years ago | (#17961208)

"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.

Show us your source code (1, Insightful)

rbarreira (836272) | more than 7 years ago | (#17961180)

Well, until you show us your source code those numbers are as believable as anything else one might randomly type here...

Re:Show us your source code (1)

GreatDrok (684119) | more than 7 years ago | (#17961238)

"Well, until you show us your source code those numbers are as believable as anything else one might randomly type here..."

I can't because the program is really large and it doesn't entirely belong to me (you know, work for people, they own your code).

You're right, I could just be making these numbers up and if you prefer to believe that then there is nothing I can do to change your mind. All I can say is that this is my own (admittedly anecodatal) experience.

Re:Show us your source code (1)

rbarreira (836272) | more than 7 years ago | (#17961314)

Actually I was thinking more about benchmarking/coding flaws than lying from your part.

Re:Show us your source code (2)

GreatDrok (684119) | more than 7 years ago | (#17961454)

"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 and have done so with other code, that wasn't the purpose of these numbers. It was simply to see what the processors do using the same code, the same compiler and similar OSs (Linux v OSX in this case). Anyway, the PPC code from gcc is likely not particularly well optimised, especially for the G5, but for the x86 based chips it isn't too bad. All code was compiled 32 bit with just the basic optimisation a C programmer would put. Compiling with -m64 doesn't really help it much and on the Intel chips has been known to reduce performance so I stuck with 32 bit.

Re:AMD64 is very fast (1)

kestasjk (933987) | more than 7 years ago | (#17961252)

I hope the benchmarks don't take get advantage out of using 64-bit arithmetic.

Re:AMD64 is very fast (1)

GreatDrok (684119) | more than 7 years ago | (#17961486)

"I hope the benchmarks don't take get advantage out of using 64-bit arithmetic."

Nope, straight 32 bit. If it had been 64 bit then the Core 2 Duo would also have seen a more significant boost versus its 32 bit predecessor not to mention the G5 should have been better than the G4 which it wasn't.

Re:AMD64 is very fast (1)

NovaX (37364) | more than 7 years ago | (#17961758)

No, Core2 has worse [xbitlabs.com] 64-bit performance.

Re:AMD64 is very fast (1)

jez9999 (618189) | more than 7 years ago | (#17961264)

Any numbers for an Athlon 64? I just bought a 3800+ single core and would like to be made really excited about it. :-P

Also which of these chips are single, and which are dual, and which are quad cores?

What's the point of dual and quad core, anyway? Anyone figured out why it's better than just having 2/4 CPUs?

Re:AMD64 is very fast (1)

GreatDrok (684119) | more than 7 years ago | (#17961478)

"Any numbers for an Athlon 64? I just bought a 3800+ single core and would like to be made really excited about it. :-P"

Pretty much the same as the Opteron in this case. The program doesn't really hammer cache or main memory, just the CPU. Work out your clock speed as a percentage of 2Ghz and do the sums and that should be the number.

The Opteron, Core 2 Duo and Core Duo are all dual core chips in this test, the others single core although the G5 was a dual processor system. Since the program is single threaded there isn't any benefit to extra cores in this case but if you multithread your program you can utilise multiple CPUs and improve performance substantially. At the moment, the sweet spot seems to be dual core as modern operating systems are happy working with multiple CPUs. A quad system is really only necessary if you are maxing out a dual core system and need to run more tasks at once.

Re:AMD64 is very fast (1)

High Hat (618572) | more than 7 years ago | (#17961482)

What's the point of dual and quad core, anyway? Anyone figured out why it's better than just having 2/4 CPUs?

Easy: Multiprocessor/core is not an "optional" or "high-end" feature in the multicore architectures, thus making SMP a commodity feature, which in turn results in lower prices on CPUs and Mainbords per processing core.

The other big advantage are shorter signal paths, which are faster - synchronizing processors that run at a couple of GHz that are connected by wires longer than a centimeter or so can be pretty challenging because of clock propagation issues. Also, shorter signal paths are much more energy efficient.

Re:AMD64 is very fast (3, Insightful)

waaka! (681130) | more than 7 years ago | (#17961272)

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.

Re:AMD64 is very fast (1)

GreatDrok (684119) | more than 7 years ago | (#17961508)

I should say that this program was written a very long time ago originally. It implements an efficient but standard Smith and Waterman dynamic programming algorithm. I have done vectorisation of this algorithm in the past and the performance improvement was dramatic (about x20). With this test program though, it hasn't really benefited from extreme compiler optimisations. I do remember running it after compiling with ccc on an Alpha and seeing a 30% speedup so there is definitely room for improvement but most of these benchmarks are with gcc on x86 which isn't too bad. OK, not icc but I don't have access to that.

As you say, the G5 was never really good at integer work but its floating point performance isn't too bad. If only HPaq hadn't killed Alpha. *sigh* What a chip.

Re:AMD64 is very fast (2, Interesting)

NovaX (37364) | more than 7 years ago | (#17961282)

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 that task to a future refresh. AMD processors receive a significant performance boost in 64-bit mode, which could easily explain your numbers.

32 vs 64 (1)

mrnick (108356) | more than 7 years ago | (#17961594)

It depends on what kind of data you are processing. If you are doing 32 bit calculations then you would want to compile your code for 32 bit, assuming your processor can handle it, as most 64 bit CPU can. If you are using 64 bit calculations then of course the 64 bit CPU would out perform the 32 bit as you would have to do additional coding steps to simulate 64 bit on 32 bit architecture, multiple 32 bit operations with bit shifting and the like.

If you took code that was written for 32 bit operations and compiled that code for 64 bit then the results would be very bad. The same issues where present when computers made the move from 16 to 32 bit.

I would assume that the code written in these tests are 32 bit. If so, then when evaluating CPU one would have to take into consideration if they needed 64 bit calculations. Also, before jumping the gun and making a rash decision some research would need to be taken to see if your operating system of choice supports true 64 bit operations. Many of the so called 64 bit operating systems only use the 64 bit CPU to support memory beyond 4GB.

Nick Powers

Re:32 vs 64 (1)

NovaX (37364) | more than 7 years ago | (#17961744)

You're assuming that the only difference between 32-bit and 64-bit x86 instructions are the bit sizes. That's not true, and the most immediate gain from AMD64 are the extra registries. There are a lot of changes to the ISA that will dramatically skew the results. The only negative results you would get compiling 32-bit code to 64-bit would be: A) The cache can contain fewer entries; B) Platform assumptions, such as when performing pointer arithmetic, would break. His code is probably fairly clean since he was able to test it on both x86 and PowerPC processors.

I also disagree with you on Operating System support. The HP wx9300 is sold with 64-bit Linux or Windows XP x64, both of which have mature 64-bit support. Microsoft Windows became 64-bit clean with the Intel Itanium series and Linux with the DEC Alpha. Windows 2000, for instance, supports up to 32GB of addressable memory on 32-bit x86 by using PAE.

Its funny you talk about jumping the gun, but then shrug off your assumptions. The entire point is to find out what bad assumptions are being made, since so many people are surprised by his numbers.

Re:AMD64 is very fast (0, Redundant)

dave1g (680091) | more than 7 years ago | (#17960894)

I just got a presentation on gotoBLAS from the creator http://www.tacc.utexas.edu/~kgoto/ [utexas.edu] , and his benchmarks show core2 duo nearly double the FLOPS of the opteron.

http://www.tacc.utexas.edu/resources/software/goto blasfaq.php [utexas.edu]

perhaps you need to write some more cache efficient code to test with. goto BLAS can feed the beast like no other.

Re:AMD64 is very fast (1)

GreatDrok (684119) | more than 7 years ago | (#17961020)

"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 non-SSE work. Also, my test code is really just integer code and it works mainly in registers and uses very little memory so it is quite a good test of the raw performance of a CPU which is why I like it.

hardware encryption support (1)

mrq1 (139232) | more than 7 years ago | (#17960832)

come on, amd guys!

get the hardware encryption support from VIA licensed and include it; that will be needed in the next years too!

Inevitable question (1, Funny)

DiamondGeezer (872237) | more than 7 years ago | (#17960838)

But will it run Linux?

Re:Inevitable question (1)

OrangeTide (124937) | more than 7 years ago | (#17961488)

I think I would cry if the answer was "No".

Re:Inevitable question (1, Funny)

Anonymous Coward | more than 7 years ago | (#17961504)

But will it run Linux?
.. And this in the one place that "Imagine a Beowolf cluster of these things!" would actually make sense!

Wow (1)

2ms (232331) | more than 7 years ago | (#17960982)

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

VW performance ? (0)

Anonymous Coward | more than 7 years ago | (#17961356)

Is this yet another comparison to computers are like cars?

linked article is from november 2006 (0)

Anonymous Coward | more than 7 years ago | (#17961032)

AMD showcases quad core Barcelona CPU? This is old news from last year. The PCWorld article linked to by this story is dated November 30, 2006.

how do they fit a fourwheeler in the chip? (2, Funny)

pseudosero (1037784) | more than 7 years ago | (#17961044)

I want a floating quad.

SSE128 means... (1)

adam31 (817930) | more than 7 years ago | (#17961058)

Does SSE128 mean some significant departure from the doomed SSE instruction set?


I'm not kidding. In SSE I'm familiar with, one of the input registers is always an output register, which means its contents are destroyed. Another flaw is that there aren't enough registers... SSE uses 8, where 32 are commonly not enough when latency is longish (especially with SoA-style progamming, where pragmatically a single vec3 occupies 3 128-bit registers).

... or Madd. You know, multiply-add. Does it have that?

Re:SSE128 means... (1)

ja (14684) | more than 7 years ago | (#17961600)

According to http://www.theinquirer.net/default.aspx?article=35 011 [theinquirer.net] there is nothing breathtakingly "new" here. If you were hoping for dramatic changes like r1 += r2 * r3 or altivec style permute, it is simply not there.

Like a repeat all over again... (0, Troll)

TheSoggyCow (1052136) | more than 7 years ago | (#17961072)

I will not surprised if AMD dethrones Intel again. It is a classical Intel vs. AMD battle...

Intel comes up with some hair-brained scheme that "More is better!". (like Viagra) They design something new and decide to make it faster (or in this case just glue more of them together). Back in the day it was the "GHz" now it's all about how many "Cores" you got. This tactic seems to suit Intel quite well and dethrones AMD for about a year and a half... During this time AMD massively redesigns there chips to integrate new, emerging technologies. The gamers and server operators of the world sit by their AMD chips knowing that they might not have the fastest chips for the time being but they are more technologically advanced.

Intel keeps cranking out their "Viagra" chips that become hotter and bigger energy hogs. When they finally come to the realization that their product SUCKS (as with the P4's) AMD is already a step ahead and swiftly takes the market back with their chips, that have always be a step ahead technologically. Intel scrambles, does a redesign, fails, tries again and history repeats. Intel's "Viagra" mentality causes their chips to be more expensive while AMD's "slow and steady wins the race" mentality allows them to keep their prices down.

--
Get your facts first then distort them as you please -Mark Twain

Great (2, Funny)

Trogre (513942) | more than 7 years ago | (#17961096)

So now I'll see four penguins at startup!

Re:Great (1)

gilboad (986599) | more than 7 years ago | (#17961438)

... I'll see 8. :)
(2xSocketF machine).

Barcelona vs Itanium in single and double float ? (2, Interesting)

tchiwam (751440) | more than 7 years ago | (#17961140)

What really interest me is how does it compare with single and double precision calculations. If AMD gets in the range of Itanium performaces will Intel follow and kill their own Itanium by boosting core 2 FP ?

cool - quad core !! (0)

Anonymous Coward | more than 7 years ago | (#17961246)

Cool - quad core cpu and my internet connection is still in the dark age.
Yep 800Kbps down. Look like my CPUs are going to sit twidle it thumbs for awhile
while waiting for the data

Re:cool - quad core !! (1)

OrangeTide (124937) | more than 7 years ago | (#17961494)

well if your cpu ever gets powerful enough to do some sort of extremely computationally expensive compression (like with fractals or something?). maybe you could squeeze a little bit more out of your slow link?

I like dial-up, nobody can call me (one phone line, disable call waiting), and I really only do IRC and text browsing. Honestly who wants to give the cable company or phone company $50 a month, those bastards are rich enough.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?