Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Register for free to join our community of investors and share your ideas. You will also get access to streaming quotes, interactive charts, trades, portfolio, live options flow and more tools.
Can you give me any hint, how much do you think one Itanium die costs?
My WAG is that a known good (i.e. tested and functional) Madison die probably
costs between $100 and $150 dollars.
What the margin will be if they will have to price the cheapest Deerfield
under $500?
That depends how Intel allocates IPF NRE and indirect costs between Deerfield
and the $2k and $4k Madisons they sell. Taking the higher estimate, $150, adding
$25 for packaging and final test brings us to $175. Doubling that to include indirect
costs brings us to $350. A $500 ASP gives 30% margin. In this hypothetical scenario
AMD's 2002 margin of 22% could be beaten by any Deerfield ASP over $449. :-P
The Madison is 57% L3 by area. A shrunk 1.5 MB Deerfield device would be ~214 mm2,
ironically the die size of Willamette. Assuming the high end of a $60-$90 KGD cost range
with same $25 package/FT costs and 100% indirect cost adder gives us a $230 cost for
the shrunk Deerfield.
Even if Intel thought they could sell half a million Deerfield the savings from a custom
die for Deerfield is only ($350 - $230)* 0.5m or $60m. When you figure the development
costs plus the device qualification and characterization costs plus the reduced flexibility
in manufacturing planning it hardly seems worth it. So the rumor is probably true.
However, if Intel stays with a single mask set when it introduces its 9 MB Madison next
year then I'd surprised.
while Intel pratically introduced 3 different processors, different by the
cache size, with 4-fold price difference. And #4 Deerfield is coming.
These three processors use the same die. Rumors are that Deerfield uses the same die too.
If true its remarkable that Intel's margins, manufacturing capacity, and yields could be so high
as to manufacture a uP with 6.0 MB L3 cache and then laser off 3/4 of it* to make an entry
level part rather than bother create a separate device with a much smaller die size. Intel
would throw away more cache to make a "$600-$700" part than AMD struggles to achieve
in four separate 193 mm2 Opterons.
*That would make Deerfield the Celeron of the IPF family.
If he choses to go AMD instead, he will have platform #1 for datacenter, webservers
and workstations, platform #2 for webservers, workstations, cheap desktops and laptops.
If he choses Intel he can have FP performance levels *now* AMD won't be able to match
until 65 nm. Assuming AMD is still in business in 3 or 4 years and x86 can scale that far.
What happened to the 2.0 GHz Opteron?
AMD's pitch for its 64now! chip looks more and more like its attempt to sell
the 29k into the workstation market 15 years earlier. The only question left
is will the embedded control market be interested in Opteron. Its still a bit
pricey for their tastes even at $229.
Imagine, how much efforts Dell spent to produce the Merced server? They sold absolutely
zero of those, they lost a lot of money. Do you think they did it just for fun, or Intel was involved?
And finally, do you think Compaq customers celebrated when Intel forced Q to kill Alpha? Intel
strongarmed Compaq,
The faithful are reduced to rocking in their seats, fingering their worry beads, and chanting
tired mantras. I wonder how long before we hear about the 820 chipset and the PIII/1.133 recall.
At the first mention of the P5 FDIV bug it will definitely be time to bring some professional
help. :-P
Gosh, I wonder why Jerry's kids are having such a blue Monday?
chipguy, $600-$700 for Deerfield?
ROFL. That just about says it all.
It sure does YB. Even Intel's "loss leader" is priced over 10x higher than AMD's ASP. ;^)
That is pretty weird. Too big a spread for a binning effect IMO. Occam's razor suggests
a datasheet errata. I'd expect the 1.3 GHz part to <90 W and maybe even <80W.
No, but you can get a $2149 model 844 Opteron (1.8GHz), which will probably have lower performance
than the $1,338 1.3GHz Madison.
Ahhh but can Madison match the PRICE/PERFORMANCE of a $229 Opteron 140? ;^)
I2 1.5/6.0 - 107 W TDP
From the data sheet. So the 130 W figure the AMD partisans wave around like
a crucifix in vampire country must be the power envelope for the entire family.
Maybe 130 W will be approached for the 1.8+ GHz I2 with 9 MB cache. The
power figure for Deerfield should prove very interesting.
That is for the zx6000 workstation. The HP server gets 1322 / 2119. And the Intel press release
confirms that these are SPECbase scores. :-O
Also keep in mind that Madison goes to 1.6 GHz this fall
and 1.8+ GHz next year while picking up an extra 3 MB of
cache.
SPECint 1318 SPECfp 2106
http://www.hp.com/hpinfo/newsroom/press/2003/030630b.html
IPF compilers have improved a lot in just the last year. Whoda thunkit?
The Itanium 2 processor with 6 MB of integrated level three (L3)
cache at 1.50 GHz, the Itanium 2 processor with 4 MB of L3 cache at
1.40 GHz, and the Itanium 2 processor with 3 MB of L3 cache at 1.30
GHz are priced at $4,226, $2,247 and $1,338 in 1,000-unit quantities,
respectively.
The Intel Xeon processor MP at 2.80 GHz with 2 MB of L3 cache, the
Intel Xeon processor MP at 2.50 GHz with 1 MB of L3 cache and the
Intel Xeon processor MP at 2.0 GHz with 1 MB of L3 cache are priced at
$3,692, $1,980 and $1,177 in 1,000-unit quantities, respectively.
And AMD prices its Opteron 140 at $229. At least AMD is being realistic.
$229 list for the Opteron 140?
ROFL. That just about says it all.
but Intel has decided to fight on horseback with
bows and arrows, while AMD is using gatling guns.
After tomorrow only an AMD zealot wouldn't have reservations about accepting such sitting bull.
Now, my point is a little more subtle than that - if a given architecture requires twice as much
instruction cache as a competing architecture, then it will be permanently cost burdened by that
cache requirement at a given generation of manufacturing
Then why is RISC beating the living snot out of x86 in the embedded processor market? ;^)
Your theory isn't subtle it is just wrong. Code spends most of its execution time in loops. Once an
icache or perhaps icache+L2 captures the loop body code of the largest hot loops in a program the
benefit of extra cache tends to drop off, or at least from the perspective of the ifetch portion of CPI.
Why? Consider program B which is 10 times larger in total code size than program A. It is far more
acurate to say B is 10x bigger because it has 10x more loops than A than to say B has the same
number of loops as A but these loops encompass 10x more code. That is why working set size
increases very weakly with program size, and thus increases very little over time. In contrast the
amount of cache that fits on-chip roughly doubles with each process generation (every 2-3 years).
It is true that for less than a specific capacity of on-chip cache an IPF processor will suffer unduly
from code size effects than a CISC or RISC processor. I think it is likely that Merced suffered from
being close to this line (among many other problems). However it is obvious looking at published
data for McKinley that it has enough on-chip cache to be almost entirely insulated from the exansion
of working set code effect. In the future the die size of IPF processors with enough on-chip cache to be
free of the code expansion effect shrinks with Moore's Law. We already see 1 MB caches in 84 mm2
chips for the mobile market. IMO the code size issue will be noise, at least for performance issues, at
the 90 nm process level for desktop class processors. If you have IPF and AMD64 processors both
with 4 MB of on-chip cache then it will matter little if a program's working set code is ~ 0.75 MB in IPF
and ~ 0.25 MB in AMD64. The amount of cache available for data isn't that much different (3.25 MB vs
3.75 MB) and in both cases off chip accesses are almost always dominated by data movement. The
same effect over time allowed RISC to sweep CISC from the extremely cost sensitive embedded uP
market despite worse code density.
chipguy, 29K - AMD dropped it as an embedded processor because they were not successful in getting it designed into products. That is the hard truth: Without design wins you don't have an
embedded product. Had you been at the helm, you would have done the same thing.
No AMD management dropped the ball.
In 1992 they shipped 850k uPs which was 20% of the embedded RISC market. In 1993 they shipped
920k uPs. Their share was down to 11% but it was STILL AHEAD of MIPS (10%) and ARM (8%), the
#2 and #1 architectures today. AMD announced the end of 29k development in December 1995, a
year they shipped 1.8m devices. Ironically they went on to ship 2m devices in 1996 and 2.3m devices
in 1997 despite the death sentence. The numbers didn't start dropping until 1998 (1.7m) when the
lack of new models became problematical.
That is a totally different situation because I am unconvinced that EPIC is the right
direction for processors. I think that Itanium has more than legacy installations to
overcome, it has to overcome its large instruction size.This means that it has an
oversized execution path and always is burdened with needing to flow more memory
into the execution units when compared to other architectures.)
That's what cache's are for. And they are especially effective for storing code due to
its high spacial and temporal locality and the fact that code working set sizes grow
far more slowly than the size of off-chip and on-chip caches. For the 3 MB McKinley
the ratio of the time the processor is stalled for data fetch compared to waiting for
code fetch is between 12:1 and 50:1. And the dominance of data fetch is even higher
in the 6 MB Madison. So your concern about instruction size hurting performance is
not warranted.
Meanwhile, in servers, Intel is still trying to prove they can displace SPARC - a strawman as that
architecture sinks slowly into the quicksand under its own weight. IBM has emerged as the company
to beat in large servers, and we don't hear Intel talk about that much
Intel targets primarily Sun in its IPF material for two reasons. First it is a fat juicy target - SPARC is
slow and it is the server RISC family with the greatest market share. Secondly Sun is the only major
OEM not to adopt IPF and in fact has gone out of its way to spread FUD about it.
OTOH Intel has to be careful not to tee off too strongly on POWER because IBM is a prominent IPF
supporter that brings its own chipsets and unique architecture to the IPF table. There are clearly
strong factional differences within IBM about which architectures to support, how strongly, and which
architectures to pitch to which market segments. Remember that IBM now supports or has publically
announced itentions to support four different 64 bit architectures (POWER, z series, IPF, and AMD64).
I think Intel is wise to focus on SPARC in its own IPF material and leave POWER bashing to OEMs
like HP and SGI. SGI sure doesn't seem to be shy about comparing its Altix 3000 to POWER.
From a technology and product standpoint, I can't remember a time when Intel was in such a weak
position, going back to the early 1980s.
That is a completely absurd claim. I can't decide it reflects more a woeful lack of historical perspective
or complete denial of the current competitive situation. Intel holds incredibly powerful product lines
across all of the embedded control, x86, and high end 64 bit microprocessor markets and year after
year economic and technology trends in semiconductor manufacturing work ever more in its favor.
you have to wonder about amd strategy at this point.
I think AMD strategy with AMD64 is absolutely the best option open to them. Some of their
specific decisions have been questionable (SOI, on-chip memory controllers) but the idea
of filling the gap Intel left by not extending x86 to 64 bits has given them far more mind share
and credibility than say, if they offered a 64 bit 29K or even took up Alpha which AFAIK they
are licensed to do. They have created a pretty clean extension to x86 and worked hard within
realistic boundaries (e.g. dropping TFP in favor of SSE2) to reduce x86's shortcomings.
After having said all that, it still doesn't mean their prospects are great. AMD is a small and
financially ever weakening player with credibility problem among the Fortune 500 IS types
it desperately needs to bring on side. Major OEMs know this and have been staying away
in droves. Only the most architecturially promiscuous of them, IBM, has bothered to even
test the waters with Opteron gear and even then half-heartedly with a 2P cluster building
block.
You're welcome. eom.
The R2000 needed external caches to function. It used a Harvard architecture with
separate data port/cache arrays for the I$ and D$ functions. To save pins they used a
multiplexed address/tag bus that operated at twice the CPU clock rate and required
external latch components. Adding all necessary external components to equal the
basic functionality of a 386 on its own meant the R2000 system burned a lot more
power for CPU functionality.
Ya know, we need to cut the AMD fans some slack. After all, AMD has never tried to introduce
a new general purpose architecture. They did have the 29K in the embedded space
AMD introduced the 29k as a workstation/server processor. After about six months it became
apparent that it was going nowhere fast in that market and AMD changed gears and attacked
the embedded control market instead.
, but it was
eventually killed due to competition and AMD's need to shift scarce resources to their X86 effort.
Another incredibly stupid move by JSIII. The 29k was reasonably successful in embedded
control. After AMD announced it was ceasing development of future 29K uPs the sales of
existing 29k devices continued to grow for several more years. Jerry flushed that all away
and then years later decided to get back into embedded control by buying Alchemy. And
they are having little success. Big surprise, many people remember the 29k family and will
be wary about designing in AMD again. These guys deal with product cycles of 5 to 10 years
and their memory of erratic and undependable uP vendors is at least as long. :-P
When 80386 processor started winning the world it was hardly the fastest. It was
probably at the slower side.
Wrong. It was the fastest of the 32 bit CISC chips of its era. It was 25 to 33% faster
than the MC68020, twice as fast as the NS32032, and 3 to 4x faster than a uVAX-II
or WE32200. The RISC chips that came soon after the 386 were much faster than
all these CISC uPs but were too expensive and power hungry for PC applications
and were used in engineering workstations and servers priced at $10k and up.
Perhaps you think my comment about how many machines "core kernel hackers" buy was flippant
Yup.
Fine, live in your fantasy world. No doubt when the endorsement of Opteron by "core kernel hackers"
turns out to be worth less than a cup of warm spit it you and your ilk will consider it further evidence
of the dark hand of Intel at work behind the scenes.
AMD will finally come with fast batch, allowing it to achieve the 3100 performance rating with 256K
of cache (I think 20 mm^2 at most). So by Christmas sale time, the most popular A64 die will be smaller
than today's Barton.
The Barton is 101 mm2 while AMD has disclosed the size of A64 as 104 mm2. It is obvious
from the Opteron die photo and stated size that a 104 mm2 A64 must be the 256 KB version.
Although not much bigger than Barton, a 256 KB A64 will nevertheless be more expensive to
make, probably much more, due to higher processed wafer costs and lower yield from SOI,
much higher pin count package, and higher test costs. With half the cache and lower clock
frequency than Barton it remains to be seen if AMD can get the performance from A64, and
therefore the pricing power, to preserve its mediocre margins let alone raise them.
and you apparently didn't know what he meant by Linux leaders, started talking about "corporate IT types".
But I'm glad to see my attempt to narrow down the language gave you a new chance to wheel out
your "Linus' opionion doesn't matter" line. Nice to know I brought a little simple pleasure into your life.
After all, we are just here to score points off one another, aren't we?
I thought the subject was the ability of AMD64 to take on other platforms in market share. This
is a forum for AMD investors right? If we want to delve into the psyche of Linux insiders and the
personality cult of Linus Torvalds we should perhaps instead go to slashdot or similar sites.
From the business point of view the "Linux leaders" are those OEMs who are successfully
selling systems to customers to run Linux based applications. From this source:
http://www.nwfusion.com/newsletters/linux/2003/0609linux1.html
the leaders in 1Q03 are IBM, HP, and Dell. HP and Dell are pushing Xeon and IPF for Linux
while IBM is focused on using Linux to help push z series, POWER, Xeon and IPF. Their
Opteron offering seems to be targetting HPC cluster builders on a shoestring budget who
can't afford POWER or IPF systems. Hardly a ringing endorsement for AMD from the top
three Linux leaders, or at least the leaders from the perspective of those selling server
class uPs.
Perhaps you think my comment about how many machines "core kernel hackers" buy was
flippant but in the context of this forum and board the comment was dead on and apparently
stung enough to make you feel my purpose was to score points. Perhaps you should instead
consider the vapid emptiness of making a big deal about the opinions of a handful of kernel
hackers. Does it surprise you that these individuals feel affinity to the vendor and architecture
that is obviously the underdog?
I remember AMD partisans making a huge noise about some game development star (Tim
Sweeney?) who made a strong public endorsement of Athlon and a denounciation of P4. In
the end his opinion mattered the square root of sweet f*ck all in determining the course of
the PC industry. Similarly, no matter how much of a nice guy Linus is or how respected he
is for his contribution to Linux, his personal opinion about uPs counts for equally little
within the big picture. Get over it.
Madison may be on steroids.
Since Madison is going to "rain" on some people's Opteron dreams Monday
maybe we can ask them to do a urine test and confirm this rumor. ;^)
Sorry chipguy, but just because Michael D. is willing to take orders for Intel configured and
built Itanium boxes and then put a Dell sticker on one if it's ever ordered, doesn't make Itanium
"the industry standard" for high end computing.
Care for some whine with your cheese?
I know the continuous stream of false Dell/Opteron rumors have broken your heart but there
is no need to take to be petulant about it. I mean any more petulant then you usually are.
Even if we ignore Dell we still have 11 major OEMs supporting IPF and 1 supporting AMD64.
By the way, the 244s are getting harder to find
Yeah and I haven't seen a VAX in nearly a decade, go figure.
Maybe it'll work, maybe it won't. But your characterization of Itanium as the standard
architecture is simply ludicrous.
Claiming IPF is open or non-proprietary is ludicrous but claiming it is standard is simply
plain fact: Let's look at the remaining 64 bit ISAs and the major OEMS supporting them.
12 for IPF (HP, SGI, IBM, Dell, NEC, Fujitsu, Unisys, Bull, Hitachi, Toshiba, Mitsubishi, NCR)
2 for SPARC (Sun, Fujitsu)
2 for POWER (IBM, Apple)
1 for z series (IBM)
1 for HPPA (HP)
1 for Alpha (HP)
1 for MIPS (SGI)
1 for AMD64 (IBM)
Face it Dan3, AMD64 is in the basement with all the other 64 bit architectures time and
fortune has frowned upon. Given AMD's 8 straight quarters of brutal losses and financial
decline one has to wonder if AMD64 will even outlive Alpha or HPPA.
If it's the core kernel hackers you are talking about, they love Opteron and Athlon64 and
they don't really give a monkey's who has the big money.
Great news for AMD!!!
How many machines a year do "core kernel hackers" buy?
Ha nice catch. As you say, it sometimes works either way. eom.
I think it is obvious that the customer was running an Itanium (Merced) cluster, not an
Itanium 2 (McKinley) cluster. One of the most common and effective FUD techniques
IPF critics (and the unwitting) employ is to confuse Itanium the processor family (IPF),
with Itanium the processor (i.e. Merced). Certain individuals have practically made an
art form out of this sly form of misrepresentation.
After all, is there anything really missing in the AMD64 family from the Linux perspective?
Other than credibility with corporate IT types? Sheesh, most companies won't even buy AMD
based PCs. Suddenly they will buy 10x to 100x more expensive hardware based on AMD uPs?
It is no accident that the first, and so far only, tier one or two OEM support for Opteron is IBM's
2P cluster building block for HPC. HPC guys will try out just about any new architecture that
comes along. But the IT guys are far more conservative. And Linux people know the big money
lies with the guys with the suites, not the guys with pocket protectors. Follow the money.
tanium still holds the record for 4-way performance in that benchmark, and that's still with the McKinley core. Madison increased its lead by 43%,
I believed when DEC did this with Alpha (brought out a much faster new device while
its old device still held the performance record) it was called "lapping the field". Well
done Intel and HP!
Yes, when running data optimizing multi pass SPEC special compilers on fixed, pre-known
data sets, Itanic can be made to look pretty good. Do you know what a data optimizing compiler
is?
You are wrong.
http://www.specbench.org/cpu2000/docs/runrules.html#toc_2.1.3
"Only the training input (which is automatically selected by runspec) may be used for the run
that generates the feedback data."
The data set used for the FDO training run is different from the data set used to generate
the SPEC score reported.
It's one that changes the executable program code to fit the particular data set - utterly
different from the way real world applications work.
You are wrong.
"The requirement to use only the train data set at compile time shall not be taken to forbid
the use of run-time dynamic optimization tools that would observe the reference execution
and dynamically modify the in-memory copy of the benchmark. However, such tools would
not be allowed to in any way affect later executions of the same benchmark (for example,
when running multiple times in order to determine the median run time)."
The SPEC rules allow no more optimization based on reference data than would be seen
in a JIT compiler or Transmeta's CMS. Are not JIT compilers and Transmeta CMS "real" in
*your* world Dan3?
"Whatever spin IBM wants to put on it, there was obviously enormous ambivalence
and disagreement within the company on whether to do that system.
I think the disagreement is from the POWER4/5 guys fearful for their ricebowl. :-P
BTW, this article describes the x450. It should be pretty competitive. But later this year
IBM will bring out the x455. It reportedly uses a completely revamped chipset. From
what I hear IBM is going to give HP and SGI real competition for the IPF performance
crown at a given CPU count. Not bad for a company with "enormous ambivalence". ;^)
chipguy: Re: For the purpose of thermal design of a
system it *is* the maxium power dissipation of the P4.
Not according to Intel:
Ummm, yes according to Intel:
"To allow for the optimal operation and long-term reliability of Intel processor-based
systems, the system/processor thermal solution should be designed such that the
processor remains within the minimum and maximum case temperature (Tc) spec-
ifications when operating at or below the Thermal Design Power (TDP) value listed
per frequency in Table 5-1"
I think that is about as explicit and unambiguous as it could be. And identical to my
statement above that you disagreed with.
chipguy: Re: To a very high tolerance, modern uPs have a constant voltage applied to them.
True. Irrelevant.
Not irrelevent. Very relevent. If uPs obeyed Ohm's law then their current draw would
be constant to an equally high tolerance as their supply voltage. You claimed they did
obey Ohm's law and yet you also admit they don't draw constant current. Busted!
Not exactly. Hence my use of the words "for all practical purposes". What I do claim is that
current multiplied by voltage gives power. You are deflecting the issue. Tsk, tsk.
You brought up Ohm's law in the context of power dissipation. Not only is that a very
practical application of Ohm's law but it is the only reason to bring it up in this thread
in the first place. Bringing it up and then walking away from it when it blows up in your
face is the only disingenuity here. :-P
I'll be generous and give you a clue. Things that obey Ohm's law don't need decoupling
capacitors to compensate for impedance in their power supply.
Irrelevant. This has *nothing* to do with inferring max power from the tech doc.
Sure it is relevent. Decoupling for impedance in the power supply indicates a high
degree of rapid time variation in the current draw. Much more rapid than the thermal
response time constant of the chip. That means Icc_max spec'd for power supply
design is not representative of an Icc_max value for thermal design. The Icc_max
value for thermal design will be less since it is averaged down. Q.E.D.
Listen shave, if you want to play amateur EE here and bring up Ohm's law great. But if
your walk can't match your talk then don't get all huffy about being straightened out, ok?
TDP is very losely defined. That is what I mean by evasive.
I have designed both chips and systems for a long time. I have been on both the giving
and receving end of chip specs. In the end a chip spec is a contract with the chip vendor.
If your system design meets a certain spec then the vendor guarantees correct operation.
But it is also a curtain that hides implementation details and assumptions. If you try to
guess or test what is behind that curtain and use that assumed model in your system
design then you are on very dangerous ground. The vendor is entirely free to change
anything behind the curtain for any reason at any time.
P4 TDP is a precisely specified value for each speed grade. All the details that go into
determining those TDP values lie behind the curtain. What is important is that it is the
system builder's contract with Intel. You build your system to dissipate up to the TDP
value and Intel guarantees correct operation. For the purpose of thermal design of a
system it *is* the maxium power dissipation of the P4.