Erratum Plagues Quad-Core Opterons, Phenoms

theraindog writes "Errata are not uncommon with new processors, but a problem with the TLB logic in AMD's quad-core Opteron and Phenom processors appears to be quite serious. The erratum is so severe that AMD has issued a 'stop ship' order on all quad-core Opterons. AMD has also blamed this bug for the delay of the 2.4GHz Phenom, despite the fact that the erratum is unrelated to clock speed. A BIOS-based workaround for the issue has been made available to motherboard makers, but it apparently carries a 10-20% performance penalty. What's more disturbing is that AMD knew of the erratum and the potential performance hit associated with fixing it before it launched the Phenom processor. Hardware provided to the press for reviews did not include the fix, conveniently overstating Phenom performance."

Comments

is this the end ... ?

[A little Frenchie]

... for AMD?

Re:is this the end ... ?

[jwo7777777]

That was because some people who said "I prefer Intel over AMD" did so without a cogent, technical argument.

I am certain there were many who stated their preference due to cooler operating temperatures, higher frequencies, etc..., but the irritants were the ones who were stuck on Intel because "that's how their daddy voted....."

tsop tsrif

[Anonymous Coward]

my k6-2 533AFR is still rock solid. ill never upgrade

socket 7 ftw.

Re:tsop tsrif

[Anonymous Coward]

You mean the ..afX
http://www.cpu-world.com/CPUs/K6-2/AMD-K6-2%20533%20-%20AMD-K6-2-533AFX.html

You will never be able to upgrade to vista using that....

What???

[GregPK]

I'm a geek an all. But, I've never heard of erratum.

But dictionary.com is your friend.

Design errors and mistakes in a CPU's hardwired microcode may also be referred to as an erratum. One well publicised example is Intel's "flag" erratum in early Pentium Pro processors. This made the conversion of floating point numbers to integers unreliable due to an exception not being signaled under certain conditions.

Re:What???

[phasm42]

Turn in your geek card!

Re:What???

[fitten]

Every CPU maker publishes the errata for their CPUs because system designers/vendors/whatever need to know these things. Every CPU made for the past (insert very long time in the computer world here) has had a big list of errata publicly published. Just got to the Intel or AMD site, for example, and look up the errata on the PPro, P3, P4, Core, Core2, Athlon, Athlon XP, Athlon64, Athlon64 X2, or whatever your favorite CPU happens to be.

The thing is, the CPU is actually broken a bit and AMD has pulled the Barcelona line but are continuing to sell the Phenom(inal Failure) line to customers and, evidently, don't plan to 'fix' the problem later (Intel offered replacements for the Pentium floating point bug after they got dinged on it, for example... I know... I had one and replaced it).

So... if you actually get your hands on (or got your hands on) a Phenom, realize you have a broken CPU and the more you load it, the more likely you'll have stability issues.... and AMD isn't (currently) going to fix it.

Re:What???

[wgoodman]

They usually attach an extra page somewhere near the manual to list erratum. You've probably been doing what everyone else does: toss them both in the trash unread.

Re:What???

[nuzak]

Erratum is singular. Errata is plural.

The conventional terms used for erratum, however, are usually "error" or "bug".

Re:What???

[Brett Buck]

There are frequently many bugs in the microcode and other internal processor units, and they are typically listed. I have a list of one-line descriptions of bugs in the Teledyne 1750A processor that covers about 3 pages total. Most are minor, some required workarounds depending on your application. It's not uncommon at all, you just have to know about it and plan accordingly. They almost all are qualitatively similar to this bug. Maybe it's a bigger problem than some but its not unusual in nature.

        Brett

Re:What???

[rbanffy]

"Every CPU made for the past (insert very long time in the computer world here) has had a big list of errata publicly published."

Well... I can't remember any for my beloved 6502. Since the specs were five pages long, I can't imagine it having a long list of design flaws. It didn't even have a long list of features ;-)

Re:What???

[alshithead]

"I'm a geek an all. But, I've never heard of erratum."

Mod me down, call me troll, but please don't claim to be a geek if you can claim to never have heard of erratum or errata. That's as bad as not knowing what a bug is or calling a PC case and its contents a hard drive.

Here's a heartfelt suggestion...read more.

Re:What???

[Carnildo]

Well... I can't remember any for my beloved 6502.

They may not have been published, but there are at least three:
1) A memory-indirect jump where the address is stored across a 256-byte boundary will read the second byte of the address from the wrong location.
2) The arithmetic status flags are not valid when performing arithmetic in BCD mode.
3) If a hardware interrupt occurs while the processor is fetching a BRK instruction, the BRK instruction is ignored.

Re:What???

[Anonymous Coward]

Wow. I am guessing you must be semi geezer like me (in my 30's).

Anyway, 1 & 3 were relatively well known, and well described by the books I used. Perhaps they still were (are?) a bug, but then I didn't use "official" documentation, whatever that may be. Can't remember about 2. BCD mode was rarely used at most, I think.

Btw, when I encountered this RISC/CISC business back in late 80's/early 90's, I thought to myself: "Hah, it's just like 6502 vs. Z80/8080. What's the big deal?"

Thanks for the post - brings back fond memory of hacking on Apple II when we could fiddle with every address/IO directly.

Re:What???

[Profane MuthaFucka]

Nonsense. You conjugate it.

I Errata, you Errated, they are eratting, we erratumed.

Re:What???

[xSauronx]

well someone just got schooled. you show him!

Re:What???

[Anonymous Coward]

Also defined in TFA as: Chipmakers refer to chip-level problems as errata. Errata are fairly common in microprocessors, though they vary in nature and severity. I'm a geek and all too who never reads the article.

Re:What???

[I Like Pudding]

Well... I can't remember any for my beloved 6502.

It's easier not to screw things up when you're building a chip on a silicon process the size of Duplo blocks.

Re:What???

[argontechnologies]

Ahhh yes the 6502..... Beloved processor of my KIM micro computer. Damn that thing rocked!

Re:What???

[kaizokuace]

I still don't get why people still call the whole computer the hard drive! it makes no sense! Also these same people refer to uploading as downloading! And its not just old people!

Re:What???

[Anonymous Coward]

Hell, even my local department store puts posters up, labelled erratum, to mention errors in their flyiers/ads...

Re:What???

[rbanffy]

Thanks for destroying my belief the 6502 was perfect. ;-)

I guess I never ran across any of those problems (that, or my distant memories have already faded to pink). Were all 6502s like that or there were differences between MOS and Rockwell and the later 65c02 processors?

And, AC, yes. The 6502 is very RISC-ish. But, at that time, being RISC was not considered cool enough to be marketed as such, not to say I don't know if the acronym had already been invented.

I loved that page zero thing. Very, very fast. One could do things in a 1 MHz 6502 people wouldn't touch in a 4 MHz Z-80...

Let the fangeezer wars begin.

Re:What???

[jamesh]

Any Futurama fan will also know that Bender's brain is a 6502, as revealed by the 'F Ray' in 'Fry and the Slurm Factory'

Re:What???

[cowbutt]

I loved that page zero thing. Very, very fast. One could do things in a 1 MHz 6502 people wouldn't touch in a 4 MHz Z-80...

On the other hand, use Z80'ers had single instructions for block data copy (LDIR) and similar instructions for IO IN/OUT (OTIR/OTDR/INDR/INIR).

Re:What???

[Ihlosi]

I'm a geek an all.

I'm afraid you're not. You've obviously never read the datasheet of a microprocessor or microcontroller. Turn in your geek license and try again.

Re:What???

[baadger]

... and AMD isn't (currently) going to fix it.

The article summary says they released a BIOS workaround to mobo manufacturers. A fix with a 20% performance hit is still a fix.

Re:What???

[Oldstench]

AMD should mimic GMT (http://www.gmtgames.com/t-GMTLivingRules.aspx/) and release Living Cores. That way, whenever errata are posted, we can just grab the latest version of the core for free and continue on our merry way.

Re:What???

[Muad'Dave]

The Z-80 was my first processor that I wrote machine code for. Note that I didn't say 'assembly' - I didn't have an assembler for my TRS-80, do I hand-assembled the instructions and POKEd them into memory.

I liked the dedicated I/O instructions, too, but they made porting unix to it difficult - the Unices of the day all assumed memory-mapped IO, not a separate I/O architecture. You could memory map the devices, I suppose, but that wasn't how it was back then. Oh well!

I got spoiled by having lots-o-registers on the Z-80 - when I 'graduated' the 6502, I was dismayed to find essentially 3 registers: A, X, and Y.

Re:What???

[John Courtland]

If you check out the wikipedia article, there's a few more errata listed under the 'dubious features' heading. It appears most of the severe errata were resolved in the CMOS implementation of the processor.

http://en.wikipedia.org/wiki/6502#Dubious_features

Re:What???

[Johnny Mnemonic]

The conventional terms used for erratum, however, are usually "error" or "bug".

Not quite true. An erratum refers specifically to the document that describes the bug or error, not the bug itself. For instance, in conversation you might say you had a bug in your program; you wouldn't say that you had an erratum. Once you wrote down a description of the bug and published it, you could refer to that document as the erratum--and at that point "erratum" is synonymous with the bug itself (as it's described in the document) and the document.

(If the bug changes character later, then "erratum" would refer only to the bug as it's described in the doc, not as the bug's new behavior--until it's described in an addendum to the erratum)

Wow, thats pedantic. But in CPU failure analysis, it matters ;)

Re:What???

[gad_zuki!]

Hello sir, it looks like you accidentally mistyped "slashdot.org" into your browser when you were trying to type "digg.com." Please try again this time. If you need assistance please press ##451 on your phone for the delivery of a half-blind helper monkey.

Re:What???

[PMuse]

I'm quite certain I'm a geek and, while I've dealt with various kinds of errata for decades, I can't say with any certainly that I've heard the term "erratum" before in the singular. Which is not to say the Latin isn't obvious, just that most English fora use the English when talking about a single error.

Re:What???

[BlackSnake112]

Don't forget the people who point to the monitor and call that the computer. These people are not computer geeks but it is still funny when they say that.

Re:What???

[nuzak]

You're indeed correct. Which makes the article's title not just pretentious, but wrong (is it a bug report that's the problem, or the bug?) Oh well, at least it's spelled correctly.

Re:What???

[Molochi]

I started hearing PC enclosures being referred to as "harddrives" several years ago, towards the end of my stint as a tech. I did ask a couple of people where they picked up the term and they said a previous "buy more" tech had told them that was what it was called. They were actually looking for a term that described a loaded box, sans anything plugged into it because they weren't cognizant that "PC" didn't need to refer to anything more than the box itself and that replacing a harddrive didn't mean they needed a new PC.

Re:What???

[Saffaya]

"I got spoiled by having lots-o-registers on the Z-80 - when I 'graduated' the 6502, I was dismayed to find essentially 3 registers: A, X, and Y."

I'm sure then you can understand the terror and abjection felt by the generation that grew up on ATARI ST and AMIGA sporting the Motorola 68000, with its 16 (sixteen) universal 32 bits registers (just save 1 for the SR), when they had to study the 8086 instruction set at university.
And I pity from the bottom of my heart those that had to actually work on this family of retarded architecture processors at assembly level.

Re:What???

[Muad'Dave]

I couldn't agree more. The x86 architecture was the most hacked-up abomination I've ever seen. The 68k series is really slick, and completely symmetrical wrt what operations could be performed on what registers. I hate having certain ops limited to certain registers. Aaargh!

I use the Microchip PIC family now for hobby stuff, and grit my teeth whenever I have to deal with the obnoxious memory bank select bits.

Re:What???

[Anonymous Coward]

The 68k series is really slick, and completely symmetrical wrt what operations could be performed on what registers.

Not so -- there are eight address and eight data registers, after all! IIRC address registers were not available as sources/destinations for all arithmetic instructions, and obviously data registers could not be used as memory addresses. That's a major break in symmetry.

If you study the machine encoding of the instructions, it's clear this was driven by the need to pack instructions into 16 bits while supporting a wide variety of addressing modes. Making it implicit by opcode whether an instruction operated on address registers or data registers allowed them to shave 2 bits off all instruction formats which needed to specify 2 registers.

68K might have been better off if it had 16 truly orthogonal general purpose registers at the cost of some addressing modes. Fancy addressing modes proved to be the bad part of CISC in the long run.

I use the Microchip PIC family now for hobby stuff, and grit my teeth whenever I have to deal with the obnoxious memory bank select bits.

I recommend switching to the Atmel AVR family. Aside from not having to bank select all the time, the instruction set was designed to make it easy to target a C compiler for the architecture despite it being an 8-bit microcontroller, and as a result there is support in mainline GCC for the AVR architecture. Just grab the gcc source and compile it with the correct switches to target AVR... or download one of the prepackaged avr-gcc cross compilers.

(They've also now got a 32-bit variant, AVR32, which I have not tried yet. Not sure about the status of gcc support for AVR32 either.)

Re:What???

[Anonymous Coward]

Z80, of course, was a huge improvement over 8080. Beside the clock speed, it also doubled the registers. Still, it inherited the inelegant instruction set with many op codes specific to particular registers.

6502 made up for the lack of registers with zero-page addressing mode, but then there is only a single zero-page much of which was dibbed by system monitor code.

Funny how this nasty Intel instruction set nevertheless "inherited the earth" today. A powerful commentary on Darwinism.

Re:What???

[Anonymous Coward]

That supposed to be a complement for 6502? ;-)

Re:What???

[fitten]

"fix it" as in replace your defective, slow part with one that doesn't have that problem.

Re:What???

[aron1231]

let us bow to the all-knowing geek master...

No.

[Anonymous Coward]

Thus concludes another episode of Short Answers To Stupid Questions.

Re:No.

[0111 1110]

Thus concludes another episode of Short Answers To Stupid Questions.

Don't you mean snappy answers? Al Jaffe must be rolling in his grave.

AMD making big mistakes under pressure!

[Anonymous Coward]

Errata are very common but how company handles them is a big factor in deciding things. I certainly hope all review sites will rerun benchmarks.

Anandtech I'm looking at you.

NDA for patch?

[Cajun Hell]

Check this out:

Linux users may have another option in the form of a patch for that operating system's kernel. Sources estimate this patch's performance hit at less than one percent, but it comes with several caveats. At present, the patch purportedly only applies to the 64-bit version Red Hat Enterprise Linux, Upgrade 4. Customers must sign a non-disclosure agreement in order to obtain the patch...

Good thing it's just a patch, as opposed to a derived work of someone else's GPLed code. I wonder what the FSF guys would say about that. I also wonder: Red Hat, why?

Re:NDA for patch?

[wizardforce]

I also wonder: Red Hat, why?

I imagine that their reasoning was that it was better to offer a patch, closed or not that benefited their users that would choose to make use of this processor. The solution isn't elegant, more like repairing an aircraft's hull with duct tape but apparently it is better than the alternatives they tried.

Re:NDA for patch?

[Crispy Critters]

It is silly to think that RH is ignoring the GPL.

There are other possibilities that are more likely. For example, perhaps the patched kernel is doing something like loading microcode into the processor. The kernel code would be GPLed but the microcode would not be.

Re:NDA for patch?

[TheThiefMaster]

I doubt AMD would reveal the kernel code for altering a cpu's microcode. That would just be asking for trouble. The "patch" is more likely a call into a binary-only kernel plugin.

Re:NDA for patch?

[42forty-two42]

There is already a microcode loader for Intel chips. If you load bad microware, you run the risk of hosing the chip, or at least crashing, but that's your choice.

Re:NDA for patch?

[Burdell]

I also wonder: Red Hat, why? The article says the patched kernel is not available via Red Hat's normal support channels, but it doesn't say who is distributing a patched kernel (or requiring an NDA) at all. Red Hat may not even be involved (since the RHEL kernel source is available, anyone could build patched kernels).

Re:NDA for patch?

[kelnos]

Actually, loading bad microcode into an Intel CPU isn't a big deal at all -- the load isn't persistent; you have to reload the microcode every time you boot. So if you load bad microcode, you simply power-cycle the box to fix it.

Re:NDA for patch?

[SmokeyTheBalrog]

I'm sure there will be no patched kernel distributed to avoid a class of licenses.

Instead this will be like patching a program. You download the patch you run it and it changes code in the copy of Linux you have already installed.

This actually, might be a sign of things to come as different flavors of Linux try to keep certain new feature proprietary. These features must be downloaded separately as a closed source patch. (Unless GPL covers this, can anyone answer this?)

Re:NDA for patch?

[Alsee]

So if you load bad microcode, you simply power-cycle the box to fix it.

Unless your microcode contains an HCF op :)

-

Re:NDA for patch?

[todd1000]

Not really, I accidently killed an Intel CPU doing this. We had to replace the CPU, only option. It may be different depending on the board, this was a specialty server board.

Re:NDA for patch?

[fmoliveira]

If you can pass a patch trough the gpl this way, dynamic linking should be a non-issue. I never believed that something dynamic linked was a derived work anyway.

Re:NDA for patch?

[kelnos]

So if you load bad microcode, you simply power-cycle the box to fix it. Unless your microcode contains an HCF op :) I wonder if the Linux kernel has a "CPU is on fire" error message like the old "printer is on fire" message ^_~.

Hmph

[moogied]

Hardware provided to the press for reviews did not include the fix, conveniently overstating Phenom performance

Yet no press people noticed the reportly huge bug?

in real life...

[User 956]

He characterized the issue as a race condition in the TLB logic "where the other guy wins who isn't supposed to win,"

This pretty much describes the college admissions process, as well.

Re:in real life...

[Anonymous Coward]

I don't want to hear how you couldn't get into Yale and now have to attend the local community college. Now that that's out of the way: no pickle, extra cheese and I want my chocolate shake in the commemorative cup! Large isn't big enough for me!

Re:in real life...

[dgatwood]

Wait, does this include the Electoral College? So Gore really was supposed to win?

:-D

Re:in real life...

[Anonymous Coward]

I may work here, but ur the one eating this crap.

Re:in real life...

[Anonymous Coward]

At least I can afford to, community college boy!

Re:in real life...

[Anonymous Coward]

Once you graduate you will realize that getting a job offer can be the same way.

And pretty much every organization in the world works that way. Do you know how difficult it is to truly assess the value of people? Inevitably people will make calls that either (a) aren't right or (b) are right, but not in your favor so you think they're wrong.

It's a tough world, I'm sorry.

This doesn't have to be so bad

[Anonymous Coward]

AMD can turn this into a PR boon to one-up Intel at the "Green" initiatives. All they have to do is repurpose the uncut wafers of these chips as solar panels and then retile the outside of all their buildings with the panels. This will save money on their energy bills and they can even start a new Ad Campaign:

"AMD Outside".

Re:This doesn't have to be so bad

[youthoftoday]

SOMEONE's been waiting a long time to say that

Re:This doesn't have to be so bad

[canuck57]

AMD can turn this into a PR boon to one-up Intel at the "Green" initiatives. All they have to do is repurpose the uncut wafers of these chips as solar panels and then retile the outside of all their buildings with the panels. This will save money on their energy bills and they can even start a new Ad Campaign:

It will not stop me from buying AMD. The only processor I have ever (of 20+) had that cooked was a P4 2.4GHz HT on a Intel PERL mobo no less! But I have abused two older AMD chips I still have running with over-clocking, dust plugs in the fans etc and in a an el-cheap mobos. One even ran with a defective fan for months. It did crash, but I caught the fan doing it one day where it would just stall. Replaced the fan, been running ever since. Those AMD just keeps on ticking, a 1200 and 2000+. Totally abused and owe me nothing.

And the AMD X2 I bought last year, runs flawlessly. BTW, I do have 2 P4 heaters still running. Yep, I have a few, even a Sparc.

But looking for another X2 for Christmas. And anyone who buys a chip with a serial number increment of less than 100,000 for production or stability are nuts. Just like a Chrysler, GM or Ford, you don't want the first 100,000, nor the last 100,000. The sweet spot is in the middle.

And although down, I do look forward to the day AMD kicks Intel ass once again. Too bad AMD execs sidelined AMD engineering with this ATI noose. ATI is going to set AMD back 4 years by the time all is counted. I do have respect for Intel PIII 650Mhz duals in a Supermicro though, they too keep ticking.

Re:This doesn't have to be so bad

[leenks]

That's real funny. We built three dual PIII 650MHz duals, Supermicro mobo, and two are now dead and the third is unstable. None of my P4s cooked (the oldest is a 1.7GHz that is still running nicely as a dev server), but several Athlon systems I've seen have died where fans failed on heatsinks. Swings and roundabouts...

Re:This doesn't have to be so bad

[Anonymous Coward]

I think Intel takes a few days to make 100,000 CPUs.

Re:This doesn't have to be so bad

[Anonymous Coward]

You do work for AMD, don't you?

Bummer

[El Pollo Loco]

Wow, bad times for AMD. They're losing the war against intel, and now have another set back. A 20% performance penalty is simply unacceptable for any processor. The fact that it is for brand new ones makes it an even bigger slap in the face for consumers.

Re:Bummer

[the_humeister]

Hmmm... I suppose that I should disconnect this Phenom-powered computer running Windows from this nuclear power station I'm working at...

Re:Bummer

[forkazoo]

Wow, bad times for AMD. They're losing the war against intel, and now have another set back. A 20% performance penalty is simply unacceptable for any processor. The fact that it is for brand new ones makes it an even bigger slap in the face for consumers.

Well, AMD doesn't sell used processors, as far as I'm aware, so where else would AMD have problems than in brand new processors? I mean, seriously, if a bug was found today in 1 GHz Durons that required a slowdown to work around, the headline wouldn't be "AMD Processor has bug," it would be, "AMD QA fucking incompetent, take years to notice problem with processor." You would rather they just ignored the problem until they came out with something newer so that the problem wouldn't be in a brand new processor?

Re:Bummer

[cnettel]

Well, as AMD was already overall not on par with Intel per clock, a 20 % decrease, if that's the general result, would indeed hurt them. It would basically make even the (just about) cheapest Intel offering competitive with the top-notch AMD CPU.

Re:Bummer

[T-Bone-T]

If I was running servers with Phenoms and I found out I needed to spend thousands of dollars more on servers to get the performance I should have been getting, I'd ask for a refund and go with Intel. That isn't something to be taken lightly.

By your reasoning, it is alright to tell customers incorrect performance limits of a product because they might never find out?

Re:Bummer

[contrapunctus]

What if you were doing scientific computing? 20% drop could mean a lot of time for a calculation. I use to run calculations that would take months...

Re:Bummer

[scottv67]

What if you were doing scientific computing? 20% drop could mean a lot of time for a calculation. I use to run calculations that would take months...

Just thinking out-loud here: Did you trying pushing-in the Turbo button?

Re:Bummer

[canuck57]

Wow, bad times for AMD. They're losing the war against intel, and now have another set back. A 20% performance penalty is simply unacceptable for any processor. The fact that it is for brand new ones makes it an even bigger slap in the face for consumers.

Not if the processor/mobo combo is 60% of the cost of a Intel heater.

What are we trying to do here, compute pi to 14 million decimal paces in 5 minutes or less?

Sooner or later AMD will come back. My experiences with Intel, is a soon as they get the lead they fall asleep. And AMD, while bruised will just wake up.

Re:Bummer

[Anonymous Coward]

Bad times? That's an understatement!

They're apparently losing a "war", and along comes a "slap in the face". Ouch!

What's next? Genocide? Stubbed toe?

Re:Bummer

[dreamchaser]

or maybe you need 12 servers instead of 10 to serve your high volume web site

Gee, I just paid 20% more than I should have for my servers? You do know that it isn't chump change for someone running a small business. Seriously, do you understand how silly your statement is?

This is a serious problem for AMD. It's amazing how many hoops some people will jump through for fanboisim.

Re:Bummer

[Anonymous Coward]

Since when does an AMD motherboard and CPU equal a mere 60% of the cost of a comparable Intel CPU alone? You're dreaming. The quad core Q6600 for $266 is by far the best deal for people that want quad core CPUs.

Intel is also showing no signs of slowing down with the tick-tock model. This year Intel released it's new 45nm technology. Next year they'll release the Nehalem archiecture. In 2009 they introduce 32nm technology. It goes on from there, alternating between a new architecture and a new process technology each year. Such a rapid pace of technology must be depressing for AMD who can't seem to get anything out on time! Even worse, when they finally do get it out the door it's plagued with bugs like this that slow performance by 20%!

Re:Bummer

[jericho4.0]

Are you nuts? Thats 20% more cost upfront, 20% more power, 20% more cooling, %20 more space.

Re:Bummer

[InvalidError]

Just thinking out-loud here: Did you trying pushing-in the Turbo button?

STACK OVERFLOW
SYSTEM HALTED.

Stupid Turbo button ruined my * Quest games countless times and unfortunately for me, most were practically unplayable at the default 4.77MHz. My next PC was a 486DX33 on which many of those games were now too fast to be playable.

Re:Bummer

[poopdeville]

What are we trying to do here, compute pi to 14 million decimal paces in 5 minutes or less?

That's not that many digits... It wouldn't take even 5 minutes on a Core 2 Duo.

Re:Bummer

[Tablizer]

Hmmm... I suppose that I should disconnect this Phenom-powered computer running Windows from this nuclear power station I'm working at...

The *person* who chose Windows for that task is more defective than the AMD chip.

Re:Bummer

[jackbird]

I wait anywhere from six hours for a few days for my raytracer to calculate a print-resolution still image on my (admittedly long in the tooth) dual-CPU Athlon for my clients, and rent time on a 750-node cluster when they want animation. 20% is a huge deal.

Re:Bummer

[Z34107]

20% is generally the difference between the $1000 CPU and the $200 CPU.

Re:Bummer

[Technician]

Hmmm... I suppose that I should disconnect this Phenom-powered computer running Windows from this nuclear power station I'm working at...


Naw, keep using it.. it's Ok for web browsing.

The Windows EULA will keep you safe if you follow all the requirements.

Read it to understand the statement.

Re:Bummer

[Alsee]

Every time I tried that my car would go flying through the air.

-

Re:Bummer

[hey!]

Hey, that's a thought. Maybe AMD mobos should have an Obrut switch header.

Re:Bummer

[Anonymous Coward]

You are trolling.
We've had lower power than AMD for a while here.
Better performance? Check.
Lower Power/MFLOP? Check.
Less Errata? Check.
Price? GoodEnough (TM).

Anon for obvious reasons. Let me tell you though, Intel will not be complacent again for a long time. We got our asses handed to us once (and only once mind you). It sucked... Bad. No more. We have a 2 year process cycle, they have a 4 or 5 year one. We have parallel design teams (one working on the next gen shrink of a family, the other working on the next first-gen part) I doubt they do. We've been trimming a lot of "fat" (that hurts because some of my friends are "fat" and will be looking for a job) to get to our core strengths. AMD is attempting to grow and having pains.
AMD will come back, but we will remain ahead.

Obvious disclaimer: I m not authorized to speak for the company, blah blah blah, nothing I say can be construed as an offer of anything, etc. I'm posting anon you I may be making this all up.

Re:Bummer

[Anonymous Coward]

This ladies and gentlemen is called AMDenial - there is no conroe

intel hasn't built a space heater since the netburst line was chopped.

Cue the intel jokes

[Anonymous Coward]

In 3.... 2... 0.9999921341...

Re:Cue the intel jokes

[T5]

IC what you did there...

Re:Cue the intel jokes

[nmb3000]

Some of the (obligatory) Pentium jokes were pretty funny. From a text file I've had laying around for quite a while:

--------------

Intel's new motto: "United We Stand, Divided We Fall"

Q: How many Pentium designers does it take to screw in a light bulb?
A: 1.99904274017, but that's close enough for non-technical people.

Q: What do you get when you cross a Pentium PC with a research grant?
A: A mad scientist.

Q: What's another name for the "Intel Inside" sticker they put on Pentiums?
A: The warning label.

Q: What do you call a series of FDIV instructions on a Pentium?
A1: Successive approximations.
A2: A random number generator.

Q: Complete the following word analogy: Add is to Subtract as Multiply is to:
        1) Divide
        2) Round
        3) Random
        4) All of the above

Q: What algorithm did Intel use in the Pentium's floating point divider?
A: "Life is like a box of chocolates." (Source: F. Gump of Intel)

Q: Why didn't Intel call the Pentium the 586?
A: Because they added 486 and 100 on the first Pentium and got
    585.999983605.

Q: According to Intel, the Pentium conforms to the IEEE standards 754
    and 854 for floating point arithmetic. If you fly in aircraft
    designed using a Pentium, what is the correct pronunciation of "IEEE"?
A: Aaaaaaaiiiiiiiiieeeeeeeeeeeee!

Q: Did you hear about the new "morning after" pill being developed as a
    replacement for RU-486???
A: Its called RU-Pentium. It causes the embryo to not divide correctly.

TOP TEN NEW INTEL SLOGANS FOR THE PENTIUM

    9.9999973251 - It's a FLAW, Dammit, not a Bug
    8.9999163362 - It's Close Enough, We Say So
    7.9999414610 - Nearly 300 Correct Opcodes
    6.9999831538 - You Don't Need to Know What's Inside
    5.9999835137 - Redefining the PC -- and Mathematics As Well
    4.9999999021 - We Fixed It, Really
    3.9998245917 - Division Considered Harmful
    2.9991523619 - Why Do You Think They Call It *Floating* Point?
    1.9999103517 - We're Looking for a Few Good Flaws
    0.9999999998 - The Errata Inside



Worth a laugh anyway :)

Re:Cue the intel jokes

[Anonymous Coward]

G/god(s/ess/es)!!! ;-) This is why I love this /.

Erm... budha, zeus, odin, ramen dude, my ancestors, all others - can't be too safe.

Re:Cue the intel jokes

[Tablizer]

In 3.... 2... 0.9999921341...

I was gonna post that joke first, but my AMD processor wasn't fast enough.

Re:Cue the intel jokes

[earlymon]

Dont' forget the top sig the week that was published - "I am Pentium of Borg - you will be approximated."

Re:Cue the intel jokes

[BlueParrot]

That's supposed to be "We're Pentium of Borg. Division is futile, you will be approximated."

"because", not "despite"

[statemachine]

AMD has also blamed this bug for the delay of the 2.4GHz Phenom, despite the fact that the erratum is unrelated to clock speed. [Emphasis added.]

Why does the summary claim this? I read through both articles, and AMD says this is a hardware issue across both chip models. Since this is a hardware issue, wouldn't it stand to reason that AMD would hold up a related chip because it's a hardware bug across both chip models and not because it's a clock speed issue? I'm not sure where the "despite" comes into play. I didn't see where the article said that AMD is not delaying a different speed Phenom.

Re:"because", not "despite"

[wizardforce]

indeed, I would have thought the reason why they didn't release the chip was because the bug caused it to be 10-20% slower in either case and probably affects similar chips of different clock speeds.

Re:"because", not "despite"

[Wavicle]

You have to read a follow-up article to the techreport.com one here: http://techreport.com/discussions.x/13724. Which reads:

Apparently contradicting prior AMD statements on the matter, Saucier flatly denied any relationship between the TLB erratum and chip clock frequencies. He also said there's no relationship between clock speeds and the performance degradation caused by the BIOS-based fix for the erratum.

I imagine that is where the article got the information.

Re:"because", not "despite"

[mr_mischief]

IANAEE (electrical engineer) and I've never built my own CPU, even from TTLs or in a simulator. It makes sense to me, though, that while chips having the error in them may not be tied to specific clock frequencies that the chances of encountering the bug still could be.

If it's a race condition in hardware, there's a good chance it's clock-sensitive. The bug probably exists in the whole line, sure. It'll manifest more as the clock ticks are closer together, because the margin for error without triggering the reversal of steps is smaller. If it's a matter of the wrong signal being sometimes being asserted because the edge of a clock line transition was missed, it's logically going to happen more when the clock cycles are shorter.

A bug being in the whole line regardless of clock frequency and that bug becoming more of an issue at higher clock frequencies are not at all mutually exclusive conditions. The higher frequencies and higher rates of the error may not coincide, but there's nothing in the article to logically say they don't.

The erratum probably does apply to the whole line equally but probably manifests as a percentage of the time in use as some function of the frequency.

For any geek wanting a basic understanding of issues like latching times, gate propagation delays, and other analog electrical signaling issues inside a digital CPU, I recommend the first few chapters of Structured Computer Organization. The book builds upon basic designs of computers from using TTLs to designing a CPU, then up by layers through microcode, designing an assembly language, and more. I have an older edition at home which covers up through the 68030 and the 80386 as examples. The newer one covers up through the Pentium II, the UltraSparc, and the Java chips. The book won't make you an electrical engineer by any means, but the discussions of the tricky timing issues within even simple CPUs might be useful here.

As for the clock speed not effecting the percentage loss in efficiency due to the microcode fix... well, yeah. The microcode is the same across the line regardless of the clock speed. If you insert two identical strings of instructions A1 and A2 into an identical pair of microcode stores B1 and B2, the resulting patched microcodes C1 and C2 will likewise be identical. The faster processor will decode and execute the microcode at the same clock speed as before, and so will the slower one. They'll each have the same percentage slowdown relative to their own clock speeds, because they're running the same microcode. We're not talking about two different generations of processors or even two different revisions. It's the same processor design at two clock speeds. One is going to get the same nerfs and buffs for any microcode change proportional to their clock speeds as the other.

Re:"because", not "despite"

[Erpo]

From TFA: [AMD's] original statements about the issue gave the impression it only affected Phenoms clocked at 2.4GHz or higher.

In any case, I think the word despite is used in the quoted sentence because AMD is releasing flawed Phenoms with clock speeds lower than 2.4GHz. This would mean AMD is lying about the reason why they delayed the 2.4GHz Phenoms, since AMD's actions would establish that this erratum alone is not sufficient reason for them not to ship a particular CPU. So AMD is making a claim despite the fact that there is evidence that their claim is false.

Re:"because", not "despite"

[Chris Burke]

It makes sense to me, though, that while chips having the error in them may not be tied to specific clock frequencies that the chances of encountering the bug still could be.

That's absolutely true, and it doesn't even necessarily have anything to do with the circuits and signaling issues in a given pipe stage.

From the descriptions, this sounds like a straight-up logic bug to me. And that's still quite possible, especially in one of the more functionally complicated parts of the chips -- the interaction between caches and the TLBs. Bugs like this can also depend on clock frequency to the extent that the specific sequence of events that has to occur is more likely to happen when more stimulus is coming in. Notice that the problem here involves an interaction between the TLBs and the L3 cache. The TLBs are in the core, which would be running at 2.4 GHz. The L3 cache is in the Northbridge, which I think on those same parts is running at 2.2 GHz. There's a synchronizer between them. So if the problem involves caching TLB entries in the L3, then having the faster core means the northbridge is going to see more requests faster from its own perspective, and this could make encountering the bug much more likely.

I'd be willing to bet that the reason why AMD shipped the parts knowing there was a bug and claiming it was frequency dependent, then reversed their opinion, is for a straightforward reason: They looked at the bug and determined that for it to occur there had to be a certain ratio of core requests to north bridge clocks in order for the circumstances to arise. So don't stop shipping current parts, and delay the faster part until a fix can be implemented (even if the fix appears out of thin air, it will take 2-12 weeks before the fab can actually spit out fixed parts).

Except then it turns out they were wrong, and it can happen at lower frequencies. Oops.

Re:"because", not "despite"

[Anonymous Coward]

So in short, the flaw is not in the "logic" of the circuit (gate level) but in the "electronics" of the chip (transistor and interconnect level). Quite physical.

I'm too still doubtful of AMD's comments. The flaw might well affect clockspeeds after all, maybe manifesting so in just some fabbing batches and some usage situations, but manifesting nevertheless -- I feel right now you can't trust that it won't, absent more extensive testing and reports. Buyer beware, that is.

NDA not enforcible

[_merlin]

If it's a patch for the Linux kernel, which is distributed under the GPL, I don't think they can enforce an NDA. The patch may be used to create a derived work of a GPL'd product, so the derived work must also be GPL'd: so you can distribute it, as long as you include its source. This will be available for all Linux variants soon.

Re:NDA not enforcible

[TheThiefMaster]

The patch is under the NDA, the kernel is under GPL, so the resulting work (patched kernel) can't be distributed, because the licenses are incompatible.

The GPL only applies to redistribution. Private-use changes don't have to be GPL'd.

IANAL,TIJHIUI (I Am Not A Lawyer, This Is Just How I Understand It).

Re:NDA not enforcible

[42forty-two42]

However, the change /is/ being distributed - from red hat to the customers under NDA. Even showing code to contractors can be considered distribution (this is one of the things the GPLv3 addresses, but of course Linux is under v2)

Re:NDA not enforcible

[crymeph0]

Whoever is making the patch is redistributing it to the affected customers, and therefore may not have the right to require an NDA in the first place, depending on what the patch is.

Re:NDA not enforcible

[42forty-two42]

The NDA can be likely be enforced; what happens is Red Hat has no legal right to distribute the kernel under those conditions. If it does, it's just plain copyright infringement. IANAL, etc.

Re:NDA not enforcible

[mzs]

I have dealt with kernel code (vxWorks and Linux) that had workarounds for PHB (Marvell) errata that I did not have the access to because of NDAs and it is not a good place to be. You have this nearly uncommented code that you only know was added because of some number of errata and you can sort of vaguely guess what may be wrong. When it comes time for maintenance you are always very scared to perturb anything too much because you do not really know the details. IIt is no fun, AMD should have already released everything it knew in the errata list.

Re:NDA not enforcible

[jaxtherat]

What??!?!!!1onenenone I always though IANAL means he takes it up the pooper

Re:NDA not enforcible

[Rich0]

The patch isn't a derived work - it would be 100% RH code. RH can distribute it under any license they like.

Now, a patched kernel WOULD be a derived work, and that would have to be GPL.

Anybody can apply a patch to anything without any licensing issues, but you might not be able to redistribute the resulting product.

If RH were distributing a patched kernel not under the GPL, that would definitely be a problem.

Re:NDA not enforcible

[jlarocco]

But their change isn't under the GPL. If they were distributing a patched kernel, they'd have problems. But distributing the patch itself is okay.

Re:NDA not enforcible

[Michael Woodhams]

It depends on whether the patch is a derivative work. It certainly doesn't stand on its own.

There has been a possibly analogous situtations with DVD bowdlerization. In the ClearPlay system, you have a special DVD player plus filter files for each movie. When you play a DVD, it looks at the filter file and skips stuff as required. Is the filter file a derivative work? The studios tried to challenge ClearPlay legally, but the suit was interupted when the Federal government passed a law explicitly allowing this - so no useful precident was set. I'm not sure if 'the filter file is a derivative work' was part of their argument - it might have been based on artistic control instead.

(There was also an outfit called CleanFlicks which would actually provide an edited DVD, having bought and destroyed a legal DVD of the movie for each edited one they sold. They did get shut down by a copyright suit.)

http://en.wikipedia.org/wiki/Cleanflicks
http://en.wikipedia.org/wiki/ClearPlay

Re:NDA not enforcible

[Plaid Phantom]

IANAL,TIJHIUI

God help us. It's growing. Soon, someone will open the Acronymicon and all /. discussion will fall into the obscure non-language of the darkness.

Re:NDA not enforcible

[ortholattice]

But their change isn't under the GPL. If they were distributing a patched kernel, they'd have problems. But distributing the patch itself is okay.

So I can develop a proprietary mod of the kernel, diff my binary against the standard kernel binary, then distribute my proprietary mods as a binary patch to the kernel? Sounds like quite a loophole.

Re:NDA not enforcible

[todd1000]

You can distribute a binary *kernel module* and not be in violation of any licenses. I don't think you can patch the kernel itself and not distribute source. I don't know which Red Hat is doing.

Re:NDA not enforcible

[HiThere]

It's a loophole, but not all that large of one. And it's one that will cause you an immense amount of work over time if you choose to use it...especially if the kernel developers object, as they can cause small changes in any area they feel like, so long as the code ends up doing the same thing...but binary patching doesn't work on what code does, but on bit pattern matching. Even if they just ignore you changes are likely to occur.

Also different distributions patch their kernels differently. Some people compile their own kernels (with non-spec options), etc.

It's one thing for a distributor to ship a binary patch to their kernel version. That's a reasonable effort, with a bounded amount of work required. To try to ship a binary patch that applies to "Linux kernels" is probably hopeless.

Re:NDA not enforcible

[Anonymous Coward]

MPU! VF!

No, but it looks bad

[_merlin]

It's not like there aren't problems with Intel's CPUs - just take a look at the problems with the MMU in the Core 2 - but no-one is suggesting Intel is doomed. It would just be better if AMD had admitted this when they first knew about the issue rather than sending out review units that are known to have serious issues.

Re:No, but it looks bad

[ceoyoyo]

No, but AMD seems to be in a pretty delicate state. Their stock is pretty low and they've taken a beating from a newly-competitive Intel. They don't have a big advantage in processor speed anymore, nor power, nor even price. Halting shipment on an entire line? Not good. If they eventually have to recall it... bad.

It might not be AMD's doom, but they're really not that many big screwups away.

Re:No, but it looks bad

[Anonymous Coward]

I think you may be right. Googling 'amd cash position' consistently indicates 'poor'. A lot of analysts seem to feel they used too much cash to buy ATI.

Add to that a recessionary outlook for 2008, and it could be a perfect storm for AMD.

Re:No, but it looks bad

[bigdavesmith]

I agree with your point, but I think this is a lot more serious, and bad news for us consumers. I feel like AMD/ATI haven't been giving Intel/nVidia the trouble that they did just a couple years ago, and the performance race that I so enjoyed is over. This just makes things worse.

Oh well. At least I can buy a computer now and it won't be outdated for a bit longer.

Re:No, but it looks bad

[TubeSteak]

No, but AMD seems to be in a pretty delicate state. Their stock is pretty low and they've taken a beating from a newly-competitive Intel. They don't have a big advantage in processor speed anymore, nor power, nor even price. ...

It might not be AMD's doom, but they're really not that many big screwups away. As far as most US consumers know (the ones that have any idea at all), there are just two companies that make CPUs: AMD and Intel. Mac users might know that Apple used to use IBM CPUs.

AFAIK, the worst thing that could happen to AMD is they get bought up, because I can't imagine any scenario where Intel literally becomes a monopoly in the consumer CPU market.

Re:No, but it looks bad

[ceoyoyo]

It doesn't matter if the consumer knows who makes the CPUs if AMD has to recall theirs. That will cost them money -- money they can ill afford to lose. It's also shutting down their processor sales at Christmas.

There are lots of things that could happen to AMD. If they do too poorly they won't be able to afford the R&D to keep up with Intel and they'll get relegated to the discount market from whence they came, or they could get bought out.

Re:No, but it looks bad

[Mathinker]

> It's also shutting down their processor sales at Christmas.

I know this is Slashdot, but most people don't stuff stockings with CPUs.

I'm sure that any kind of computer being bought for Christmas has a CPU which was manufactured a minimum of a month or two ago. I'd actually guess that their processor sales slump somewhat in December and January because of surplus production of assembled computers in the previous months (and because at least some of the workers who buy CPUs and upgrade business computers go on vacation).

Re:No, but it looks bad

[Ihlosi]

It's not like there aren't problems with Intel's CPUs - just take a look at the problems with the MMU in the Core 2 - but no-one is suggesting Intel is doomed.

That's because Intel's piggy bank is much, much fuller than AMDs. Not to mention the huge marketing weight of their brand names.

Re:No, but it looks bad

[ceoyoyo]

Yes, isn't that just perfect -- the biggest shopping season of the year and your products are stuffed with CPUs that you may be forced to recall. I guess that's why AMD stock is lower than it's been in at least two years.

Re:No, but it looks bad

[Dr. Smoove]

Cutting down sales on quad core processors? Are kids these days really being given systems with quad core processors?

Re:No, but it looks bad

[ceoyoyo]

Big kids get (or buy themselves) presents at Christmas too.

Re:No, but it looks bad

[clayne]

and then use 10% of their actual capabilities...

Re:No, but it looks bad

[ceoyoyo]

Be fair... the virus scanner will use a good solid core, so that's 25% at least.

Expect Theo de Raadt

[andreyvul]

to make a big issue out of this, as he did with the Core 2 errata.

(For mods that are troll-tag-happy, Theo de Raadt is the maintainer of OpenBSD and is security paranoid.)

Re:Expect Theo de Raadt

[Chandon Seldon]

This isn't (known to be) a security issue. Basically when the bug gets triggered, the processor just crashes. I guess you could carefully craft input to trigger it as a denial of service attack...

Re:Expect Theo de Raadt

[the_brobdingnagian]

I don't know what Theo de Raadt has to do with this, I certainly did not see his reaction about this on one of the OpenBSD mailinglists. Can you at least explain what this erratum has to do with security. Because it does look like you're trolling. I do think this is not an isolated event and we can expect more and more processor bugs in the coming years. It's time to leave the antiquated x86 design behind us and move to a cleaner architecture.

Re:Expect Theo de Raadt

[andreyvul]

Security issue: Crafting input to crash the computer.
Processor arch: 68k, MIPS, powerpc, sparc?

Re:Expect Theo de Raadt

[Wavicle]

I guess you could carefully craft input to trigger it as a denial of service attack...

Yup. That's what we in the business call a "security issue."

Re:Expect Theo de Raadt

[forkazoo]

It's time to leave the antiquated x86 design behind us and move to a cleaner architecture.

I used to sing the same song, but it really doesn't apply any more. The parts of the chip that are genuinely X86 specific are quite small on a modern CPU. Consequently, a change in instruction set would actually have a very slight impact on a modern CPU, except for probably making it slower. If AMD had been using this design to build a souped up MIPS processor, there is absolutely no reason to suspect that they wouldn't have run into exactly the same sort of trouble. Sadly, if somebody wanted to make a really modern architecture, they'd want to make some sort of uber CISC which actually operates directly on a compressed instruction stream to make maximal use of cache space and instruction fetch bandwidth. Thankfully, nobody has had the stomach to invent such an abomination! :)

Re:Expect Theo de Raadt

[dancingwllamas]

I believe he was referring to this story from awhile ago. You're still right though - I believe the previous story was referring to Core2 sometimes not obeying the NX bit, which is a much bigger security issue than the processor crashing.

Hopefully...

[cmacb]

Intel will have copied these features and have similar problems.

Old issue, really

[Uzito]

My good old Opteron 170 had the same stupid issue with unsynched core clocks. What is new here?

Re:Old issue, really

[CajunArson]

The old opty 170 didn't have an L3 cache which is where the bug lies. This bug is rare, but it is reproducible when the CPU is under heavy load and was one of the reasons why AMD was trying to get hardware reviewers to come to an AMD event in Tahoe to run benchmarks on AMD approved systems instead of just dropping chips into FedEx packages. Causing a full-blown system freeze is also on the serious side when it comes to bugs. There have been even more problems, techreport has a story that unlike the hand selected systems that ran at Tahoe, many of the actual consumer phenoms you can buy today actually use slower HT speeds (1.8Ghz vs. 2.0 Ghz in the demos). This means that the memory subsystem (AMD's one theoretical strength over Intel right now) is slowed down, so the somewhat unimpressive initial results are actually overstatements of what the consumer chips can do. (article here).

    AMD is in a world of hurt right now. The "true" quad-core line appears to be nothing more than marketing hyperbole since year-old q6600's are faster clock-for-clock than Phenom is. AMD will hopefully get these bugs ironed out... by next February. Even then though, AMD will have chips that are MASSIVELY expensive to make, but that they can't sell for the higher prices Intel is able to command. AMD would be fine if they had an expensive chip they could sell at a premium, or a very cheap to produce chip they could sell for the budget crowd, but right now they have Acura production costs coupled with Kia per-unit revenues: bad times.

Re:Old issue, really

[CajunArson]

OK html time: HERE

Re:Old issue, really

[nonsequitor]

The Q6600's are faster and more efficient because Intel has more money to throw at manufacturing. If AMD had Intel's cash they would be at 45nm already and be handing Intel their ass right now. I'm not a FanBoy, but from everything I've read, AMD's chips have been much more elegantly designed since going Dual Core, whereas Intel can just throw money at the problem, like buying the company that designed the Core 2 architecture and shrinking their fab process. Performance-wise Intel is in the lead for the moment, but once AMD is down to a 45nm etch, they will easily be back in the game since they'll be able to clock those chips way past where they currently are. I think I read in the hardware enthusiast review that the chips are capable of higher over clocking but there were some errata which killed performance when over clocked past a certain point. Once AMD gets that all ironed out, they'll have a truly amazing platform. However, I'm a little sad that their marketing department forced them to release a product which wasn't ready before Christmas, it's going to build a lot of ill will with early adopters.

Re:Old issue, really

[zsouthboy]

"The "true" quad-core line appears to be nothing more than marketing hyperbole"

No, it's not marketing.

You're not seeing the usefullness on the desktop.

HPC is another story - and it's also the place that the plain old Opteron has been holding its own, against the faster, clock per clock, Core 2 microarchitecture.

Having requests go through the FSB (which is a WTF this day and age) kills cache snooping, etc, between cores.

The "true" quad core doesn't have this problem.

Re:Old issue, really

[merreborn]

AMD would be fine if they had an expensive chip they could sell at a premium, or a very cheap to produce chip they could sell for the budget crowd, but right now they have Acura production costs coupled with Kia per-unit revenues: bad times.

AMD actually still rules the absolute low end of the market (and has for years). Semprons ($30+) and old X2s ($60+, new retail box) are dirt cheap, and it's simply not possible to get better performance per dollar.

There isn't much a $60 X2 can't do in your average desktop.

Re:Old issue, really

[nxtw]

The Q6600's are faster and more efficient because Intel has more money to throw at manufacturing.

Manufacturing is an important part of any high-tech industry. Improved manufacturing leads to lower costs and improved products. In the end, it doesn't really matter to Intel's big accounts and PC enthusiasts how they made their products better, but on more relevant measures (price, performance, efficency being the big ones.)

but from everything I've read, AMD's chips have been much more elegantly designed since going Dual Core

But who makes purchasing decisions based on which CPU has the "more elegant design" instead of something quantifiable like performance and/or efficiency?

whereas Intel can just throw money at the problem, like buying the company that designed the Core 2 architecture and shrinking their fab process.

The current Core microarchitecture can be traced back to the original P6 microarchitecture first released in 1995. It was developed in Israel, a country where Intel has had a presence for over thirty years - and where the Pentium M was developed. While technologies acquired companies may have contributed to the success of the Core microarchitecture, it's still an Intel design.

And in this case, throwing money at problems gets them solved. It means that I can throw money at products I want today.

but once AMD is down to a 45nm etch, they will easily be back in the game since they'll be able to clock those chips way past where they currently are.

If AMD's new 65nm CPUs can't compete with Intel's year-old 65nm CPUs, what makes you think AMD's 45nm CPUs will be better than Intel's 45nm CPUs (once both are generally available)? They don't even offer a decent competitor for Intel's LV and ULV dual-core mobile chips, which are 65nm.

Re:Old issue, really

[Alsee]

right now they have Acura production costs coupled with Kia per-unit revenues

You forgot Pinto.

-

Re:Old issue, really

[firesyde424]

The guys over at Anandtech were able to show that AMD had the right idea with a native quad core approach. While the core 2 might be more efficient OVERALL per clock cycle, the phenom and native quad core opteron show edhigher memory efficiencies and lower general latencies than core 2's or xeon's. While this difference only really shows in high end data applications, it does show that AMD has the better TECHNICAL solution in the long run. What AMD has missed is that in the mass consumer market, technical details rarely matter beyond pricing and speed. Most consumers only want to know which is the best deal and which is the fastest.

Having said that, the CPU market has been a tug of war between intel and amd for several years now. Go back to when the first P4's were released. People predicted doom and gloom for AMD then as well.

The intel fanboys will cry "at last!" The amd fanboys will cry "We have not yet begun to fight!" AMD will pull through. You can still find numerous models of consumer PC's with AMD processors in them. AMD still has a VERY healthy enterprise market as well where the opteron competes neck and neck with the best intel xeon's. We haven't heard that last from AMD, and I seriously doubt that we ever will.

Re:Old issue, really

[MrFlibbs]

An excellent post, but one of your details is wrong -- The P6 was not designed in Israel. That design was done in Hillsboro, Oregon. Most of the Pentium Pros sold into the marketplace were from the "P6s", a shrink of the original design, and that was done in Folsom, California.

The design team in Israel added the MMX instructions into the last P5 and then worked on the ill-fated Timna design (integrated memory controller with RDRAM interface) while the P6 was ramping. After that they began the low-power design that became the Pentium M. They also did the Core and Core2 designs. (Except for the new Penryn, which is from Folsom.)

Re:Old issue, really

[chazwuzza]

I recently upgraded my athlon64 3700+ (socket 939) to a althlon64 x2 4200+ for 60 bucks and yeah it was a big boost, apparent in every application. Also the x2's are very overclock friendly, I'm able to push mine to 2.5+ ghz from the stock 2.2 I'm not upgrading my mobo until the next gen chip situation gets sorted out.

Re:Old issue, really

[Anonymous Coward]

I'm not a FanBoy,

but you sure sound like one, because...

but from everything I've read, AMD's chips have been much more elegantly designed since going Dual Core, whereas Intel can just throw money at the problem, like buying the company that designed the Core 2 architecture and shrinking their fab process.

it seems you've been relying on AMD fanboy information sources.

The company which designed Core 2? Intel. Core 2 is a descendant of Intel's P6 microarchitecture, first realized in a shipping product as the Pentium Pro. P6 has been one of the most successful basic processor designs of all time.

Intel has never bought an outside x86 design. AMD, on the other hand, did: they bought NexGen to get the design which ended up being sold as the AMD K6 (plus, of course, the engineering team which created it). AMD's previous efforts at in-house x86 design were mostly carbon-copy clones of Intel designs, plus the K5, an original design which flopped badly.

The company with the more elegant design? Intel. Core 2 is a really good design with few weak points. The only real deficiency is that Intel chose to keep it on Intel's aging FSB, which hurts the latency and bandwidth of access to DRAM relative to AMD's products. Despite this, Core 2 has been beating said products silly at everything but pure bandwidth drag race benchmarks, and the reason why is that it's a very sophisticated and elegant CPU core.

The company which shrunk Intel's fab process? Intel.

In fact, Intel is the only remaining company which actually does its own fab research. This has nothing to do with whether Intel/AMD are good/evil, it's just a consequence of economic reality: the rising costs of R&D have left Intel as the only semiconductor company able to finance next generation fab tech R&D on its own. Everybody else is either getting out of the business (Texas Instruments would be a high profile example) or partnering to share costs.

It's also a fact that Intel typically gets to new process nodes (like 45nm) a year ahead of anybody else making high performance CPUs. Yet another fact: Intel's processes tend to outperform everybody else's (for example, AMD's 65nm process simply can't compete with Intel's 65nm, based on published performance information).

Performance-wise Intel is in the lead for the moment, but once AMD is down to a 45nm etch, they will easily be back in the game since they'll be able to clock those chips way past where they currently are.

You might think that, but you might also be wrong. The industry has been having bad performance scaling problems for the past several process nodes. It's no longer sufficient to just shrink. AMD's fastest Athlon X2 is actually made on their 90nm process, not their 65nm process. They do have a 65nm version, but it has never clocked as high as the 90nm version (I think the current figures are 2.6 GHz on 65nm and 3.2 GHz on 90nm).

Intel's 45nm process solves one of the major scaling problems by introducing metal gates with a Hi-K gate dielectric material; this allows them to dramatically reduce leakage current, the industry's bane since 130nm, and also allows use of a thicker dielectric, making manufacturing significantly easier. AMD's initial 45nm process will have neither technology. By the time AMD has a 45nm process with comparable technology, Intel should be debuting 32nm. (And if historical trends remain true, AMD's 45nm process will never match Intel's 45nm anyways.)

Depends ...

[Pinky's Brain]

As long as the diff doesn't contain any of the original code and the patch is distributed in isolation then there is no conflict with the GPL ... if RH distributes a binary kernel though then they are in violation of the GPL, this would make RH liable but I don't know whether your rights under the GPL or the prohibitions under the NDA take precedence for the recipient though.

Au contraire!

[Spy der Mann]

It just means they're starting to make Intel's mistakes! They're on-par now! :D

Re:What?

[Anonymous Coward]

And no 'kdawson' crack either. Disappointing.

Let's not forget..

[AcidPenguin9873]

that Intel's Core 2 also had a problem with the TLB when first released, although that problem manifested itself as data corruption instead of a lockup. Here are the two articles from The Inquirer about it - the second one especially. And note that this document was released after Intel had shipped the buggy Core 2's.

However, Intel was able to fix it without incurring a large performance loss. It's a shame for AMD that they weren't able to do the same.

Re:Let's not forget..

[Tablizer]

However, Intel was able to fix [TLB bug] without incurring a large performance loss. It's a shame for AMD that they weren't able to do the same.

It could just be the luck of the draw how easy it is to work around. I don't think one incident is a sufficient sample size to judge AMD compared to Intel.

They did

[DreadSpoon]

AMD admitted there were errors in the early Phenom CPUs back before launch. They even put it in their presentations in the press conferences and such. They also said before launch that they were going to include the proper fix in the revised core used in the higher end Phenom, hence the delay.

Re:They did

[Wavicle]

AMD said there was a bug that only affected the 2.4GHz Phenom. Read this and note where they say:

AMD already issued a fix to all of its motherboard/system partners, so if you already own a 790FX motherboard or plan to buy a Phenom system, make sure to update the BIOS. 9500 (2.2 GHz) and 9600 (2.3 GHz) parts are unaffected by the errata.

Now we learn that the slower parts were affected as well.

Re:They did

[Anonymous Coward]

We did not learn that at all. The article doesnt go out and say it, and it certainly doesnt cite sources that say that.

Re:They did

[bakes]

AMD admitted there were errors in the early Phenom CPUs back before launch. They also said that the performance of the new chips would be 'phenominimal'.

What?

[Poromenos1]

QMUNAD, WHEA (Quit Making Up New Acronyms Damnit, We Have Enough Already)!

Re:What?

[Anonymous Coward]

And an unusual amount of goatse crap. Can we ban their IP's or something

What's more disturbing, blah, blah ,blah

[Hanging By A Thread]

Everyone makes crap these days and releases it anyway. It has to kill or injure people and be recalled before it's truely "disturbing"....

Relax everything's fine!

Borat says "I buy Pentium Core Duo, neighbor can not afford he buys AMD Phenom everyone knows it's for girls, Great success!".

[offtopic] Re:"because", not "despite"

[benji fr]

aaahhh !

Someone, here, now, on /., who not only RTFA, but also RTFUA ! ...

Why all the secrecy?

[jonwil]

What is so bad about a company like AMD coming right out and saying "processor model x, clock speed y, stepping z has bug abc and this is the workaround for it". Assuming BIOS vendors and others are going to be deploying the fix anyway, how does it hurt AMD if everyone knows of the fix?

Re:Why all the secrecy?

[Anonymous Coward]

Well if they knew about it prior to the release there are only a couple of things to do, 1) depending on when they knew they delay the other option 2) is that it's too late to delay so the have a problem in that they've burned a lot of money and made a bunch of broken chips. So what do you do? The chips aren't always broken like you might hope, it's a subtle thing, they mostly work. So you sell them, most are going to go to Taiwanese companies anyways. Then before the customers start to get them en masse, you sort of announce the screw up on the hush hush. You've got the board vendors in a situation where you can get them to eat the costs until you fix it and they still need to buy chips form you in the future. Likewise, if you can keep it quiet enough The Street doesn't pay too much attention, they might even boost you stock because there is a lot of demand for these parts that you simply cannot get.

As for the ones that have actually reached customers, it is a more messy problem at that point. Better to not publicize the whole thing and hope they don't notice than to do anything about it. You have any idea how many BIOSes aren't patched out there and because of that how many parts are working with known errors? Do you have any idea how much money Intel burned fixing floating point units that the majority of their customers never actually used?

Going public with this in a big way only burns AMD. They already have a big bowl of suck to eat. Their market is so insanely competitive, they need a 3 and 4 core part just to stay in the game and stop the bleeding. Hopefully the bulldozer is good and can win some hearts back.

 

Re:Why all the secrecy?

[Anonymous Coward]

What is so bad about a company like AMD coming right out and saying "processor model x, clock speed y, stepping z has bug abc and this is the workaround for it". Assuming BIOS vendors and others are going to be deploying the fix anyway, how does it hurt AMD if everyone knows of the fix? Try telling that to the Marketing people. But duck on your way out...

Re:Why all the secrecy?

[Quikah]

The "fix" reduces performance by 10-20% in certain workloads. That is pretty bad thing to be coming right out and saying.

Good thing they bought ATI

[Chris Snook]

At least in the graphics world, "faster and usually correct" is acceptable.

Re:Good thing they bought ATI

[n dot l]

Nah. Not "usually". GPUs are correct...for a given value of correct, that is. I mean, have you seen the massive error bars the DX/GL specs attach to the meaning of "correct" or "conformant"? Kind of hard to miss that mark when your target is the size of a large barn and you get to shoot from a point of your choosing - including the inside.

I swear, an implementation based on a five year old with a red, green, and blue crayon would probably satisfy a good portion of the GL spec...

</hyperbole>

Re:AMD Is Doomed Unless...

[Anonymous Coward]

Hey! This is slashdot, not your personal advertising space for YACB (yet another crappy blog).

Oh, wait a minute...

Re:AMD Is Doomed Unless...

[Anonymous Coward]

Hey man, fuck you and your limpdick blog. That is all.

Why AMD Released Faulty CPUs: Possible Theory

[Ma3oxuct]

If you look at AMD's financial statements (http://sec.gov/Archives/edgar/data/2488/000119312507238299/d10q.htm#tx48043_5) for the last quarter, it has been loosing a lot of cash. This leads me to believe that they released faulty CPUs, right before the holidays, in order to get some cash in the short term.

The idea was to gain some cash to sustain operations until a faultless (i.e. no major faults) CPU can be released. Those that bought faulty CPUs will get their CPUs replaced as soon as faultless CPUs are completed. In some sense you can look at AMD's action as taking out a long term loan.

A counter argument to my theory can be that AMD would not risk its reputation to take out a "cash loan" in such a manner. However, the risk of losing reputation is justified if we consider another major factor at play: the holidays. It is less likely that AMD would gain the same (or even close to the same) cash flows if they would have released the CPUs after the holidays.

AMD now has some cash and is able to breath a little bit. When it releases fixed CPUs it will be able to continue where it left off.

Re:Why AMD Released Faulty CPUs: Possible Theory

[Anonymous Coward]

I just looked at AMDs financial statements for last quarter, and despite your claim, there has been no meaningful change in the balance of AMDs current assets (by which I mean, AMD has plenty of liquidity to maintain operations without 'cashing' out its reputation); therefore, your supposition is wrong.

There are significant cash flows at AMD, led foremost by its operating losses, but it's pretty clear to me that you don't understand financial statements enough to provide useful insight into this company. Regardless, on balance, AMD appears able to easily offset (finance) its operational losses with borrowing. This is obvious from their financial statements. Take a class or something.

Re:Why AMD Released Faulty CPUs: Possible Theory

[cnettel]

A big recall program is more expensive than just pissing customers off and taking additional costs for shipping and handling. The OEMs, distributors and retailers are the ones that will get really pissed.

Re:Why AMD Released Faulty CPUs: Possible Theory

[endeavour31]

Exactly right! Putting out a shitty product in an attempt to keep up with your bigger and more established competitor (which keeps pulling ahead anyways) is the perfect way to get Wall Street analysts drooling over your company which will have a wonderful effect on your market cap. AMD cannot affor too many blunders or they will be left well behind. All that work to establish themselves as an alternative to Intel can and will evaporate if they start shipping crap in servers to major business.

Re:AMD Is Doomed Unless...

[Anonymous Coward]

Whatever. Start off whining about crappy concurrency, then start mumbling about "easy software composition". How are they related? Are you ADD?

A [expletive] Day in the [expletive] Life

[florescent_beige]

[engineer] gets [error] during [random load tests]

[engineer]: Hmm

[engineer] runs [random load test] 10 more times gets 10 more [errors]

[engineer] calls [manager] "Um, I have something to show you..."

[manager]: [expletive]

[manager] calls [vp]: "We may have discovered an issue..."

[vp]: [expletive expletive expletive]

[vp] calls Hector Ruiz: "Hector, remember when you said the next person that called with bad news would be wearing your guitar around his neck?

Hector: [?]

[vp]: "Well," [explains]

Hector: [expletive expletive expletive expletive expletive expletive expletive]

[vp]: "We have maybe a BIOS fix."

Hector: [expletive expletive expletive expletive expletive]

[vp]: "Ok we'll just go ahead and do that then..."

Hector: [expletive]

[vp]: "Ok then I'll see you later."

Hector: [expletive expletive expletive expletive] *click* [expletive]

Re:A [expletive] Day in the [expletive] Life

[clampolo]

What makes this funny is that it is probably how it really happened.

Vista on Phenom

[steveoc]

Just wondering - if a new customer buys a quad core phenom, just to run some super elite gamerz rig running Vista .... does it really matter if the CPU is going to generate bad results, or crash at some point ? Its not like the operating system and other code running on the buggy processor isnt equally likely to break something as well.

To use a car analogy ... if a blind, retarded midget (Vista operating system), gets into a car with a broken crankshaft and square wheels (busted phenom CPU), then is anyone going to lose any sleep ?

Re:Vista on Phenom

[Tablizer]

To use a car analogy ... if a blind, retarded midget (Vista operating system), gets into a car with a broken crankshaft and square wheels (busted phenom CPU), then is anyone going to lose any sleep ?

Yeah, the neighbors will because square wheels make a lot of noise.

Re:Vista on Phenom

[nxtw]

Just wondering - if a new customer buys a quad core phenom, just to run some super elite gamerz rig running Vista .... does it really matter if the CPU is going to generate bad results, or crash at some point ? Its not like the operating system and other code running on the buggy processor isnt equally likely to break something as well.

Who wants to buy an unsafe / defective product? Even if the bug is unlikely to occur, I would not want to purchase a product with a known performance-impacting (fixed) or crash-causing (not fixed) CPU unless it was priced competitively to make up for the disadvantage. And right now, the AMD CPUs are simply not priced competitively.

It doesn't really matter how buggy you percieve the software running on "super elite gamerz rig"s to be - whether the software is extremely reliable or extremely buggy, running it on buggy hardware will only increase the chances of failure.

Re:Vista on Phenom

[Anonymous Coward]

Oh come now, Vista is plenty stable. On my laptop, which goes into and comes out of hibernate and standby all day, Vista has been running just fine without reboot for just about one solid month now. The next reboot I expect will be to load up the release candidate of the upcoming service pack.

These CPUs on the other hand... they worry me a bit.

Perfect Linux CPUs

[evilviper]

Ironically, these may turn into the CPUs dejour for Linux users...

The performance hit is probably 10% when patching the microcode which should mean steep price mark-downs on this generation of CPUs. But it's only a 1% performance hit when patching the (Linux) kernel.

So why doesn't every OEM that sells Linux servers and desktops just buy up all of AMD's supplies of defective chips at a big discount, and pass the savings along? I'd buy a couple.

Re:Perfect Linux CPUs

[steveoc]

Yep, perfect.

Cant wait to see the big price drop on the old stock - and get myself a carton load of quaddies.

Imagine a beowulf cluster of .. severely marked down, dirt cheap quad cores ? :)

Re:Perfect Linux CPUs

[Anonymous Coward]

im not a linux using OEM, or even responsible for a small linux-using shop, just my own two/three linux systems, so take that as you want, but i still wouldnt be interested, here is why:

- the phenom, even assuming a IPC parity with intels kentsfield, would need more then a 10% price drop to be price/performance competitive, based on my local prices
- with the current patch, you are limited to a specific 64 bit RH version, and i dont feel like switching distros for a hypothetically cheaper cpu
- i own a perfectly good intel system, so a phenom would also cost me a new mobo, kentsfield wouldnt (although if i were to go on an upgrade tour, my mobo would also be bumped, for some intel p35 loving)

the only way these things would become close to interesting would be if prices dropped at the very least 20% (and that is with the current kentsfields, yorkfield has the opportunity to oncer again ruin whats left of AMDs party), the kernel patch gets integrated in 32 and 64 bit linux, and just about every single distro out there (or at least the large mainstream ones, like ubuntu)

and even then, ever since i got a full time job i cant find myself caring to much about spending 10% more on something if that would mean not having to pfaff about with patches and stuff

Re:Perfect Linux CPUs

[Anonymous Coward]

In what way is that ironic? I'm not sure you know the definition of that word.

Re:Bummer - BUT I'M BUYING

[flatulus]

Just bought my MSI AM2+ mobo and 4Gig DDR2. Next week I buy my own broke-ass Phenom - happily!

Why?

Because I still have the choice of buying a broke-ass AMD processor instead of an Intel. If AMD folds, Intel might just give every employee a new Porsche just for kicks. Because with what they will be able to charge (in a monopoly business), the Porsches would be a rounding error.

Remember that Free Enterprise is the ultimate democracy. Vote with your dollars!

No, but it looks bad-Says Netcraft.

[Anonymous Coward]

"It might not be AMD's doom, but they're really not that many big screwups away."

They're trying to pull a Commodore. Anyway I think my next processor will be Intel. Combine that with an Intel board and it should be one steady machine.

Re:AMD Is Doomed Unless...

[pem]

I read some of your links, and, while I will admit that there are certainly problems with how software is built, I don't think you have a silver bullet.

If pictures are so good, how come a lot of hardware is written in Verilog/VHDL instead of schematics, when both are available?

If fine-grained parallelism is so error-free, how come chip companies spend a fortune verifying and validating both their schematics and their HDL before they tape out?

BTW, I make my living by writing software, writing Verilog, and drawing schematics.

FWIW, I prefer Python to Verilog, and Verilog to schematics. In fact, I check my schematic netlists with Python scripts to make sure there are no errors.

When it's important to get it right, I find text much preferable to schematics -- it can be easily diffed and version controlled.

Re:Bummer - BUT I'M BUYING

[eechuah]

That's psycho. Assuming a 50k price for Porsche's and Intel's current employee count of 80k, that's a 4 billion dollar investment right there, or half a year of profit. You really think that would be a rounding error?? I can see that now... umm... board of directors, our profits dropped by 50% this year, but employee morale is through the roof! Yeah, right.

Do your math next time.

Oh please knock it off

[Sycraft-fu]

The whole "Intel is t3h hot!!!" thing has gotten old. Yes, P4s were very inefficient chips. Not so with their modern lineup. Core processors are quite efficient power wise for their given level of performance. They also scale way down, there are Core Solos with only a 3 watt TDP spec. Shouting about the Core lineup using a lot of power when it is AMD's processors that you use as the alternative makes little sense.

It is just silly to dredge up old crap and keep using it. It actually weakens any point you try to make because it makes you look as though you don't know what you are talking about. Name calling is bad enough but when it is outdated name calling it is really silly.

By the way, I wouldn't crow too much about price either. I can't find many Phenoms available but the 2.2GHz one Newegg sells is $245. A 2.4GHz Core 2 Quad is $260. Even assuming the Phenom is faster (which would be real questionable especially in light of the patch) that makes it 94% of the price, not 60%. Not a significant cost savings.

It also should be noted

[Sycraft-fu]

That the vast majority of errata are minor things. They either don't matter much or don't affect almost anything or both. It is the kind of stuff that if discovered in a piece of software would probably be left in if it was more than a few lines of code to fix. However, because of the nature of a CPU, they just make sure to document all of it so people know. Most of it never gets fixed, precisely because it isn't a big deal.

Bigger ones generally are fixed in microcode, and sometimes even lesser ones. However something things big, well it may be as you say and take an actual hardware fix.

I also think you may be right about them being not so willing to replace it. For one, there just aren't that many sold. The Pentium was marketed at consumer machines, this is more high end. So it was a bigger flap for Intel. However the other thing is AMD is hurting badly right now. They have lost a lot of money recently and are not going to be in the mood for losing more. While it may well be a case of penny wise pound foolish to refuse replacement, executives make those kind of decisions all the time, especially when there is heavy pressure to cut costs.

Re:Redhat's NDA for patch?

[vranash]

I have one character array and a float for you: 'gcc-' '2.96'

Enough said.

Spirit of the license?

[Anonymous Coward]

Doesn't this constitute as a an attempt to exploit a loop-hole within the license? Doesn't it go against the spirit of the license which aims to ensure that modifications to GPL'ed code remain GPL'ed? Any lawyers out there that can comment on this?

Re:Spirit of the license?

[nautsch]

Now that you say it. Thats exactly how i see it.

Re:AMD Is Doomed Unless...

[Anonymous Coward]

I'm reading your articles, and you're a complete crackpot.

The true model of paralelism is double buffering on a console game? Uhhh.... Right... I think what you're getting at here is a non-blocking algorithm. There isn't any "lock" since they're reading and writing separate buffers. There's lots of non-blocking algorithm research out there, and other alternatives to locks. I encourage you to read up on it, a lot of it is quite interesting. Transactional memory is another hot topic; have you read up on that?

In other words: don't trash academia when academia has already come up with very good solutions for the problems you describe. You're showing blatant ignorance of what academia has to offer.

Your rejection of terms like "thread" and "algorithm" is even more ludicrous.

Re:AMD Is Doomed Unless...

[Anonymous Coward]

I read about your COSA thing. It looks like you reinvented LabView's language G...and not particularly well. Needless to say, there are many problems with it. If it was really that good, wouldn't it have caught on sometime in the past 20 years? Here are a few of the many reasons it sucks:

1. It does NOT eliminate programmers. Sure, it doesn't require typing, but that just means it eliminates typists (and it doesn't really do that because you still have to type in comments). Anybody can drag and drop a component, but it takes a programmer to figure out which ones to use and how to connect the components together.

2. It's a bitch to debug because you have potentially thousands of things all running in parallel. You can't easily single-step. You can't easily comment out a block of code you think is causing problems. You can't just start sticking Print statements everywhere.

3. Cutting and pasting code is a mess! When you have to insert some code into the middle of your algorithm, you can't just insert a new line, you have to insert rows and columns of pixels. If your components aren't all on a grid, that may not be easy.

4. Printing out your program requires cutting and pasting because it's 2-dimensional. It's hard to visually understand things like switch constructs and sequential operations, particularly when they're nested, because that makes it 3-dimensional.

5. Non-text files are difficult to deal with. You can't tell your friend to look at line XXX to help you figure out why you have a bug. You can't diff the code, meaning it's not really possible to version control properly. Have you ever posted a small code snippet to have somebody copy it, get it working, and post a reply with the fixed code? It's not possible with these programs.

6. It gives new meaning to the term "spaghetti code" because data flow is indicated by lines, and complex data flows look like a plate of spaghetti. In a traditional programming language, you can compute some value (say, average of Foos) and assign it to a variable (say, avgFoo). You can then use that value 100 different times in your function by typing 'avgFoo' and every time you see it you know that it's the average of Foos. With this graphical method, you just have some icon with a line coming out of it with some comment hopefully indicating somewhere that the line is the average of Foos. Then you have 100 lines distributing this value all over the place in your diagram, all of them looking just like any other line in the diagram (in the case of G, every line of the same data type looks the same). Can you make sense of this program snippet?

Unfortunately, G is not the only visual programming language I've ever had to use. In fact, the company I currently work for has such a method of programming its system. It was designed because the users apparently had trouble using the text-based language. I think the engineer who designed the graphical system is the only one in the company who still uses it. Keep in mind that the text-based language is still implicitly parallel, it just doesn't have all of the problems I mentioned above (although it's not much easier to debug).

For those who don't know what this sort of programming looks like, see this for a good example of how it takes a 2MP bitmap to describe a page of code.

dom

Re: Wait for Rev B3

[Lobachevsky]

The Phenom Rev B3 release (March '08) is supposed to fix the TLB issue in hardware. Until then, there's a microcode update (via a BIOS patch) that fixes stability issues (at the cost of 10-20% L3 performance).

+1 Punny [nt]

[Anonymous Coward]

Horrible news...

[GiMP]

I just got my Barcelona system running last month, paid very good money for what was supposed to be a revolutionary platform, and for what? Sub-par performance? Really not cool AMD, really not cool.

I might hope that the RH patch hits mainstream Linux, but I'm not sure how that affects Xen...

On the Desktop maybe.

[LWATCDR]

The new quad cores from AMD do beat Intel's once you get past two sockets. Even with "just" eight cores the Intel systems start to get memory constrained.
The problem is most people don't need more than four cores these days. But if you need a really big server AMD does still seem to be a better solution than Intel.
I really want to see a dual-core Phenom! Most desktops still don't need a quad core. The Phenom core has some real improvments over the old cores and it should be cheap and very low power.
Today on the desktop the quad-core just isn't that useful. So where are the next generation dual-cores?

Re:Bummer - BUT I'M BUYING

[flatulus]

I cannot believe you bothered with that reply!

Call me stubborn...

[kitgerrits]

But I still bought it (the 2.3GHz version, though).

I know it's not the fastest on the market and I know it has a bad rep,
    but I'm an AMD guy and I intend to stick with them as long as I can.

I have a compatible (CrossFire) motherboard and the CPU will cost me about $250.
If I want to go to Intel, I would have to spend at least -twice- that much,
    just for the MoBo and CPU (Never mind new cooler, etc).

Even if it might freak out under heavy load, It won't be that much of a problem, because it's only a game machine.
(I realize that means it will often be under a heavy load, but I can stand to lose the data on there, I have my Ghost Backup)
I've had about a half dozen 'freezes' in the past month and I don't think this CPU will make that much of a difference.

Just my 2c

Re:AMD Is Doomed Unless...

[clampolo]

I'm on the VHDL side and I agree about schematics being bad. It takes longer to draw them and they are harder to read. To trace signals, you have to highlight the wire and then go on a huge search over the schematic to find it. The whole time you are zooming and unzooming. With a text-based language you can just do a simple search and find the information instantly. Another thing is how hard it is to modify a schematic. In VHDL I can easily insert an inverter. In a schematic, you have to spend several minutes tearing up wiring and changing stuff around.

Re:AMD Is Doomed Unless...

[Anonymous Coward]

I think the first thing you need to do is remove the incredibly arrogant tone from your blog, especially seeing as a very large portion of it is really quite questionable. It makes you seem like an absolute raving lunatic.

not likely

[tacokill]

No, AMD is not trying to get a "cash advance" from it's customers.

If AMD, a Fortune 500 company, needs cash....they go to the debt markets like everyone else. It's not like this is the local loan shark here. It's Goldman Sachs. It's Citibank. It's Lehman Brothers. And trust me, they will be more than happy to help AMD find short-term cash (for a fee, of course). What do you think investment banking is?

There is no conspiracy here. Please move along.

It's what every geek fears...

[Black.Shuck]

...erratum plaguing their boxen.

Re:AMD Is Doomed Unless...

[MOBE2001]

I think the first thing you need to do is remove the incredibly arrogant tone from your blog, especially seeing as a very large portion of it is really quite questionable. It makes you seem like an absolute raving lunatic.

One of the things I noticed about a lot of computer geeks is their total lack of a sense of humor. It smacks of autism and anal retentiveness. ahahaha...

Elsie Wahlig on erratum 298

[jharel]

AMD fellow Elsie Wahlig posted the following on a Linux mailing list:

AMD Family 10h revision B2 processors suffer from an issue in the processor TLB known as erratum 298. Erratum 298 is documented in a forthcoming update to the Revision Guide for AMD Family 10h Processors (PID 41322). The workaround in the Revision Guide document is intended to be applied by BIOS. The BIOS workaround has performance implications which can be avoided by having the OS directly workaround the issue. A Linux 64-bit patch was developed for 2.6.23.8 by AMD's OSRC team and will be posted to this list by Joerg Roedel. The patch is for demonstration purposes and is NOT being recommended to be applied upstream.

Erratum 298 will be described as follows: "The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."

The L2 Eviction Linux kernel performance patch re-enables the registers set for the BIOS workaround described in the Revision Guide document. It then prevents the processor from performing the operation that can trigger erratum 298. The patch works by emulating the Accessed and Dirty bits.

The basis for the kernel patch solution depends on the root cause of the L2 eviction problem. The only exposure for the problem is when the TLB needs to set an A or D bit in a page table entry. If the TLB never needs to set an A or D bit, the bug cannot occur. By emulating the A and D bits with the help of the Present and Writable bits, the patch will ensure the real A and D bits are always preset. It works by forcing a page fault when the first access is made to a page with the emulated A bit not set, and when the first write access is made to a writable page with the emulated D bit not set. Emulated A and D bits are stored in bits generally available to the OS in the page table entry.

Elsie Wahlig

Re:AMD Is Doomed Unless...

[Ginger Unicorn]

are you saying the whole thing is joke?