From a technical standpoint, while McKinley is not the joke that was Merced, it isn't taking a clear
lead in the 64-bit race (as we all thought it would)

Speak for yourself. For years I expected the performance crown at 180 nm would be a
tossup between McKinley and Alpha EV7 with the EV7 most likely to come out ahead.
The EV7 is ahead on peak SPEC but McKinley is ahead on base SPEC. BTW, most
independent industry observers like MDR evaluated McKinley performance as better
than expected.

It is very expensive to produce and does not give the generational advantage Intel promised with
EPIC

Compared to what? Desktop uPs? It certainly isn't compared to its peers.

The McKinley, EV7, and POWER4 all within 6% of each other in die size. If you consider
differences in process, packaging, and the fraction of the die protected by redundancy it
seems inescapable that McKinley is by far the cheapest of these three 180 nm bleeding
edge server processors to produce.

On Itanium, two strikes.

Why do you say McKinley is a strike? It is the fastest performing 180 nm aluminum processor
in history on SPEC CPU 2k and beats all 180 nm processors, including those with the advantage
of copper interconnect, in SPECfp_base2k. And it runs rings around its publically stated primary
market target, Sun's US-III based family of workstations and servers. Most important of all, it
restored the credibility of Intel/HP/EPIC. Merced was an industry joke but no one laughed at
McKinley, least of all competitors.

If Intel doesn't get it right with the upcoming process shrink then Itanium is out.

This is the computer industry, not baseball. Intel has money to push IPF for many more years
and MS certainly showed us that money can buy as many chances as you want. Most important
of all, Intel's IPF partners seem firmly committed as ever to bringing highly competitive IPF based
products to market. I think Madison will be a very compelling product . But regardless, this idea
that it is Intel's final chance is nonsense.

Very impressive work. eom

But Intel is going after IBM's jugular with the Itanium family, so it's not surprising
that IBM's happy to drop some big rocks on the Itanium effort.

That isn't what I hear from a fortune 50 IT type who has seen IBM's IPF product
line plans for 2003 and kicked a few tires so to speak. I think it is more likely that
the IBM x455 family will drop a big rock on AMD enthusiast's fantasy that IBM is
their ideological bosum buddy in promoting Opteron. BTW, the inquirer has it very
wrong when they pegged the 455 as simply a 450 with Madison installed. HP and
SGI had better look out too. ;^)

PC Week, Jan 22, 1996 reports a slip of the P7 (renamed to Merced) from 1997 to 1998.

More sleazy misrepresentation. The original P7, due in 1997, was a 64 bit x86. The code name
was transferred to the Merced when Intel decided to ally with HP. The first EPIC processor was
never expected earlier than 1998. It shipped in 2001, that's a three year slip.

PC Week, Jan 19, 1993 had an article that says that Intel would deliver a 64-bit chip, the P7, in
1995, with the first systems shipping in 1996.

You know that has nothing to do at all with EPIC. Intel's alliance with HP didn't start until the
next year. Did you think we wouldn't see through this misrepresentation? Its like the tricked
out link to SPECmine you gave a while back that hid HP and SGI entries. Have you no shame
at all?

I don't have to diferientiate software/hardware, so I didn't say it just right, so what. Its trivial.

Thanks for condensing all of what it means to be a hard core AMD enthusiast
down to two sentences on a single line. I think this just about says it all.

I am not tech, but I doubt corp enterprise wants a Micro$haft solution

I have my doubts too but that's not the issue. The issue is MS wants to be able to offer
an enterprise solution and that means IPF. This is a prestige thing for Redmond and
that alone will assure full support for IPF from Bill on down. Support for AMD64, at best,
is a useful hedge for Redmond in its complex relationship with Intel. That's a role that
has previously been filled by MIPS and later by Alpha. Fat lot of good it did for those
guys.

And what is intel doing now, reacting to the 86-32 compatibility of A64 by putting more
hardware into IA64 for 86-32 fibulation, another knee jerk reaction, that ought ta help alot.

Wow you really rush in where angels fear to tread. FYI the x86 compatibility box in the
McKinley core was a complete redesign over Merced's and is much simpler and more
compact even though it performs significantly better. And looking beyond the McKinley
core, Intel has expressed interest in an entirely software based x86 compatibility scheme
for future IPF processors. Surely an AMD partisan of all people appreciates the wisdom
of moving towards a proven DEC/Alpha-related approach to solving a tough problem.

Your claim that Intel is "putting more hardware in IA64 for 86-32 fibulation" is a complete
and utter fabrication. But considering the author, that is not entirely unexpected.

Last time I told you that the flash numbers you presented to gauge market share gains/losses in Q1 were outdated and the conclusions you arrived at were wrong because of that, you also ignored it the first time around. Well, it turned out I was right about it. I just wanted to see if you´re doing that intentionally or not.

Hold on there, I didn't "arrive at any conclusions" at all about flash. That is a clear cut misrepresentation
and I resent it. I simply presented the data I found in the issue of BW that arrived that very day because I
thought it was timely, relevent, and of interest to this forum. I did not omit or change anything about it and
freely said where it came from. Nor did I make any claims about it being better or worse, newer or older
than anyone else's data. Indeed, any experienced observer of the industry knows that data from two
different market research firms for the same period and market segment is often contradictory.

I am under no obligation to answer anyone's reply to a post of mine. If you feel you are being ignored
than perhaps you should first question whether your reply held any value above rhetorical. I generally
try to reply to any question or comment made in good faith to which I can provide a worthwhile answer.
Sometimes I fall behind the pace of posts or skip entire threads that turn south so I probably miss the
odd post directed to me that merited a reply so don't automatically take offense.

Re: Do you wear hip waders when you do this or do you just not have a lot of friends living down wind?

What's you problem? I posted my impressions of my new PC and you have a meltdown.

Meltdown? I was complimenting you are your adroit change of subject from a major
disappointment for AMD to a completely irrelevent praise for Opteron based on a
subjective and unquantified attribute. When the going gets tough you change the
subject as discretely and quickly as possible. Never so quickly as you when are
caught in a lie or misrepresentation.

I think I know what's bothering you.

Intel's 64-bit chip is 4-5 years behind plan ... [yada yada yada]

More lies. The first IPF processor was 3 years late to market. The second was on
schedule, and the third one is due in a little over a week. It has a production 64 bit
version of Windows waiting for it. In very stark contrast the 130 nm generation of
Hammer might very well be superceded before there is even a production version of
Windows native to AMD64. MS isn't renown for meeting schedules and Bill knows
on which side his bread is buttered. More importantly, Bill knows that IPF will take
him where AMD64 never will, where he wants to go more desperately than anything
else, the raised floor holy of holies, corporate enterprise computing. But that's ok,
you can always change the subject and tell us how great Opteron runs Doom III. :-P

The point about inventory reduction was taken but without any quantification of its
significance I couldn't incorporate it into my back-of-envelope cost estimate for the
1 MB A64. But now that you have shamed me into the effort to acknowledge your
objection I will say that your comment that inventory reduction will become a more
important effect over time makes no sense at all. How can "inventory reduction" be
an ongoing effect?

And also why would inventory reduction necessarily reduce my cost estimate for
Athlon, and by extrapolation, A64? It would tend to lower both ASP *and* margin.
The breakdown of total cost between direct and indirect costs would change as
well.

Re: And what will Microsoft have for the launch of the Athlon64 in September

Windows XP PRO is extraordinarily responsive on Opteron. I'm not sure what makes this so, but it "feels" faster. Possibly it's because Windows does a lot of status checking periodically, particularly
before switching focus applications or starting new ones, and the low latency memory controller lets it cycle through the open processes, network connection daemons, etc. more quickly.

It feels faster? ROFL, that's the last refuge of scoundrels and Mac fanatics. The real
news is that there is no 64 bit Windows support for A64's launch. Period. Maybe Bill
wasn't all that happy with JSIII's back-handed testimony on his behalf after all. :-P

I got to say, no one shovels it better than you Dan3. Do you wear hip waders when
you do this or do you just not have a lot of friends living down wind?

"The big loser in the latest rankings is Sun Microsystems Inc. In November, Sun had 88 machines on the list, but that number shrunk to just 9 on the latest list, which means that Sun's
ranking as a supplier of computers on the list has dropped from third to tenth place."

No kidding.

Not to worry though, Scooter sayz UltraSPARC-V will save the day in 2005, err, 2006, oops,
2007, umm whenever.

In the mean time maybe Sun should try to sell big clusters made from their new Xeon
boxes to keep a toehold on the list.

There are now two excellent 64 bit server chips available on the open market. Either
one would be a huge step ahead for Sun from the oh-so-tired USIII core based line.
Sun likes to brag about the size of their uP development team and the resources at
their disposal. I wonder how long until the cognitive dissonance Sun shareholders
seem to be gripped by wears off and they start to question the return on this expensive
and poorly functioning effort.

What the heck do you expect? The man in question *has* no message. He
comes here to dish out ad-homs and can't expect anything but derision
in return. OTOH Elmer and I are always happy to talk shop. Some people
don't like the facts, opinions, and speculation we present but are unable
to counter them in a coherent, cogent and effective manner and in their
frustation start to act out. They're the problem, not our refusal to suffer
fools gladly.

Perhaps the old saying better to keep one's mouth shut and be thought a fool
than speak freely and confirm it applies in this case. The most successful
poseurs understand this implicitly. The rare time he does say anything vaguely
technical he handles the technical terms awkwardly and self-consciously.

Well apparrently 1500 Itanium2s sold in a single system!

Stop lying. Everyone knows Intel has to *give* them away, unlike Opterons
which sell like hotcakes through major OEMs.

That's why Intel continuously loses money while AMD is profitable.

Apparently not enough.

Well....if the Chipguy says 20%, who am I to disagree?? I mean.... he's the Chipguy for God sakes.

I never stated any absolute yield estimate for any chip. My analysis was
based on AMD's own ASP and margin numbers and looking at factors
that affect relative costs between Athlon and A64.

Is English not your native language? I thought my explanation was quite
clear.

From this you conclude the production cost of an A64 1MB will be at least $100. I think your methodology is
just as flawed as EP's

I said that based on the average total cost of $47 for Athlon, that for a wide range of breakdown
of average total cost into direct and indirect cost the A64 1 MB's total cost is likely at least $100.
IMO the direct variable manufacturing cost of A64 1 MB would be 3-4 times higher than for Athlon
256 KB. Obviously if the $47 for Athlon breaks down to $5 for each working tested chip and $42
of engineering, sales, corporate overhead 3x higher direct cost gives an A64 cost of $57 if you
assume the same indirect overhead per chip. A more likely Athlon breakdown of $25 for the chip
and $22 overhead and 4x higher direct cost gives an A64 cost of $122. In the later case AMD
would need to achieve $156 ASP for A64 1MB to keep their lackluster 22% margin from sinking.

How about predicting Intel's production costs the same way? Last I heard was Intel's ASP's were
traditionally north of $200 (though they may now be as low as $150) in a heavily P4 weighted
environment. At a margin of 50%, that would indicate it costs Intel about $100 to $133 to produce
their P4's.

Better check your understanding of margin, your math doesn't make sense.

For Intel its more like $150 ASP and 52% margin last I heard. That means the average total cost
is $72. Given Intel's huge spending on R&D and marketing it is likely that indirect costs dominate
the direct cost so each P4 probably costs less than half of the $72 figure to make.

So... you believe (at least initially) it will cost AMD at least $100 to produce A64.
Please enlighten the thread with a max yield (??%) which corresponds to your at least $100 cost assumption.

I am not going to engage in a guessing game about yield when the issue at hand is cost. We
can completely bypass the question of absolute value of yields by simply looking at the cost
numbers AMD provides investors. Last I heard they claim $60 ASP and 22% margin on
Athlon. That tells us the sum of direct and indirect costs is about $47 for a product mix that
is very heavy with 256 KB Athlon (~85 mm2). It seems inconceivable that the 1 MB A64 isn't
more than twice as large as the average Athlon in the period reported. Factor in higher raw
and processed wafer cost, higher scrappage, lower device yield, and higher packaging and
test costs for A64 and it is easy to see for a wide range of direct vs indirect cost breakdown
for Athlon leads to the conclusion that it would cost AMD at least $100 to produce a 1 MB A64,
perhaps much more.

Athlon 64 Roadmap

http://www.xbitlabs.com/news/cpu/display/20030619091246.html

Not entirely sure about the credibility of the info, but here it is.

I think it is inevitable that the desktop version of K8 will have to go to a 128 bit wide
memory interface to keep up. The question is then how will it affect AMD's pricing
segmentation/product positioning strategy based on Opteron vs A64.

There isn't as far as I know a way to run 32 bit software on IA64 with sensible performance,
so pointer-heavy integer apps just have to live with the bloat.

You can compile natively for IPF with 32 bit pointers if you want. They would be loaded
from memory using 32 bit loads and zero extended to the 64 bit register width and thus
access the first 4 GB of the native logical address space. This is very similar to how it
is done on Alpha, an ISA that was also "born" 64 bit. Of course support for this would
depend on the toolset and OS.

"He's a god," says Dave Taylor, a co-developer of the original Quake who gave up being
CEO of his own company to work for Transmeta.

I guess your DD was less than thorough Dew. The natives did think he could walk
on water when he was at TMTA. Apology accepted in advance.

I think AMD claimed about a 5% code bloat when recompiling under AMD-64.

AMD claimed code size growth of "< 10%". In the examples of AMD64 code I have
seen posted on the net it seemed to average about 4.9 bytes per instruction
compared to the traditional figure of 3.5 to 3.7 bytes for 32 bit x86 code. AMD
claims the extra registers reduces static instruction count by 10% and dynamic
nstruction count by 5%. That calculates to 1.20 to 1.25x larger code although this
will likely improve inthe future.

Not a big deal, and it's likely that cache miss rates will stay the same, given less
swapping between registers and L1.

A DECWRL study looking at 64 bit pointers found that 64 bit code on Alpha ran
about 5% slower on average than 32 bit code due to cache effects. (code size
stays the same) Add to the bigger pointer effect 10 to 20% larger code and
the benefits of those extra 8 GPRs disappears real fast. I think AMD's own
SPECint2k submissions speak for themselves.

Mike didn't write that article. Nova is still mighty p!ssed at HPaq killing off Alpha in
favor of IPF (he was an Alpha reseller in the far east) so don't be looking for him to
cut Intel any slack. His articles are interesting and often disclose stuff for the first
time but a disinterested observer he isn't.

Check your math. McKinley has been shipping commercially for 11 months. It was a little
over one year in the sampling/proto stage.

LOL, I though that was the purpose of all those 800 MHz and 1.2 GHz Hammers protos
that have reportedly been around for more than a year. Are AMD's development partners
slow learners or what?

You could see, that you will nearly get a 3000+ system for
the same price as a 2,4G NW ... or will you now say, that
3000+ is slowlier than 2,4G?

No. But it is curious that the invisible hand of the FREE MARKET has
determined that the two systems are of equivalent value.

AMD enthusiasts often show an interesting schizophrenia. On one hand
many will point to how much cheaper some *current* AMD processor
or system is than an equivalent Intel product. Yet when attention is
turned to some *future* AMD product the assumption always seems to
be that IT will be the one that finally achieves pricing power parity with
Intel products.

Another manifestation of this odd syndrome is the acceptance that Intel's
recent and current products are more expensive yet Intel still gains market
share and makes money and 50+% margins while AMD loses money with
its dismal 22% margins. Yet some *future* situation where AMD products
will be priced cheaper than their Intel equivalents is presented as a major
economic dislocation, a sea change that represents the inevitable end of
the evil Intel chip empire.

I hope AMD survives another thirty odd years because its fans never cease
to be a source of amusement and wonder. :^)

What does an article unfavorable to Linux have to do with him leaving? While he was at
TMTA he walked on water. Now he is persona non grata. Your pettiness is disturbing.

Here's a rhetorical question: Does the "3100" rating refer to existing 32-bit performance or potential
performance using the A64 extensions?

I suspect that for the vast majority of desktop applications the difference will be negligible. The
benefit of extra GPRs is more or less canceled out by greater cache and TLB miss rates due
to larger code size and doubled pointer size.

wbmw, will Linux be a tossup for Itanium and AMD64? That is not my expectation (I expect to see a whole lot
more optimized AMD64 apps), but the jury is still out so we'll just have to see how it looks a year from now.

On your related comments to others about programming for 64-bits being equivalent - taking care with the size of
INT and the alignment of structures is just one part of the problem. Another part is optimization of critical code
paths - will the Itanium compiler be good enough?

Good point. Gcc for IPF is problematic - the compiler has too many intrinsic problems with poor alias and
dependency tracking to be the basis of a decent EPIC compiler. At least those are the kind of comments
I have read from the various insider groups that have looked at the issue over the last 3 or 4 years. BTW,
gcc had similar quality of code issue with Alpha, the TRU64 compiler ran rings around it.

Intel offers its excellent IRC compiler suite for Linux. Since they are in the chip business, not software,
they should sell it for a nominal fee. Heck, IIRC Compaq ended giving a copy of TRU64 C compiler to non
commercial Alpha Linux users who asked. There are also efforts to offer high quality open source IPF
compilers other than gcc for Linux. These include the Chinese Academy of Science compiler based on
SGI's MIPS open toolset and HP's funding to make Hwu's excellent UIUC Impact compiler technology
open source. There is a large amount of EPIC compiler work being done beyond Intel and HP's internal
compiler efforts for Linux so expect the situation to become increasing favorable to IPF over the next
few years even for those who only accept freebies.

For some things, yes, for other things some attention to optimizing critical paths will be necessary on Itanium but
not AMD64.

All high end uPs benefit from their own unique optimizations and Opteron is no exception. Go look at the flags
for Opteron's peak SPEC submissions vs IPF peak SPEC submissions. The Opteron testers were doing far
more whack-a-mole with flags.

Curious that no one posted about the news that Mr. Linux "has the left the house".

I'd bring up the old aphorism about a sinking ship but it would be grossly unfair
to equate Linus, a decent guy by all accounts, to a rat. The other half, well...

I didn't realize that HP-UX, OpenVMS, IRIX, AIX, z/OS, z/VM, VSE/ESA and Solaris were all being ported to AMD64

z/OS? In the context of someone shopping for a PC at Circuit City?

Well you are the one to bring up the issue of 64 bit software. And to claim that K8 would
run "all the 64-bit software to come". Unless you can show that software development
for all those other platforms and architectures has come to an end in favor of AMD64
then your statement is clearly and utterly wrong and symptomatic of the pathetic FUD
you contiinually spread.

I can make one more important conclusion - this A64 1.8 Ghz most likely will not cost over $100.

AMD shareholders better pray that you are wrong because that could very well be below cost.
How long can AMD afford to sell such a loss leader?

It's a good way for AMD to unload the trash

My nomination for AMD board post of the day. ;^)

Do you really think that AMD will leat HP to soak the top speed grade to use in
low-margine high-volume office crap?

Tsk tsk tsk. So much for gratitude to the first tier 1 OEM to ostensibly adopt a K8 family
processor.

I agree with you that Athlon-64 will not be a cheap chip to produce. Where Barton has a variable cost
around $30, Athlon-64 will probably cost AMD $60 to $75 to produce, at first.

A multiple of 2.0 to 2.5? Get real, AMD would be lucky to eventually get a cost multiple
that low if A64 was a bulk CMOS device that ditched the HT links and used the Athlon
package.

Picture yourself in front of the systems lined up for sale on the shelves of Circuit City or
Comp USA. For a $1,000 you can get a 64-bit 2800+ HP. How much more are you willing
to pay for a 32-bit 3.4ghz P4?

The 64-bit system runs all the 32-bit software and all the 64-bit software to come.

No kidding? I didn't realize that HP-UX, OpenVMS, IRIX, AIX, z/OS, z/VM, VSE/ESA and
Solaris were all being ported to AMD64 along with all their associated applications and
middleware. Do you have any links to back up this incredible claim?

This is something very interesting I spotted at Aces Hardware:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/bph08342/bph08342.pdf

Its specs for a HP A64 based PC. Of particular interest is the processor description
as a 1.8 GHz Athlon64 with 1 MB L2 cache and a QuackHertz rating of 3100+.

This is great news for Intel, especially if the 3100+ is as bogus as the numbers for
the last few Athlon introductions. We are talking about a uP that is much larger than
the Northwood P4, uses SOI processing instead of bulk, 9 layers of interconnect
instead of 6, and a 700+ pin package instead of a 478 pin package. This thing will
be way more expensive to make than Northwood or Prescott and perhaps as much
as 3 or 4 times more to make than a Barton Athlon. I wonder how many 130 nm
A64s AMD can afford to sell? What was it JSIII said about Willamette - it was way
too big? ROFL!

I do concur that Madison will outperform anything else in 1p & 2p configurations, but what have
they done to improve scaling? I suspect Opteron will give good competition at 4p and probably beat
it at 8p (which, like Madison, is being introduced soon).

You suspect wrong. McKinley already beats Opteron at 4P - 58.4 to 49.2 SPECfp_rate2k so
Madison will wallop it.

As far as 4 to 8P scaling, why not look at the SGI Altix 3000. It scales from 4 to 8 with a 98.6%
increase in SPECfp_rate2k throughput. That is far beyond Opteron scaling at any number of
processors shown to date.

BTW, the Altix 3000 does 32P to 64P scaling with a 94.6% increase in throughput. How well
does Opteron do there?

chipguy, of course I was talking dollars, who do you take me for?

Chill, I was giving you the benefit of the doubt, that is why the smiley was
there.

For a true hard core AMD partisan no claim is too outlandish (not mentioning
he-who-will-go-unnamed). I am glad you are not in that category.

I think this intruduction is worth another 3-5 millions for this quarter, very helpful to meet the target.

I hope you talking about dollars, otherwise it is time to call out the guys with the butterfly nets.

OEM's will love this desktop replacement 2800, as it is definitely more reliable in notebook than
P4 at 2.8 Ghz.

I am glad you recognize that the DIY pull on this part is zero. Too bad desktop replacement
laptops are almost always corporate sales and we all know how much business likes AMD
based computers. SOHO sales for expensive desktop replacement machines is probably
mostly in North America and I would bet Dell has a pretty good lock on most of those. Again,
a no show for AMD.