Alpha vs. Itanic: facts vs. FUD
Bill Todd
around the details of Compaq's decision to scuttle Alpha and take a cruise
on the Itanic, they frequently resort to protestations that it's all a
matter of opinion, preference, or prophecy rather than anything more
concrete. To meet such objections head-on, let's review the things we
*know* (at least unless one assumes that Compaq has lied in the figures it
has itself divulged) and compare their credibility with the Compaq spin.
Executive Summary
1. We know that at no point in the past 2.6 years (i.e., under
post-Pfeiffer management) has Compaq demonstrated any interest in its Alpha
products remotely comparable to its fixation on PCs and 'industry-standard
servers', despite Alpha's far-greater profitability (with the possible
exception of ISS profits during the Y2K dot-com boom, which died along with
it).
2. We know that in cancelling post-EV7 Alpha development in favor of a
migration to the IPF Compaq made a highly-controversial decision and offered
highly-questionable justifications for it.
3. We know that some of these justifications, both technical and economic,
were outright lies.
4. We know that in the process Compaq broke public, repeated, long-standing
commitments to customers that could have been stronger only if they had they
been written into contracts with associated penalties for non-performance.
5. We know that Compaq has made no attempt to address the detailed
questions that have been raised, but has simply kept repeating the same
folderol that accompanied the June 25th announcement.
Is it really any surprise that some customers choose no longer to do
business with this company and that others are pressing for a complete
change of its management? If you think so, or are inclined to scoff at the
assertions above, read on.
Part I: Performance
Compaq and its apologists have said that starting around 2004 Alpha's
"performance advantage [over the IPF] would begin to erode significantly"
and that it would be able to maintain "no substantial performance benefit"
( http://www.eetimes.com/story/OEG20010625S0105 ) in attempting to justify
the decision to consolidate on that family ("the Compaq pseudo-technical
spin continues" on 11/30 analyzed an October Compaq white paper on this
subject that has yet to become generally available).
1. Fact: SPECint2000 performance for today's top-of-the-line (800 MHz)
Itanium is abysmal: 314 for a Dell configuration and 342 for an HP (values
of 365 and 379 have also been listed by HP but reportedly use an ILP32
compiler, which is hardly a generally-useful choice for a 64-bit processor).
SPECfp2000 results are less abysmal (710), but also hardly as applicable to
typical commercial/server use. By contrast, SPECint2000 top-of-the-line
Alpha performance hits 679 at 1 GHz, with a SPECfp2000 figure of 960 for
those interested in that aspect.
2. Fact: Today's top-end Itanium consumes 130W to produce its sub-standard
performance, while today's top-end Alpha consumes about 80W while supplying
twice the performance - i.e., about 3 times the performance per Watt, a
significant advantage in the building of high-density server farms (as noted
in http://www.siliconstrategies.com/story/OEG20010809S0051 ) or any other
power- or heat-sensitive application (or just in the ability to continue to
increase clock speeds -
http://www.zdnet.com/zdnn/stories/news/0,4586,2681998,00.html ). Intel
itself states that using Itanium in a 1U form factor is out of the question
before Deerfield appears
( http://www.zdnet.com/zdnn/stories/news/0,4586,5095529,00.html , which
suggests that this could be as early as late 2002, but given that Deerfield
comes after Madison and Madison is now scheduled for early 2003 that Itanium
prediction appears to have slipped, just as all others have).
3. Fact: Intel's prognosis for McKinley's performance next year (1 GHz at
introduction) is "at least" 1.5x Merced's (given other figures bandied about
it might be 1.6x or even 1.7x, yielding a 550-ish SPECint2000 figure), still
using 130W of power. Alpha's EV7 is expected to debut next year at about
105W with a SPECint2000 of well over 800 (at 1 GHz; 125W and 1000
SPECint2000 if it debuts at 1.2 GHz - see
http://www.realworldtech.com/page.cfm?section=columns&AID=RWT061101221315
for what are still the most-recent estimates I know of), plus major on-chip
support for radically improved memory bandwidth and latency and
multi-processor support (including on-chip routing) that no IPF member yet
defined has (but POWER4 has today and Hammer will next year...). While this
appears to shrink Alpha's performance-per-Watt advantage to about 2:1, that
does not allow for the fact that Alpha's power consumption includes major
on-chip features that McKinley must use additional external chips for - so
while the actual advantage should significantly exceed 2:1 (due to both the
real-world performance advantages of the on-chip glue and the additional
off-chip power McKinley consumes by not having it) it's not clear by how
much, nor is it clear how much McKinley and Madison/Deerfield will be
hobbled by continuing to depend on a shared-bus approach to multi-processor
configurations.
4. Fact: Intel's public road maps stop with Madison (the same McKinley
core in a 0.13 micron process with additional on-chip cache) in 2003
(Deerfield being a cost-reduced Madison with less cache), and while Compaq
has added a 'next generation IPF' entry (without additional description) in
2004 it's not clear that they have any right to expect it before 2005 (since
that's the earliest one might expect the transplanted Alpha EV8 team to get
a new design - even one only incorporating on-chip glue around the Madison
core - out onto the streets). Compaq's October white paper mentioned above
shows Madison hitting 1.8 GHz in 2003H2 (probably *late* H2, as the graph
appears more optimistic than Intel's own estimates); I don't have estimates
for the evolution of EV7's clock speeds in the same time frame, but had
Alpha development not been curtailed it would have been reasonable to expect
EV7 to migrate to a 0.13 micron process during this interval and pick up the
same relative performance boost that Madison did, thus once again retaining
its relative performance and performance-per-Watt advantages.
5. Fact: The main reason EV7 might not have migrated to a 0.13 micron
process was that EV8 was scheduled to arrive in 2003 (presumably in that
process). The prognosis for EV8 was approximately a 2x performance increase
over a comparable EV7 for multi-threaded (i.e., typical server and many
other environments) use due EV8's ability to run 4 separate threads
concurrently on a single EV8 processor ('SMT'). As a result, in typical
server use EV8 should have approximately doubled EV7's well-over-2:1
performance-per-Watt advantage over Madison to 5:1 or 6:1, and EV7's 1.5:1
absolute SPECint2000 advantage to about 3:1.
6. Fact: Without the Alpha team, it's not clear how or when Intel could
have taken the next major step after Madison/Deerfield. EV7-style on-chip
glue might still have appeared sometime in 2005, but adding SMT to the
complex EPIC architecture will be a great deal harder than adding it to an
OoO machine - see Paul DeMone's Silicon Insider columns at
realworldtech.com. For added enjoyment, read the "Alpha and IA64" white
paper at http://www.compaq.com/hpc/ref/ref_systems.html : it describes in
great detail why Alpha will remain superior to Itanium for the indefinite
future, and while the file name has changed to ref_alpha_ia64.pdf from
alpha_ia64.pdf the content appears at least superficially identical to the
original and just as applicable today as it was when written in 1999 (in
part because both Itanium and Alpha schedules slipped in the interim).
Admittedly some of the 'facts' cited above only describe the predictions
that Compaq and Intel made for their respective architectures, but they were
presumably in the best position (respectively) to do so so it qualifies as
'best evidence' in the absence of obvious intent to deceive. The point is
that *all* this evidence, without exception, supports the thesis that Alpha
*would* have retained and even increased its advantages over Itanium through
the point (2004 - 2005) where both road maps become too vague to make even
educated guesses about what might happen next (I don't know what EV9 and
later versions were supposed to add architecturally to Alpha, and the only
thing that's clear about Itanium's future is that trying to add things like
OoO processing and SMT would have been *hard* - and will still be even with
the EV8 team there to help, rather than competing vigorously against it).
So anyone who would care to suggest otherwise, as Compaq has, needs to cough
up some evidence to that effect - and no one has.
Part II: Profitability
Compaq and its apologists have said that Alpha was 'economically
unsustainable' in attempting to justify its cancellation.
1. Fact: Alpha development cost no more than $300 million annually
http://www.zdnet.com/eweek/stories/general/0,11011,2780645,00.html by
Winkler, who would hardly have underestimated it in the context of
attempting to justify the decision to drop it). It may have been half that
(the $150 million quoted in an interview with Rich Marcello -
http://www.eetimes.com/story/OEG20010625S0105 ), and the latter number is
more consistent with the R&D expenditure figures (about $500 million
annually for development of *all* products acquired with DEC, with storage
said to be the largest single contributor) in the 1999 and 2000 Compaq
annual reports.
2. Fact: VMS systems alone as of Summer 2000 generated about $800 million
in annual profit on about $4 billion in annual revenue (from an source at
Compaq sufficiently unimpeachable that those who might be expected to cast
doubt upon it have chosen not to do so). Terry Shannon reported, presumably
on the basis of access to inside information, that VMS grew its sales
modestly in the year between that date and the cancellation of Alpha.
3. Fact: VMS revenue was still listed at $4 billion annually and Tru64
revenue at $3 billion (with Himalaya revenue at $2 billion) in a March, 2001
Compaq slide presentation (cited in a comp.os.vms post, though I'd have to
dig for the date and author). Additional revenue was generated by Alpha
Linux sales (though they may have less significant for revenue than for
market recognition of Alpha as the preferred 64-bit Linux platform).
4. Fact: VMS achieved its revenue and profit despite near-zero promotion
by Compaq ($13 million for all VMS marketing in 2000 from the same source as
above, as contrasted with a $385 million overall Compaq expenditure on
advertising alone from the annual report). There is significant anecdotal
evidence (in terms of the absence of 'sightings' and the preference of the
Compaq sales force for pushing Wintel solutions) of the lackadaisical
(compared with Wintel products) promotion of Alpha itself and Tru64 as well,
though they were not as completely invisible as VMS.
5. Fact: Despite this neglect Alpha business as a whole was growing: BCSD
revenue grew 17% in 2000, and 2/3 the revenue came from Alpha servers
http://www.zdnet.com/zdnn/stories/news/0,4586,2684913,00.html ). Or better
yet Compaq's own numbers from
http://www.compaq.com/newsroom/pr/2001/pr2001021201.html : "With our focus
on providing high-performance enterprise computing solutions, we have seen
AlphaServer systems revenue grow at a rate of 20 percent per year and our
UNIX growth rate has been more than 30 percent-more than twice the industry
average" (other sources have noted that while 4th in market share Tru64
was - prior to June 25th - the fastest-growing proprietary Unix around).
6. Fact: Material in the 2001Q1 and 2001Q2 quarterly reports suggests
(though in typically inscrutable fashion) that Alpha-related revenue and
profit were weathering the slowdown/recession/whatever markedly better than
the 'industry-standard' and PC segments were. Alpha-related revenue
appeared to take a *major* hit in the 2001Q3 report, but lacking
month-by-month internal numbers one would have to take a wild guess at why.
From the above we can conclude that prior to the June 25th announcement
Alpha was quite profitable despite its development cost and enjoyed its
stable and modestly growing market despite Compaq's lack of interest in
promoting it. Hence the likelihood that it would have continued to be
profitable seems high (absent convincing indications that its ability to
compete would decline, already addressed in the 'Performance' section), as
well as the likelihood that it could have grown at a significantly faster
rate had Compaq been at all interested in doing so - in marked contrast to
other Compaq business areas (the PC space) that have struggled just to break
even for years despite Compaq's desperate (and costly) efforts to support
them.
In sum, there appears to have been every reason to promote Alpha vigorously
rather than kill it. Those who would contest this conclusion need to
present comparably-persuasive information in support of their views, and so
far have not presented anything at all.
Part III: Perfidy
So far, the decision to cancel Alpha could simply be considered monumentally
bad judgement by management that did not understand the details of the
situation and acted on minimal and faulty information in a misguided attempt
to eke out a bit more profit for their shareholders (i.e., mere
incompetence). But cancelling Alpha was not just a bad decision: it also
shattered faith with customers who had been reassured time and time again
that they should commit their businesses to Alpha because Compaq itself was
equally committed to Alpha's long-term viability.
Fact: Plenty of anecdotal evidence of such commitments exists but is
unnecessary to reproduce here, because Compaq spelled out these commitments
earnestly and in detail on its Web site in a letter
( http://www.tru64.org/pages.php?page=Valued_Customers ) from two Vice
Presidents which remained there until a month or so after the cancellation.
Ironically, the letter was written shortly after Compaq had pulled the plug
on Windows 2000 support on Alpha (again, after unwavering commitments to
such support right up to the day of cancellation) - and in the process blown
the opportunity for Alpha to have been the sole platform to run 64-bit
Windows until Itanium finally shipped nearly two years later. This move was
seen by many as an indication of Compaq's lack of support for Alpha itself,
and the letter was intended to reassure nervous potential customers that
Compaq was "unequivocally committed to Alpha for the long term" (to quote
from the letter, though I was tempted to find some of the flowery language
of permanence used in land treaties made with the American Indians during
the 1800s).
Compaq broke these commitments unilaterally, without attempting to negotiate
a mutually-acceptable course of action with its customers, without apology,
and with no compelling business reason to do so. Back in the Wild West (to
continue the metaphor above) Compaq's management would not have been fired
for such perfidy: it would have been shot.
Conclusion
I almost feel apologetic for having gone over so much of this again, but as
long as Compaq's lackeys keep denying the legitimacy of these issues and
just repeat the spin that came out on June 25th I'll keep calling them on
it. I at least managed not to repeat *everything* that I said in September
( http://www2.tru64.org/stories.php?story=01/09/06/4674257 ), though in the
process omitted a few details that reflect on Compaq's management no better
than those above.
In closing, it would be hard to better the conclusion of another Paul DeMone
article from 18 months ago - watch out for URL line-wrap
( http://www.realworldtech.com/page.cfm?section=columns&AID=RWT062000000000&
p=9 ):
"It is tempting to see an active period of fierce competition and change in
the computing industry as a prelude to a Darwinian shake out of computer
architectures and vendors from the marketplace. But history has always shown
that such battles are almost always inconclusive. Although the writing is
clearly on the wall for the MIPS architecture in the workstation and server
market, it appears to have a bright future ahead of it in embedded control
applications in telecom and consumer markets. MIPS wasn't defeated in the
competitive high end 64-bit MPU marketplace due to technological problems,
or the superiority of other processor families. MIPS's defeat occurred due
to a self-fulfilling prophecy initiated by a crisis of confidence in the
minds of SGI executive management, who were unwilling to invest in new
processor core development out of the fear they couldn't keep up with IA-64.
Score one for Intel's trademark ability to engage in, and win, campaigns of
psychological warfare against competitors (which is rivaled perhaps only by
Microsoft).
"IA-64 processors will arrive on the 64-bit MPU scene and gradually grab
market share. But this will be due more to who makes them rather than how
they perform. And this share will largely come from IA-64 filling the voids
left by MIPS and (eventually) PA-RISC and helping to grow the 64-bit market
in the direction of the standard high volume server and workstation hardware
niche currently occupied by Intel's 32-bit Xeon product line. Like the
claims made for the Intel i860 a decade earlier, the alleged superiority of
IA-64 and EPIC will prove to be illusionary except for a tiny subset of
computing problems. And there is little reason to believe that existing RISC
processor families such as Alpha, POWER, and SPARC will not continue to be
competitive and thrive in a rapidly growing 64-bit MPU marketplace on the
basis of their current strengths."
Of course, AMD's Hammer may change some or all of that. But it likely won't
be to Itanium's advantage if it does.
- bill
Dr. Dweeb.
Now send a copy of this to the following sets of induhviduals.
Wall Street Casino Analysts
Industry pundits
Industry Analysts (IDC, Aberdeen etc)
The BoD of HP and CompaQ
Carley & Curley (personally)
The HP family.
...
And Bill, I would add to it a job application - since apparently all those
above could use some help :-)
Dweeb.
"Bill Todd" <bill...@metrocast.net> wrote in message
news:T9%O7.240004$dk.16...@bin1.nnrp.aus1.giganews.com...
Drazen Kacar
> 1. Fact: SPECint2000 performance for today's top-of-the-line (800 MHz)
> Itanium is abysmal: 314 for a Dell configuration and 342 for an HP (values
> of 365 and 379 have also been listed by HP but reportedly use an ILP32
> compiler, which is hardly a generally-useful choice for a 64-bit processor).
Why do you think so? How do you explain the fact that a certain number of
Alpha SPEC submissions were produced with -taso compiler option which
forces 32-bit pointers?
The quote below is not meant for you, BTW.
--
.-. .-. Unlike good wine, bullshit doesn't improve with age.
(_ \ / _) -- John McLean
| da...@willfork.com
|
Bill Todd
"Drazen Kacar" <da...@willfork.com> wrote in message
news:slrna0p3u...@raven.arsdigita.de...
> Bill Todd wrote:
>
> > 1. Fact: SPECint2000 performance for today's top-of-the-line (800
MHz)
> > Itanium is abysmal: 314 for a Dell configuration and 342 for an HP
(values
> > of 365 and 379 have also been listed by HP but reportedly use an ILP32
> > compiler, which is hardly a generally-useful choice for a 64-bit
processor).
>
> Why do you think so?
If you're asking why I think that limiting pointers to 32 bits is hardly a
generally-useful choice for a 64-bit processor, I'll answer that you might
as well be using a Xeon-like 32-bit processor if you can do so.
How do you explain the fact that a certain number of
> Alpha SPEC submissions were produced with -taso compiler option which
> forces 32-bit pointers?
I don't explain it, because I wasn't aware of it. If it's so, it's as
dubious as HP's practice above (unless it was produced before DEC *had* a
useable 64-bit compiler, or occurred on VMS before VMS supported 64-bit
pointers, either of which would be a reasonable excuse. FAIK that *could*
have been HP's excuse as well: I was just pointing out that use of such
could inflate the performance numbers when compared with a fully-64-bit
compiler, which I assumed - I hope with some justification - was the norm
when testing 64-bit processors).
>
> The quote below is not meant for you, BTW.
Thanks for the clarification. I liked it too.
- bill
Tim Shoppa
> So far, the decision to cancel Alpha could simply be considered monumentally
> bad judgement by management that did not understand the details of the
> situation and acted on minimal and faulty information in a misguided attempt
> to eke out a bit more profit for their shareholders (i.e., mere
> incompetence).
No, it was the *only* decision that the corporate culture of Compaq
could support. They sell Wintel boxes; that's all they've ever done;
they cannot see the world outside those blinders. (HP used
to do a lot more other than sell Wintel boxes and printers, but
they've decided to wear the same set of blinders.)
I agree with all your other points, but they're irrelevant when
Compaq management can't even fit those facts into their brains. Their
belief system simply doesn't allow it.
Tim.
David Brown
Tim Shoppa wrote in message <3C0C6AD0...@trailing-edge.com>...
Then why did they buy the Alpha in the first place?
Bill Todd
"Dr. Dweeb." <Dw...@nospam.com> wrote in message
news:dF%O7.20$uQ4....@news.get2net.dk...
> Outstanding !
Aw, shucks.
>
> Now send a copy of this to the following sets of induhviduals.
>
> Wall Street Casino Analysts
> Industry pundits
> Industry Analysts (IDC, Aberdeen etc)
> The BoD of HP and CompaQ
> Carley & Curley (personally)
> The HP family.
While I'd be more than happy if someone considered it worthwhile to
circulate it to such people, I'm spending more time than I should on this
already for someone whose only motivation is disgust at Compaq's actions.
"Think globally, act locally" applies to me in this case, and 'locally' for
me is just here (though I did consider including an HP newsgroup in the post
in case they might not realize the kind of upper-management 'talent' they
may be about to acquire - but had no idea which would be appropriate).
- bill
Martin Knoblauch
>
> >
> >I agree with all your other points, but they're irrelevant when
> >Compaq management can't even fit those facts into their brains. Their
> >belief system simply doesn't allow it.
> >
> >Tim.
>
> Then why did they buy the Alpha in the first place?
they didn't buy Alpha. They bought DIGITAL and that way "accidentially"
got a few things that they never really understood. Folklore says they
bought Digital primarily for the Services organisation. Getting
Alpha/Tru64/TurClister/OpenVMS was "just" a side effect.
The Inquirer today had a piece on it. Not necessarily scientific, but I
think some of it is pretty near to the truth:
http://www.theinquirer.net/04120101.htm
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.K...@TeraPort.de
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
Jan Vorbrueggen
> > 1. Fact: SPECint2000 performance for today's top-of-the-line (800 MHz)
> > Itanium is abysmal: 314 for a Dell configuration and 342 for an HP (value
> > of 365 and 379 have also been listed by HP but reportedly use an ILP32
> > compiler, which is hardly a generally-useful choice for a 64-bit processor
> Why do you think so? How do you explain the fact that a certain number of
> Alpha SPEC submissions were produced with -taso compiler option which
> forces 32-bit pointers?
IIRC, the difference in performance achieved by -taso is much smaller on Alpha
than those pointed out above: only a few components need apply, and even with
them the gain is in the 5% arena.
Jan
Bill Todd
"David Brown" <dav-no...@westco-nospam-ntrol.com> wrote in message
news:9uignn$t6p$1...@news.netpower.no...
Because Palmer couldn't figure out a way to get rid of it and still have a
company to sell them.
- bill
Tarjei T. Jensen
Bill Todd wrote in message ...
>If you're asking why I think that limiting pointers to 32 bits is hardly a
>generally-useful choice for a 64-bit processor, I'll answer that you might
>as well be using a Xeon-like 32-bit processor if you can do so.
You are being silly. According to a compiler vendor (ACT), 32bit pointers
gives you faster programs which takes up less space in a 64bit machine. A
64bit machine lets you play around with more memory.
Greetings,
jmfb...@aol.com
You're half right, although I don't know why. Rats, that
came out wrong....I don't know why Palmer couldn't manage to
sell the Alpha and OS business.
Compaq wanted DEC's hot line infrastructure; they didn't want
anything else. hmm...they don't call hot line anymore but
I can't recall the term used these days.
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
Dr. Dweeb.
"Tarjei T. Jensen" <tarjei...@kvaerner.com> wrote in message
news:9uimo2$k5...@news.kvaerner.com...
Smaller for sure, but how does that mean faster ?
Image activation a bit quicker, but what else ???
Dweeb
Chris Morgan
> Smaller for sure, but how does that mean faster ?
> Image activation a bit quicker, but what else ???
32-bit pointers fit into half as much memory as 64bit pointers, so
using 32-bit pointers on a 64-bit machine may improve your
applications performance to the extent that it is memory bandwidth
constrained (cache, main memory etc) and to the extent that it shifts
a lot of pointers about. On average this may be a small effect, except
where using them (32-bit ptrs) keeps your working set inside some
level of cache and not using it doesn't.
Chris
--
Chris Morgan <cm at mihalis.net> http://www.mihalis.net
Temp sig. - Enquire within
Bernd Paysan
> > Then why did they buy the Alpha in the first place?
>
> Because Palmer couldn't figure out a way to get rid of it and still have a
> company to sell them.
He could probably have moved all those stuff to Samsung/API.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Nick Maclaren
In article <3C0CEFC0...@gmx.de>, Bernd Paysan <bernd....@gmx.de> writes:
|> Bill Todd schrieb:
|> > > Then why did they buy the Alpha in the first place?
|> >
|> > Because Palmer couldn't figure out a way to get rid of it and still have a
|> > company to sell them.
|>
|> He could probably have moved all those stuff to Samsung/API.
At that stage, the DoD/NSA would almost certainly have vetoed that.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
JF Mezei
> Executive Summary
Bill, trying to be the devil's advocate for a nanosecond:
If Compaq feels that it can maintain the remaining VMS installed base with a
migration to IA64, then all of the profits generated by VMS under alpha should
continue to flow with ia64. So by moving VMS customers on Intel vapourware,
Compaq need not spend any money on Alpha and still get the profits from VMS.
Compaq has fixed Alpha engineering costs, and variable fabbing costs. I would
suspect that each Alpha chip costs much less to fab than it will cost Compaq
to buy a IA64 chip from Intel. For high volumes, this would favour Alpha since
the per unit cost would be much lower. But with low volumes, the fixed costs
start to matter and the higher unit price of IA64 may end up being cheaper to compaq.
Compaq used the "consolidation" thing which will steamline all servers on the
same architecture. Horse radish. The only savings will be the low end Alpha
servers and workstations that will be replaced by that Proliant stuff. Tandem
machines will continue to require their special systems and cabinets, and
large VMS systems will continue to require their special systems (such as
wildfire equivalents) and cabinets.
Is this really different than a scenario where Compaq would have made a
serious commitment to Alpha and convinced Microsoft of such with Windows64
having Alpha has it première platform years ago ?
Tandem would have migrated to Alpha, VMS and Tru64 were already there, and
Microsoft would have made Windows and layered products for Alpha. Intel and HP
would have been stuck with a big bloated and underperforming dud that was
still years before being real silicon. But that didn't happen unfortunatly
with Compaq having blown that opportunity.
Compare this with the current scenario: Intel is essentially paying Compaq to
port Tandem-NSK and VMS to that IA64 thing. Tru64 is just giftwrapped and
handed over to HP to do as it wishes.
And since Compaq doesn't have long term plans for VMS, it doesn't mind if its
image is hurt by the broken commitments to Alpha and the continued lack of
marketing of VMS because it has personally contacted those profitable
customers Compaq wishes to retain and convinced them to stick around with VMS
for a while.
In the end, the biggest irony is that days after Compaq announces it wants to
become IBM, Compaq does the opposite and takes steps to become just another
box maker that assembles everyone else's technology.
The one big question that remains is who really purchased Digital. Could
Intel and Microsoft have convinced Compaq to buy Digital and ensure that
Digital's jewels are burried ? Or was Compaq really stupid enough to buy all
that stuff and take active steps to ruin it ?
What Compaq could have done is simply buy Digital's PC business and in
exchange for reliving Digital of its PC misery, Digital would have
"code-shared" the services business with a Compaq branding of Digital provided services.
Digital would then have been able to focus on its enterprise systems while
Compaq would have been able to concentrate on its wintel crap and both would
have shared the service/support business.
Rupert Pigott
>
> > 1. Fact: SPECint2000 performance for today's top-of-the-line (800
MHz)
> > Itanium is abysmal: 314 for a Dell configuration and 342 for an HP
(values
> > of 365 and 379 have also been listed by HP but reportedly use an ILP32
> > compiler, which is hardly a generally-useful choice for a 64-bit
processor).
>
> Why do you think so? How do you explain the fact that a certain number of
> Alpha SPEC submissions were produced with -taso compiler option which
> forces 32-bit pointers?
Interesting...
Could be down to broken code, in source or libraries. At a place of work we
used -taso to fix seriously broken source which assumed 32bit-ness. That
also occurred in some libraries too, so we had to compile stuff linked
against them with -taso too.
Personally I'd have preferred to have fixed the code properly, because
anything which is that sensitive is untrustworthy.
There might well be performance reasons for it. In certains apps pointer
size can contribute substantially to the working set of an application,
therefore halving the pointer size improves cache utilisation. ;)
Cheers,
Rupert
Bill Todd
If you're suggesting that a 64-bit machine allows an application compiled
with 32-bit pointers to 'play around with more memory', I'm interested in an
explanation of how. The only advantage I can think of running an ILP32
program on a 64-bit machine (vs. on a 32-bit machine) is the ability to
execute 64-bit-wide arithmetic operations (using longlong, int64, or
whatever the compiler provides) natively, but I could be missing something
obvious.
If you're suggesting that a 64-bit machine is required to allow use of more
than 4 GB of physical memory, you're simply wrong: PAE support in 32-bit
Windows 2000 is designed to handle up to 64 GB of physical memory (e.g., on
32-bit Xeons, which was why I mentioned them) to run 32-bit applications in,
and may (though I'm not familiar with it at this level of detail) make more
than 4 GB of physical memory available for system use (e.g., as extended
cache).
So unless I'm missing something above, it's not obvious that a 64-bit
architecture is particularly valuable if all you're going to do is run ILP32
programs on it.
- bill
Bill Todd
"JF Mezei" <jfmezei...@videotron.ca> wrote in message
news:3C0CFA13...@videotron.ca...
> Bill Todd wrote:
> > Executive Summary
>
>
> Bill, trying to be the devil's advocate for a nanosecond:
>
> If Compaq feels that it can maintain the remaining VMS installed base with
a
> migration to IA64, then all of the profits generated by VMS under alpha
should
> continue to flow with ia64. So by moving VMS customers on Intel
vapourware,
> Compaq need not spend any money on Alpha and still get the profits from
VMS.
That could be the explanation for Compaq's behavior, in which case it was
grossly incompetent (since it should be clear by now that VMS profits - and
perhaps even more so Tru64 profits, given the apparent consequences of the
HP acquisition - are *not* going to continue unscathed across this event)
and perfidious with respect to existing commitments to users and the lying
attempts at justification. Which is what I thought I said.
- bill
Toon Moene
>
> they didn't buy Alpha. They bought DIGITAL and that way "accidentially"
> got a few things that they never really understood. Folklore says they
> bought Digital primarily for the Services organisation. Getting
> Alpha/Tru64/TurClister/OpenVMS was "just" a side effect.
I thought the term was "collateral damage".
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
Dirk Munk
Now I would like to see Compaq's reaction. We all know Compaq is reading this newsgroup, so I challenge Compaq management to react to this article. Point for point, and of course with cool facts !
I think that in case of the absence of such a reaction, we can safely assume that your vision is correct, and Compaq is not able to deny it.
Regards,
Dirk
Drazen Kacar
>
> "Drazen Kacar" <da...@willfork.com> wrote in message
> news:slrna0p3u...@raven.arsdigita.de...
> > Bill Todd wrote:
> >
> > > 1. Fact: SPECint2000 performance for today's top-of-the-line (800
> MHz)
> > > Itanium is abysmal: 314 for a Dell configuration and 342 for an HP
> (values
> > > of 365 and 379 have also been listed by HP but reportedly use an ILP32
> > > compiler, which is hardly a generally-useful choice for a 64-bit
> processor).
> >
> > Why do you think so?
>
> If you're asking why I think that limiting pointers to 32 bits is hardly a
> generally-useful choice for a 64-bit processor, I'll answer that you might
> as well be using a Xeon-like 32-bit processor if you can do so.
I'm not very familiar with x86 processors, so I don't know what you mean.
> How do you explain the fact that a certain number of
> > Alpha SPEC submissions were produced with -taso compiler option which
> > forces 32-bit pointers?
>
> I don't explain it, because I wasn't aware of it. If it's so, it's as
> dubious as HP's practice above (unless it was produced before DEC *had* a
> useable 64-bit compiler, or occurred on VMS before VMS supported 64-bit
> pointers, either of which would be a reasonable excuse.
I don't think so. The latest Compaq submission for Alpha lists
-xtaso_short option for several benchmarks.
http://www.spec.org/osg/cpu2000/results/res2001q4/cpu2000-20011022-01046.html
And the explanation for the flag tells us:
-xtaso_short (Compaq C)
Directs the compiler to allocate 32-bit pointers by default. You
can still use 64-bit pointers, but only by the use of pragmas. [...]
> FAIK that *could* have been HP's excuse as well: I was just pointing
> out that use of such could inflate the performance numbers when
> compared with a fully-64-bit compiler, which I assumed - I hope with
> some justification - was the norm when testing 64-bit processors).
Not really, I think. The norm seems to be: whichever combination of
options and settings produces the best result. So you'll find submissions
for Unix systems produced in single-user mode, which is hardly a
generally-useful choice for a Unix system. Or you'll find them with
kernel settings which affect L2 cache policy, so that different runs of
a program might produce different results, but some of them will be
somewhat better than without that kernel setting. This used to be quite
popular on SPARCs under Solaris. And there are other little tricks like
this, all done in pursuit of the highest number.
Anyway, I brought this subject up because it seems to me that it's
fairly important. There once was a paper on DEC site which reported their
performance measurements with respect to pointer size, done on early
Alphas. They had two bad things to report:
1. If your application needs a lot of memory, it might happen that its
data won't fit in physical RAM in case it uses 64-bit pointers, although
it would if it used 32-bit pointers. Then you'll see some swapping if you
use 64-bit pointers. That could have disasterous effects on performance.
2. 32-bit pointers take twice less space in the CPU cache, so you might see
better performance because of this. The worst example they had was
performance downgrade of 12%, I think, but the average was less than
that.
But they chose to ship a Unix system with the default 64-bit pointer
compilation environment. While this choice introduced measurable
performance decrease, it had the benefit of only one ABI and only one set
of libraries. It was a good trade-off, IMO.
I don't know if that paper is still available from somewhere.
I'd tend to ignore the first problem because of a "buy more RAM"
solution. The second one is interesting, though. There's a small class of
applications which will benefit from LP64 environment. Those that could
use more than 4GB of memory and those that perform a lot of 64-bit
integer calculations.
Big memory consumers are largely databases and 64-bit CPUs are benefitial
for them. There are ways to use more than 4GB even with 32-bit CPU, but
as far as I'm aware, that requires changes to the application code, so
it's not an extremely good solution. Further, CPU cache utilization for data
will probably not have that much impact if you're actually using 4 gigs
of RAM. I would guess that TLB trashing might have greater impact in
these cases, but I have no data to prove it.
In any case, databases are important.
The second category appears to be fairly small. It has been recently
pointed out to me that one such program is seti@home. I have no reason
not to trust the source of information, but I don't know of any other
program in this category.
It's also interesting to point out that seti@home probably doesn't
require 64-bit pointers. It just needs 64-bit integer arithmetic, so
stating that it would benefit from LP64 environment is somewhat
misleading. Take SPARCs, for example. On recent Solaris releases you have
two environments on 64-bit CPUs: ILP32 and LP64. There is no way to have
32-bit pointers and 64-bit longs. The CPU wouldn't have problems with
that, but the OS doesn't support it. The legacy ILP32 environment doesn't
allocate enough space to store 64-bit registers on context-switch, so you
can't use the upper 32 bits of integer registers there. The new LP64
environment uses 64 bits for pointers and longs. Sun could have
introduced a third environment which would feature 32-bit pointers and
64-bit longs, so seti@home would run even faster, but that means having
yet another ABI and yet another set of libraries. I'm quite thankful
that they didn't do this.
However, with -taso on Tru64, you can have 32-bit pointers and 64-bit
integer arithmetic, if you're willing to spend some time to set it up.
I regard -taso as one of the optimization options to be used when one
needs to squeeze the last few percent of the performance from the
compiler. It's very nice that it's there, but I wouldn't use it every
day, because there's a price to be paid.
There's one benefit you'd get from migrating to 64-bit environment on
operating systems which were running on 32-bit environments (Solaris and
IRIX, for example): since it's a migration to the new ABI, the vendor
will get a chance to fix some stuff that couldn't be fixed in 32-bit ABI
because of binary compatibility issues. This probably isn't applicable to
Alpha, but just for the record.
Time to make a point, I suppose. The above text says that I wasn't able
to find a lot of applications which would benefit from 64-bit
environments. (And I've been looking for them.)
That means that your good old 32-bit apps are perfectly adequate and will
usually perform a few percents faster than 64-bit apps. So why would
anyone go through the pains of converting their 32-bit apps to 64-bit
apps? Except for the database vendors, of course.
I remember the time when Digital released its 64-bit Unix on Alpha.
A huge number of free software programs had problems. They just weren't
64-bit clean, which was not a surprise, because they were never tested on
a 64-bit environment. AFAIK, at the time Digital had the best BSD/SYSV
support in their OS, so it largely wasn't a question of the APIs that were
used in the applications.
It took quite some time to clean the apps. And this is a task where free
software community is traditionally better that closed source software
vendors, because anybody can do it. Digital's lint implementation was a
big help for me, I have to say. But I have no reason to believe that
commercial software would be ported any time soon to 64 bits if there are
no visible benefits. So just databases and scientific applications with a
huge data sets? Hmm, but you have them already running perfectly fine on
your current 64-bit OS and CPU.
Since I'm not following IA-64 very closely, I'll have to admit that I
don't know which OS is supposed to be the most important OS for that CPU.
If it's something coming from Microsoft, I'd estimate that the porting
effort for all third party applications would take a lot of time, because
the applications were never tested on a 64-bit OS. Unix people had a lot of
problems and I don't see why Microsoft nation wouldn't.
I've also seen reports stating that IA-64 doesn't run legacy x86 code
with a remarkable speed. I don't know if that's true, but if it is,
you'll have a problem with IA-64. Software vendors are just going to tell
you that they see no reason to port to 64-bit IA-64 environment when you
can spend less money on x86 solution (Hammer, maybe) and get a better
performance from their software.
Nikola Milutinovic
news:9uignn$t6p$1...@news.netpower.no...
>
> >Compaq management can't even fit those facts into their brains. Their
> >belief system simply doesn't allow it.
> >
> >Tim.
>
> Then why did they buy the Alpha in the first place?
They bought Digital. Why did they burry Alpha? Ask yourself who profitted by
it - Intel. Looks like a behind-the-scenes deal to me.
Nix.
cjt
I subscribe to the view, which appeared in an article I saw someplace here,
that what they were after was the service/consulting group, and not the
enterprise platforms +/-.
Ketil Z Malde
> You are being silly. According to a compiler vendor (ACT), 32bit pointers
> gives you faster programs which takes up less space in a 64bit machine. A
> 64bit machine lets you play around with more memory.
If I had a dime for every time I've wanted to change compiler vendor,
I could probably afford a better compiler, too.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
René Schelbaum
"JF Mezei" <jfmezei...@videotron.ca> schrieb im Newsbeitrag
news:3C0CFA13...@videotron.ca...
> Bill Todd wrote:
> > Executive Summary
>
> Compaq used the "consolidation" thing which will steamline all servers on
the
> same architecture. Horse radish. The only savings will be the low end
Alpha
> servers and workstations that will be replaced by that Proliant stuff.
Tandem
> machines will continue to require their special systems and cabinets, and
> large VMS systems will continue to require their special systems (such as
> wildfire equivalents) and cabinets.
did you say 'steamline' intentionally, because it's still vaporware ?
René
<snip>
Tarjei T. Jensen
Bill Todd wrote in message ...
>than 4 GB of physical memory, you're simply wrong: PAE support in 32-bit
>Windows 2000 is designed to handle up to 64 GB of physical memory (e.g., on
>32-bit Xeons, which was why I mentioned them) to run 32-bit applications
in,
>and may (though I'm not familiar with it at this level of detail) make more
>than 4 GB of physical memory available for system use (e.g., as extended
>cache).
That only applies to intel and HP CPUs as far as I know.
I'm pretty sure that Robert Dewar knows what he is talking about.
greetings,
Ketil Z Malde
> Compaq has fixed Alpha engineering costs, and variable fabbing
> costs. I would suspect that each Alpha chip costs much less to fab
> than it will cost Compaq to buy a IA64 chip from Intel. For high
> volumes, this would favour Alpha since the per unit cost would be
> much lower. But with low volumes, the fixed costs start to matter
> and the higher unit price of IA64 may end up being cheaper to
> compaq.
It seems to me that in the chip market, volume is everything. Most of
the RISCs that started out with clean designs and performance
advantages, are experiencing serious competition from x86, even if
they (arguably?) still maintain a performance edge.
As the performance disadvantage of the commodity x86 chips diminishes,
the high-end RISCs get tucked into a smaller and smaller market
segment, with development cost being amortised over fewer and fewer
units. Thus, the price/performance advantage for the commodity chips
increases further, volume and market share expands, more money can be
invested in better manufacturing process, and the wheel turns.
I guess that was kinda obvious.
It was probably obvious to SGI, HP and Compaq, who are to various
degrees trying to find a suitable bandwagon to jump onto.
Unfortunately, after much hard work segmenting the market into PeeCees
and Real Iron, the x86 is out. Even more unfortunately, the IA64
proves to have more than its share of initial problems.
Unsurprisingly to some, but one can easily imagine executives not
seeing far beyond the Intel brand, and/or relying on Intel's strong
commitment to pull it through.
> Is this really different than a scenario where Compaq would have
> made a serious commitment to Alpha and convinced Microsoft of such
> with Windows64 having Alpha has it première platform years ago ?
Compaq(/Digital) was probably not all that far from making Alpha a
commodity, with multiple manufacturers and reasonably independent
development. At one point, a large part of the PC-using Linux crowd
saw an Alpha workstation as the ultimate iron. Alpha had a
price/performance advantage, they should have ruled the compute-rack
business now.
Whether that would have been sufficient is of course an open
question.
> The one big question that remains is who really purchased Digital.
> Could Intel and Microsoft have convinced Compaq to buy Digital and
> ensure that Digital's jewels are buried?
Intel I can understand, but what does Microsoft gain? One would
imagine a revival of NT/Alpha would be at least as easy as a brand new
NT/IA64.
But Intel managed to bury the most commoditized 64-bit contender,
and a likely performance thorn in their side. I don't know the
details of the deal, but unless Compaq were asleep at the wheel, they
should have received sustantial benefits.
> Or was Compaq really stupid enough to buy all that stuff and take
> active steps to ruin it?
Mergers are always difficult, and rarely beneficial, it seems.
Martin Knoblauch
>
>
> But they chose to ship a Unix system with the default 64-bit pointer
> compilation environment. While this choice introduced measurable
> performance decrease, it had the benefit of only one ABI and only one set
> of libraries. It was a good trade-off, IMO.
>
personally I think it was a bad choice. While definitely the "pure"
way, it probably hindered a lot of ISVs to move to Alpha (from other
architectures), because of the 64-bit cleanup work.
I was at SGI at that time and we fared pretty good with 32-bit
pointers, even on the machines that had 64-bit kernels.
Why? IMO it was to early for broad useage of 64-bit pointers. Remeber,
the Alpha and the MIPS R4K came to market in 1992 or so. At that time
only HPTC and some databases *needed* more than 32-bit address space.
Porting the HPTC stuff was easy, as it was (is) mostly Fortran with no
pointer arithmetic. And the DB people ported, because they needed/wanted
the space. All the other apps were happy with 32-bit. Many of them still
are today.
By limiting/defaulting to 64-bit, DEC probably helped to clean up some
code early, but they likely also shot themselves in the foot big time.
Anton Ertl
"Rupert Pigott" <Dark...@btinternet.com> writes:
>Drazen Kacar <da...@willfork.com> wrote in message
>news:slrna0p3u...@raven.arsdigita.de...
>> Alpha SPEC submissions were produced with -taso compiler option which
>> forces 32-bit pointers?
>
>Interesting...
>
>Could be down to broken code, in source or libraries.
No, at least not for SPEC95. I have run SPEC95 on Linux-Alpha,
compiling with gcc (which does not have an option like -taso), and it
works.
Followups to comp.arch.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Robert Harley
"Bill Todd" <bill...@metrocast.net> writes:
> As the spin-meisters continue their attempts to weave a web of uncertainty
> around the details of Compaq's decision to scuttle Alpha and take a cruise
> on the Itanic, they frequently resort to protestations that it's all a
>[...]
Nice summary. I agree with it (mostly). Thank you.
Just for fun, here's the average of SPECint and SPECfp for a selection
of current Intel chips:
Chip MHz Score
------------------------------------
Pentium 4 2000 699
Pentium 4 1900 665
Pentium 4 1800 658
Pentium 4 1700 636
Pentium 4 1600 601
Pentium 4 1500 588
Pentium 4 1400 551
Itanium 800 541 <- bet the farm on this one!
Bye,
R
JF Mezei
> It seems to me that in the chip market, volume is everything. Most of
> the RISCs that started out with clean designs and performance
> advantages, are experiencing serious competition from x86, even if
> they (arguably?) still maintain a performance edge.
The fact that Intel embarked on its giant IA64 project is a clear indication
that Intel was seing a ceiling come for the 8086's performance. Otherwise it
would have continued to pump out Pentiums that are ever faster and faster.
I would think that one problem with an inefficient architecture is that you
have to compensate with higher fabbing technology. This is why the 8086 has to
have significantly higher close speeds than PowerPC or Alpha to achieve
similar performance.
This would mean that to compete against Alpha and Power, Intel would have to
spend on new fancier FABs before the others to achieve performance others get
with cheaper fabbing techniques. So to keep up with Power and Alpha, the 8086
might have started to cost more and more.
The problem is that IA64 seems to have been built with too many compromises to
allow it to really give the performance at lower clock speeds. So now they are
stuck with a complex large chip which is harder to fab with the high clock
speeds that are possible on the 8086 because it is a simpler chip.
> As the performance disadvantage of the commodity x86 chips diminishes,
> the high-end RISCs get tucked into a smaller and smaller market
How much more can the 8086 advance its performance compared to the newer
architectures such as Power and Alpha ? If it hits a ceiling, then the race is
over and 8086 will be left behind.
Can the 8086 be used to build systems such as Wildfires ? Does it have what it
takes ? While it may be well suited to run video games and gas pump displays,
is it really well suited to run complex servers ?
> Intel I can understand, but what does Microsoft gain? One would
> imagine a revival of NT/Alpha would be at least as easy as a brand new
> NT/IA64.
Microsoft knows that NT may have stolen much from VMS but that it is still
flawed compared to VMS. Microsoft knows that VMS has great potential as a true
server OS and even as a desktop one if someone is willing to spend the money
to market it. So it is to Microsoft's advantage to ensure that VMS stays
hidden and tagged "dying legacy".
VMS is one of the few remaining "quality" OS that can be fully supported and
thus suitable for 24/7 serious environments. Technologically, it is a serious
competitor to NT and Microsoft knows that it doesn't have what it takes to
build something that can technologically compete against VMS. Stealing Dave
Cutler wasn't enough to build an OS that could technologically compete against VMS.
So what do you do to a competitor that is clearly better than you are ? Make
sure no spotlight ever shines on it and that it is stored in the basement
where nobody sees it. And that is what Digital and Compaq have done.
> and a likely performance thorn in their side. I don't know the
> details of the deal, but unless Compaq were asleep at the wheel, they
> should have received sustantial benefits.
Asleep at the wheel. They are brainwashed into the idea that only Intel-based
servers will survive and that there is no way for anyone to counter that
coming tidal wave that Intel was able to predict. Same philosophy for NT.
Heck, if the Compaq accountants figured that Alpha was a cost centre instead
of a profit generator, I wouldn't be surprised if Compaq paid Intel to relieve
them of that Alpha they never wanted in the first place. Nice deal, no
employee severance packages and then probably get to isent their tongue a bit
deeper into Andy Grove's derrière.
Since they can't win the war against dell by being more efficient than Dell,
they figure that the only way to survive is to lick Grove and Gate's derrière
better than Mickey Dell can and hope to get better deals from MS and Intel.
> Mergers are always difficult, and rarely beneficial, it seems.
Everyone knows that. This is why any merger that happens now, especially in
IT, should be viewed as an exercise in eliminating a competitor, not an
excercise in growing a company, especially when two companies are nearly
identical as was the case with HP and Compaq. HP gets very little it doesn't
already have when it buys Compaq, except its existing customers, and a bigger
share of the pie of future customers since there will be one less PC manufacturer.
My guess is that once Compaq is gone, Dell will start to build more serious
servers and a more serious enterprise business and will kill HP at the server
business just as it killed Compaq at the PC business.
Maynard Handley
<har...@estephe.inria.fr> wrote:
Well we all know how well ignoring Intel and those stupid underpowered
CPUs they produced in the 80's worked out for DEC the first time round.
Maynard
Thomas
> The fact that Intel embarked on its giant IA64 project is a clear indication
> that Intel was seing a ceiling come for the 8086's performance. Otherwise it
> would have continued to pump out Pentiums that are ever faster and faster.
Maybe Intel was bothered that others are also allowed to make 8086
processors? And by designing something that is patented, they can
hopefully monopolize the market again?
Apropos patents: I'm sure some folks will be interested that quite some
years ago, when the Atari ST was stil a popular machine, and an 80286
was hip, small boards were sold with a NEC V30 chip and some PLDs that
would be soldered in parallel (except for 3 pins ISTR) with the 68000 in
the Atari.
The whole thing would behave as a PC and was able to switch from 68K to
x68 mode and back. I do not remember if the x86 side ran in a window or
only full screen - I do remember it was at full CPU speed and not only
copy protection hardware.
It was a small German business named 'Sack'. Maybe this can help to
debunk some 'switching between incompatible instruction set' patents...
Thomas
Ketil Z Malde
> The fact that Intel embarked on its giant IA64 project is a clear indication
> that Intel was seing a ceiling come for the 8086's performance. Otherwise it
> would have continued to pump out Pentiums that are ever faster and faster.
I could have sworn the x86 family was doomed when Motorola was
building the modern 68000. Later, when RISC was the buzzword, I was
positively sure that x86 was history.
Mind if I remain skeptic with respect to a performance ceiling? :-)
And, of course, Intel are pumping out faster and faster Pentiums. At
one point, they were probably convinced they could quantum leap those
pesky RISCs with the IA64 architecture though.
> I would think that one problem with an inefficient architecture is that you
> have to compensate with higher fabbing technology.
And the advantage of a commodity architecture is that you can afford
it.
> This would mean that to compete against Alpha and Power, Intel would have to
> spend on new fancier FABs before the others to achieve performance others get
> with cheaper fabbing techniques. So to keep up with Power and Alpha, the 8086
> might have started to cost more and more.
Maybe. I don't think the numbers bear this out, in fact, I think x86
looks better and better for computing or server farms.
> Can the 8086 be used to build systems such as Wildfires?
I'm not aware of anything inherent in the architecture that would
inhibit it. Correct me if I'm wrong.
Peter da Silva
JF Mezei <jfmezei...@videotron.ca> wrote:
> The fact that Intel embarked on its giant IA64 project is a clear indication
> that Intel was seing a ceiling come for the 8086's performance. Otherwise it
> would have continued to pump out Pentiums that are ever faster and faster.
They've been promising a replacement for the x86 every few years since, what,
the early '80s. They keep coming out with new replacements and then abandoning
them. . . iApx432, i860, i960.
--
`-_-' In hoc signo hack, Peter da Silva.
'U` "A well-rounded geek should be able to geek about anything."
-- nic...@esperi.org
Disclaimer: WWFD?
Jan Vorbrueggen
> Well we all know how well ignoring Intel and those stupid underpowered
> CPUs they produced in the 80's worked out for DEC the first time round.
I don't think x86 processors were "underpowered" (stupid, yes, at least in
some things) compared to VAXen. But it was competition from SPARC, MIPS & Co.
that did the VAX and DEC in (in some part - other reasons are a deficient
business model and nonexistent marketing), not competition from x86.
Jan
Jan Vorbrueggen
> The fact that Intel embarked on its giant IA64 project is a clear indication
> that Intel was seing a ceiling come for the 8086's performance. Otherwise it
> would have continued to pump out Pentiums that are ever faster and faster.
>
> I would think that one problem with an inefficient architecture is that you
> have to compensate with higher fabbing technology. This is why the 8086 has
> to have significantly higher close speeds than PowerPC or Alpha to achieve
> similar performance.
I presume you mean clock speeds. If so, you're mostly wrong - historically,
Alphas have been the speed deamons. It is only because Compaq allowed their
lead to slip away that Intel caught up. And with the Pentium 4, Intel clearly
followed Compaq's lead for high-speed designs.
AMD's Hammer will show whether indeed slight tweaks of the architecture to
remove clear bottlenecks (e.g., register pressure) will lead to a processor
that can easily compete with any other approach (e.g., POWER4, EV7) on various
measures. I consider it likely.
> This would mean that to compete against Alpha and Power, Intel would have to
> spend on new fancier FABs before the others to achieve performance others get
> with cheaper fabbing techniques. So to keep up with Power and Alpha, the 8086
> might have started to cost more and more.
IBM is certainly using fabs comparable to Intel's, and indeed in some things
is more advanced (Cu wires, SOI) - and IBM is/was fabbing Alphas for Compaq.
> Can the 8086 be used to build systems such as Wildfires?
Of course. The added value in such systems is in the infrastructure built
around the processor, not the processor itself (within certain limits). EV7
is a different kettle of fish because it integrates much of the glue logic
required on the processor chip, making the job for the builder of large and
hopefully scaleable systems significantly easier.
> While it may be well suited to run video games and gas pump displays,
> is it really well suited to run complex servers ?
Yes.
Jan
Bill Todd
"Jan Vorbrueggen" <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote in
message news:y4lmgg6...@mailhost.neuroinformatik.ruhr-uni-bochum.de...
> JF Mezei <jfmezei...@videotron.ca> writes:
>
> > The fact that Intel embarked on its giant IA64 project is a clear
indication
> > that Intel was seing a ceiling come for the 8086's performance.
Otherwise it
> > would have continued to pump out Pentiums that are ever faster and
faster.
Much more likely it's an indication that Intel foresaw the need for a 64-bit
platform both for long-term competitiveness and for shorter-term higher
margins (which is the reasoning Intel itself has advanced).
> >
> > I would think that one problem with an inefficient architecture is that
you
> > have to compensate with higher fabbing technology. This is why the 8086
has
> > to have significantly higher close speeds than PowerPC or Alpha to
achieve
> > similar performance.
>
> I presume you mean clock speeds. If so, you're mostly wrong -
historically,
> Alphas have been the speed deamons.
JF's point seemed to be that the less efficient architecture required higher
clock speeds to achieve the same level of performance, not that Alpha used
slower clocking than x86s at any given point in time.
It is only because Compaq allowed their
> lead to slip away that Intel caught up. And with the Pentium 4, Intel
clearly
> followed Compaq's lead for high-speed designs.
>
> AMD's Hammer will show whether indeed slight tweaks of the architecture to
> remove clear bottlenecks (e.g., register pressure) will lead to a
processor
> that can easily compete with any other approach (e.g., POWER4, EV7) on
various
> measures. I consider it likely.
Yup. If AMD can pull off what they've described, Hammer could easily be a
far greater threat to everyone than IA64 will ever be.
...
> > While it may be well suited to run video games and gas pump displays,
> > is it really well suited to run complex servers ?
>
> Yes.
Assuming incorporation of good error-checking in the processor itself.
Hammer has some features in this area: are they, and those in the current
Intel x86 offerings, comparable to, say, POWER4 and Alpha in this regard
(and is *anyone* comparable to the z-Series platforms)?
- bill
Bob Koehler
As I recall, it wasn't the hardware on PC's that was so unimpressive,
was was the so-called OS. Good for running Leasure Suit Larry, but
who would seriously try to do real work? Most PC's didn't even ship
with a useable disk backup media.
Sander Vesik
> JF Mezei <jfmezei...@videotron.ca> writes:
>> The fact that Intel embarked on its giant IA64 project is a clear indication
>> that Intel was seing a ceiling come for the 8086's performance. Otherwise it
>> would have continued to pump out Pentiums that are ever faster and faster.
> I could have sworn the x86 family was doomed when Motorola was
> building the modern 68000. Later, when RISC was the buzzword, I was
> positively sure that x86 was history.
> Mind if I remain skeptic with respect to a performance ceiling? :-)
Also, apparently, it was ~ 1994 (if not 3) that intel was seeing that
ceiling coming and started to develop IA64. Since then the ceiling
continue to not arrive...
>> Can the 8086 be used to build systems such as Wildfires?
> I'm not aware of anything inherent in the architecture that would
> inhibit it. Correct me if I'm wrong.
Yes there is - there is no inherent need for x86 in such a system, and
hence the larest ones pretty much are the not-really-well-selling (at
least they were not really well selling before september, iirc) Unisys
32P machines...
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants
--
Sander
+++ Out of cheese error +++
Rupert Pigott
news:9umihe$c...@web.nmti.com...
> the early '80s. They keep coming out with new replacements and then
abandoning
> them. . . iApx432, i860, i960.
I'm pretty sure that the i960 actually has done (or is doing) really well in
the embedded sector - hardly abandoned mate. :)
I know that they tried to push the i860 in that direction, but it never
really made an impact.
Cheers,
Rupert
Rupert Pigott
news:rz7vgfl...@estephe.inria.fr...
> Chip MHz Score
> ------------------------------------
> Pentium 4 2000 699
> Pentium 4 1900 665
> Pentium 4 1800 658
> Pentium 4 1700 636
> Pentium 4 1600 601
> Pentium 4 1500 588
> Pentium 4 1400 551
> Itanium 800 541 <- bet the farm on this one!
Wouldn't comparing it to the P3 be a better comparison ? After all the P4 is
designed to attain huge clock rates, whereas the Itanium is intended to
attain huge IPC.
Cheers,
Rupert
Martin Høyer Kristiansen
Doesn't really matter. The P4 is the highest performing x86 Intel has
produced. And it is only fair to compare best of kin versus best of kin
in the same 0.18um design rule.
Cheers
Martin
Tarjei T. Jensen
Rupert Pigott wrote
>I'm pretty sure that the i960 actually has done (or is doing) really well
in
>the embedded sector - hardly abandoned mate. :)
>
>I know that they tried to push the i860 in that direction, but it never
>really made an impact.
The i860 has been used in embedded applications. E.g. at one time the SGI
graphics system used some of those. My memory says 4 for each graphics card,
but I'm not sure.
greetings,
Stefan Monnier <foo@acm.com>
> Wouldn't comparing it to the P3 be a better comparison ? After all the P4 is
> designed to attain huge clock rates, whereas the Itanium is intended to
> attain huge IPC.
You mean he should remove the `MHz' column from his table?
Agreed: it could delude an inexperienced reader into think that
Intel `just needs to up the clock'.
Stefan
Paul DeMone
Bill Todd wrote:
>
[...]
> JF's point seemed to be that the less efficient architecture required higher
> clock speeds to achieve the same level of performance, not that Alpha used
> slower clocking than x86s at any given point in time.
This reasoning is quite backwards. It is like saying fast airplanes
got that way because they started out with short raked back wings and
the designers found they had to fly fast to get sufficient lift.
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race of EPIC
Kanata, Ontario proportions to put more PRECISION and POWER into
dem...@mosaid.com architectures with MIPSed results but ALPHA's well
pde...@igs.net that ends well.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Sid Ahmed Ali TOUATI
> Please explain why anybody should care if perfomance (as indicated by the
> Spec score) comes from high clock rate or IPC?
in one word : money. That's what we are speaking about and that's the idea behind
Bill Todd post (I think). If you increase your performance by 30 % while doubling
your costs (in $, power consumption, sand, ...), may be that's not the best gain
! The tradeoff cost/performance, that's what we should care about. Other
tradeoffs are also interresting : performance/clean-design,
performance/time-to-market, ... but this is not what the consumer evaluate
easily.
A previous post suggested that increasing the performance by technological issues
(increasing clock rates, transistors density, better cooling techniques, ...)
cannot keep the industrial costs under control for future processors generations.
Better architectural designs are, in my point of view, the best way to keep the
projects of processors designs "viable" economically. Again, this is not an
issue for the end consumer/user.
SAAT
Jan Vorbrueggen
>> JF's point seemed to be that the less efficient architecture required higher
>> clock speeds to achieve the same level of performance, not that Alpha used
>> slower clocking than x86s at any given point in time.
> This reasoning is quite backwards. It is like saying fast airplanes
> got that way because they started out with short raked back wings and
> the designers found they had to fly fast to get sufficient lift.
Quite. A speed demon is that way because his designer decided that was the way
he should be. A point of comparison might be the Pentium III and the Pentium 4
- the latter is the first (in a sense) x86 speed demon, but achieves
comparable performance on many benchmarks to the former or an Athlon running
at substantially lower clock speeds.
Jan
brad.madison
Bill Todd wrote:
>
> While I'd be more than happy if someone considered it worthwhile to
> circulate it to such people, I'm spending more time than I should on this
> already for someone whose only motivation is disgust at Compaq's actions.
> "Think globally, act locally" applies to me in this case, and 'locally' for
> me is just here (though I did consider including an HP newsgroup in the post
> in case they might not realize the kind of upper-management 'talent' they
> may be about to acquire - but had no idea which would be appropriate).
>
> - bill
I've started brwosing comp.os.vms after ignoring it for a couple of
years. Your posts are outstanding.
My question: is the Compaq management (in your opinion) greatly worse
than Digital's management before Compaq bought Digital? I suppose since
Digital WAS committed to Alpha they were some better, but what I think I
recall gave the impression of a bunch of suits who didn't understand the
computer business pretending they were managing a computer company.
There is of course the problem that generically "a bunch of suits who
don't understand the X business pretending they are managing an X
company" applies fairly broadly today.
I suspect Intel management does know Intel's business, so the flaw I
cite isn't truly universal. I also suspect that Intel's management
really lusts for a situation in which there is no significant
competition so that they can manipulate the market to their advantage.
Convincing Compaq to drop Alpha works in that direction. They can use
market share to force down AMD's profits (while lowering their own).
Will it come down to IBM/Motorola vs. Intel?
$150 million/year for Alpha development means a team of about 100.
That's not trivial but it's not huge, either. It sure looks dumb of
Compaq to throw out such a powerful part of their technogy. Of course
without it they don't have to demonstrate management skill for processor
development and don't risk being faulted for mis-manageing Alpha. It
appears that currently they are mismanageing Alpha in the extreme, but
they count on this dropping out of sight.
A good deal of this can be traced to weak managers embracing the notion
of the inevitability of Windows domination of the operating system
market. Strong managers would look for the weaknesses of Windows and
push the advantages of their products that do not suffer from those
weaknesses. They'd also put effort into strengthening their products
even more. A couple of years ago I had the hope that Compaq was shining
Microsoft, and had a major development effort to modernize and improve
VMS. They'd suddenly announce a solution that left Windows in the dust
for reliability and ease of management. I suppose Compaq could be doing
that, but if so they are doing a beautiful job of disguising their true
focus if they are.
Rupert Pigott
news:3C10803A...@inria.fr...
about. Other
> tradeoffs are also interresting : performance/clean-design,
> performance/time-to-market, ... but this is not what the consumer
evaluate
> easily.
Actually clean-design has to be a very important consideration. It's a
nightmare to test something with billions of states and cases, much easier
to test something that's simple. The complexity of a design directly affects
the simulation, testing and part validation processes. All of those have a
significant direct impact on unit cost.
In the case of a developer porting/writing an OS kernel or compiler the
complexity of the architecture will have a direct impact on their
development time. Again this is a significant cost. If they are working on a
complicated architecture they are likely to make mistakes, and this will be
passed further down the chain in the form of software failures - which will
cost more money.
[SNIP]
> Better architectural designs are, in my point of view, the best way to
keep the
> projects of processors designs "viable" economically. Again, this is not
an
> issue for the end consumer/user.
Yup, but that doesn't necessarily mean that *new* architectures are better.
;)
The crossposting on this thread is absolutely gross. If I reply again it
gets axed.
Cheers,
Rupert
Jan Vorbrueggen
> I suspect Intel management does know Intel's business, so the flaw I
> cite isn't truly universal. I also suspect that Intel's management
> really lusts for a situation in which there is no significant
> competition so that they can manipulate the market to their advantage.
If they know enough of antitrust laws, they want to keep a small competitor or
three that have no chance of really eating their lunch, but that will hand on
indefinitely. Makes life so much easier with the FTC and Mario Monti.
> $150 million/year for Alpha development means a team of about 100.
$1.5M per person per year? Seems high by a factor of 3-5 to me.
Jan
Bill Todd
"Rupert Pigott" <Dark...@btinternet.com> wrote in message
news:9uqn09$s59$1...@neptunium.btinternet.com...
...
> The crossposting on this thread is absolutely gross. If I reply again it
> gets axed.
I'll take some, but not all, of the blame for that. The original post in
this thread was intended to rebut the protracted assertions during Terry
Shannon's 'Special IPF-Inside Issue...' thread that all the arguments were
merely matters of opinion. That 'Special IPF-Inside Issue...' post included
the full list above save for comp.unix.tru64 (which seemed to me a
conspicuous omission) and comp.arch (which I included to attempt to gather
less-biased input on some of the more technical issues, as I stated in that
first post).
- bill
Bill Todd
"brad.madison" <brad.m...@mail.tds.net> wrote in message
news:3C10CF59...@mail.tds.net...
...
> My question: is the Compaq management (in your opinion) greatly worse
> than Digital's management before Compaq bought Digital?
My acquaintance with the last years of DEC management is far more tenuous
than that since Compaq took over (and the immediate pre-take-over period),
so others are likely in a better position to make comparisons. Under
Pfeiffer Compaq *seemed* more actively interested in promoting Alpha (and
even made a couple of tentative moves toward promoting VMS) than DEC had
been, and eventually got the acquired DEC sales force to tone down its
efforts to get customers to buy *anything* but VMS. But the post-Pfeiffer
regime has seemed about as eager to sell Windows to anyone who can be
convinced that it will do the job as the DEC 'Affinity' program was.
I suppose since
> Digital WAS committed to Alpha they were some better,
Yes - it's a lot harder to imagine DEC having been able to get away with
axing Alpha than to imagine Compaq surviving (barely) without it.
but what I think I
> recall gave the impression of a bunch of suits who didn't understand the
> computer business pretending they were managing a computer company.
The assertion that Palmer's job was to prepare DEC for acquisition is a lot
more consistent with his actions than any explanation that assumes he was
trying to keep DEC viable.
...
> $150 million/year for Alpha development means a team of about 100.
I think one of the articles I cited mentioned a total of 500 engineers, 200
of whom (the EV8 team? clearly, a lot more than just designers) would
immediately transfer to Intel. Of the rest, some would stay at least a
while at Compaq to complete EV7 and then move to Intel, and likely some
(server types?) would stay at Compaq indefinitely. But those numbers (and
what they mean) could stand clarification.
- bill
brad.madison
Oops. Right.
Peter da Silva
Rupert Pigott <Dark...@btinternet.com> wrote:
> Peter da Silva <pe...@abbnm.com> wrote in message
> news:9umihe$c...@web.nmti.com...
> > the early '80s. They keep coming out with new replacements and then
> abandoning
> > them. . . iApx432, i860, i960.
> I'm pretty sure that the i960 actually has done (or is doing) really well in
> the embedded sector - hardly abandoned mate. :)
They abandoned the general purpose processor version (i960MP?). I mean, the
68000 is still doing well in the embedded market. Heck, I'm using one in my
Visor! But I don't think anyone would argue that the 68000 hasn't been
basically abandoned as a general purpose processor.
Rupert Pigott
Not really... Office space, equipment, test gear, samples, prototypes... All
costs big $$$. I'm sure if they were really good engineers they could do it
all in their heads and etch it out onto silicon using a microscope and a
very fine toothpick. :)
Cheers,
Rupert
Rupert Pigott
> In article <9uo1nt$qh$1...@neptunium.btinternet.com>,
> Rupert Pigott <Dark...@btinternet.com> wrote:
> > Peter da Silva <pe...@abbnm.com> wrote in message
> > news:9umihe$c...@web.nmti.com...
> > > the early '80s. They keep coming out with new replacements and then
> > abandoning
> > > them. . . iApx432, i860, i960.
>
> > I'm pretty sure that the i960 actually has done (or is doing) really
well in
> > the embedded sector - hardly abandoned mate. :)
>
> They abandoned the general purpose processor version (i960MP?). I mean,
the
> 68000 is still doing well in the embedded market. Heck, I'm using one in
my
> Visor! But I don't think anyone would argue that the 68000 hasn't been
> basically abandoned as a general purpose processor.
Uh-oh.
This sounds like an argument with moveable goal posts. As ever it depends on
how you define your terms. Personally I don't feel that 'embedded' excludes
'general purpose', nor do I think that 'general purpose' is a euphemism for
'desktop'.
My idea of a general purpose processor is one which is suited to many
application domains. Clearly the 68K family meets this criteria, as does the
i960 family. If you mean specific implementations of an architecture then
yes, the MC68000 and the i960[insert specific variant here] are both quite
dead. :)
In terms of the MC68000 part being abandoned as a general purpose processor,
yeah, it's firmly dead because it's EOLd. Same goes for the i960MP, however
both architectures have lots of descendents who have lots of bells &
whistles, but I don't really see how that excludes them from 'general
purpose' use. Would you say that a PPC with some PCI bus pins on it is a
non-general purpose processor ?
Cheers,
Rupert
Peter da Silva
Rupert Pigott <Dark...@btinternet.com> wrote:
> This sounds like an argument with moveable goal posts. As ever it depends on
> how you define your terms. Personally I don't feel that 'embedded' excludes
> 'general purpose', nor do I think that 'general purpose' is a euphemism for
> 'desktop'.
OK, s/general purpose processor/replacement for the iApx86 family of CPUs/.
After all, that's the goalpost I was shooting for when I brought it up. When
they dropped the version of the 960 with the general purpose MMU and (IIRC)
FPU, they abandoned that goal.
The point is, this is the fourth time that intel has brought out a new CPU
and said "this will replace the 80x86". Since the 80x86 has not been
replaced, intel has obviously backed away from 3 of their 4 attempts...
and may yet drop the ball on this one as well.
> In terms of the MC68000 part being abandoned as a general purpose processor,
> yeah, it's firmly dead because it's EOLd.
They keep bringing out new Dragonballs.
Anton Ertl
"Rupert Pigott" <Dark...@btinternet.com> writes:
>Peter da Silva <pe...@abbnm.com> wrote in message
>news:9ure63$9...@web.nmti.com...
>> basically abandoned as a general purpose processor.
>
>Uh-oh.
>
>This sounds like an argument with moveable goal posts. As ever it depends on
>how you define your terms. Personally I don't feel that 'embedded' excludes
>'general purpose', nor do I think that 'general purpose' is a euphemism for
>'desktop'.
>
>My idea of a general purpose processor is one which is suited to many
>application domains.
I believe what Peter da Silva meant, without knowing, was a processor
that would be used in a so-called general-purpose computer. I.e., a
computer that is not dedicated to a specific purpose at build time
(unlike embedded systems), but that can be programmed for a variety of
purposes with a variety of software.
Hmm, with this definition the 68k is still there as a general-purpose
processor, because some freely programmable (and thus general-purpose)
PDAs use it; but certainly the 68k has been abandoned for anything
that wants porformance comparable to a current PC (we could use the
term "high-performance" instead of "general-purpose", if that had not
already been used for "scientific/super-computing").
Followups to comp.arch
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Jan Vorbrueggen
> After all, that's the goalpost I was shooting for when I brought it up. When
> they dropped the version of the 960 with the general purpose MMU and (IIRC)
> FPU, they abandoned that goal.
I never had the impression Intel wanted to use the i960 to substitute x86 -
is there a public declaration by them on that intent? While with IA64, that
intent was very clear and consistent right from the beginning - even to the
point of re-directing the P7 (IIRC) designation for that, instead of for the
next-incarnation x86.
Jan
Jan Vorbrueggen
> > $1.5M per person per year? Seems high by a factor of 3-5 to me.
> Not really... Office space, equipment, test gear, samples, prototypes... All
> costs big $$$. I'm sure if they were really good engineers they could do it
> all in their heads and etch it out onto silicon using a microscope and a
> very fine toothpick. :)
They don't run a fab anymore, you know.
My general rule-of-thumb is twice to thrice the annual salary of the employee
to get at full costs. At lot of companies are just profitable with a factor of
two, but a thing such as a server design and testing centre might need a
little more - but not 7 times more.
Jan
Ketil Z Malde
> The point is, this is the fourth time that intel has brought out a new CPU
> and said "this will replace the 80x86". Since the 80x86 has not been
> replaced, intel has obviously backed away from 3 of their 4 attempts...
> and may yet drop the ball on this one as well.
I just can't wait to buy a laser printer with an Itanium in it!
(To hook up to my 8GHz Pentium VI, of course. Or should that be
Athlon VI? :-)
Larry Kilgallen
> "Rupert Pigott" <Dark...@btinternet.com> writes:
>
>> > $1.5M per person per year? Seems high by a factor of 3-5 to me.
>> Not really... Office space, equipment, test gear, samples, prototypes... All
>> costs big $$$. I'm sure if they were really good engineers they could do it
>> all in their heads and etch it out onto silicon using a microscope and a
>> very fine toothpick. :)
>
> They don't run a fab anymore, you know.
Correct. They pay fab charges to outside companies, presumably including
for test runs directly related to the work of the chip designers.
Robert Harley
See this: http://news.cnet.com/news/0-1003-200-8145128.html?tag=owv
------------------------------------------------------------------------------
In the third quarter--the first full quarter of Itanium
sales--manufacturers sold just $13.7 million worth of servers
containing the chip, which comes to less than 500 servers, according
to market researcher IDC.
------------------------------------------------------------------------------
And people thought Alpha sales were low?
R
.-. .-.
/ \ .-. Robert...@argote.ch .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' http://argote.ch/ `-'
Peter da Silva
Jan Vorbrueggen <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
> pe...@abbnm.com (Peter da Silva) writes:
> > After all, that's the goalpost I was shooting for when I brought it up. When
> > they dropped the version of the 960 with the general purpose MMU and (IIRC)
> > FPU, they abandoned that goal.
> I never had the impression Intel wanted to use the i960 to substitute x86 -
> is there a public declaration by them on that intent?
The impression I got from their original positioning of both the 860 and
960 was that the x86 had limited headroom, and these devices were going to
be there when it topped out.
I will admit that the 960 got relegated fairly quickly to the embedded market,
but that always seemed to be due to 860-960 team rivalry after they were both
already out.
Peter da Silva
Ketil Z Malde <ke...@apal.ii.uib.no> wrote:
> pe...@abbnm.com (Peter da Silva) writes:
> > The point is, this is the fourth time that intel has brought out a new CPU
> > and said "this will replace the 80x86". Since the 80x86 has not been
> > replaced, intel has obviously backed away from 3 of their 4 attempts...
> > and may yet drop the ball on this one as well.
> I just can't wait to buy a laser printer with an Itanium in it!
Just so long as they don't try using the beggars in Netapps.
John F Carr
>
>> The point is, this is the fourth time that intel has brought out a new CPU
>> and said "this will replace the 80x86". Since the 80x86 has not been
>> replaced, intel has obviously backed away from 3 of their 4 attempts...
>> and may yet drop the ball on this one as well.
>
>I just can't wait to buy a laser printer with an Itanium in it!
That sounds like an excellent application: laser printers need heating
elements.
--
John Carr (j...@mit.edu)