RagingDragon (a@b.c) on 2/7/09 wrote:
---------------------------
>someone (someone@somewhere.com) on 2/6/09 wrote:
>---------------------------
>>Linus Torvalds (torvalds@linux-foundation.org) on 2/6/09 wrote:
>>---------------------------
>>>
>>>Intel could drop IPF tomorrow, and nobody would care.
>>
>>LOL, wish projection on your part.
>>
>>Not only does IPF refuse to die but it refuses to falter.
>>IPF system sales have grown monotonically by $1B/yr
>>for the last five years in a row. In contrast x86's growth
>>has slowed significantly, even shrinking in revenue in
>>Q2 and Q3.
>>
>>You have little more than your personal prejudices and
>>biases to go on. Intel management knows how much it
>>costs to develop brand new IPF microarchitectures, how
>>much it costs to make IPF processors, what it can sell
>>them for, and a damn good idea of the total available
>>market open to IPF for any given combination of features,
>>performance, and pricing. You can't imagine *anything*
>>at all more important than clock rate yet Intel chose to
>>sacrifice ~10% of the frequency of Tukwila, about 200
>>MHz or more, to use flip-flops that are 100 times more
>>resistant to soft errors than those used in its cheaper
>>high volume products. Maybe those who were born into
>>a PC mentality happily accept the occasional funny now
>>and then but I am sure glad my banks don't. :-)
>>
>
>Is there anything (other than a desire to protect Itanium sales) preventing Intel
>from producing a Xeon variant made on the slower but more reliable process?
>

First of all this is not a process issue, it is a design
issue. Intel sells two types of x86 server processors.
The first type uses the same basic chip Intel sells as
desktop and laptop processors (Xeon DP). It is just
plain stupid putting the overhead of big machine class
RAS and scalability features into a design that sells
99% of units into PCs. Then there is Xeon MP. This
is an unique mask design typically differentiated by a
much bigger last level cache but it still uses the same
x86 CPU core as the Xeon DP/PC product. If you want
to use highly soft error resistant flops in Xeon MP then
you would have to redesign, lay out, tune, and reverify
the entire x86 CPU core to do it and that would greatly
increases the design effort and time to market. Maybe
you just haven't noticed but x86 still takes approximately
0% of the mission critical computing market despite
being in the server market in a serious way since 1995.
IPF is firmly established as Intel's "big machine" MPU
family and that's why it gets full RAS and scalability
treatment and x86 doesn't. Deal with it.

Just for fun let's turn your question around. Other than
a desire to protect x86, why hasn't Intel produced cut
down and defeatured IPF MPUs priced low enough for
the high volume 1s/2s server market? Your original
question is no less silly that this if one actually looks
to see what is happening in the market.


>>Not only does Intel refuse to kill it but they keep ramping
>>up the resources available to the IPF business group as
>>sales grow. Since 2007 Intel has had two full processor
>>design teams with over 1000 engineers designing two
>>successive generations of processors beyond Tukwila.
>>Those are not actions of a company reluctantly going
>>through the motions to fulfill contractual obligations.
>>Intel could have kept shrinking the I2 core into process
>>after process with less than a 1/10th of the manpower
>>and money it is investing. Intel also didn't have to let IPF
>>skip right over 45 nm altogether and grant it equal timely
>>access to 32 nm as Xeon MP.
>>
>
>I must've missed the press release - I wasn't aware that 32nm Xeons and Itaniums were available yet.
>
>The fact is, Intel might, or might not, release 32nm Itaniums around the same time
>as 32nm Xeons. When it comes to Itanium Intel have consistently failed to meet release
>deadlines. Until such time as Intel can consistently and successfully execute their
>Itanium roadmaps, those roadmaps are little more than wishful thinking.

No one can predict the future with certainty but there
is something that can be said with 100% certainty. IPF
could never catch up to x86 in process access as long
as it was being designed into older processes to start
with. That changed with Poulson whose development
has been under way for quite a while.