Intel's 64-bit strategy
Russell Wallace
A few years ago when IA64 was first announced, I said "Great! Now we
can put a good architecture on 90% of desktops to replace this x86
mess!"
When the performance figures for Merced started coming out I said "Oh
well, strike one, but I'm sure the next version will be better - if
they can make x86 run fast they can make anything run fast".
But the performance estimates for McKinley keep being revised
downwards and at this point it looks like a real possibility that IA64
is an irretrievable disaster and there's nothing that can be done to
make it competitive.
If that happens, it's dead and the only question is how long before
the life support machine is turned off. It'll be hard enough to
transition from x86 to a superior architecture; no amount of marketing
will make the world transition to an inferior one. (It's not just
performance either - heat dissipation is a serious problem with
today's Pentiums and getting worse every year; Itanium's big jump
there might be a showstopper by itself.)
That leaves Intel with a problem - in the long run, they have to come
up with a 64 bit story or cede the high ground to AMD and ultimately
be replaced by them.
As luck would have it, there's actually a solution at hand. Alpha is
the undisputed performance leader despite the meager trickle of
resources it's been getting, and has the nontrivial advantage of being
a proven established architecture with good quality compilers,
operating systems, x86 emulator and even a Windows port already
written. And as of last summer... Intel own Alpha.
Of course a switch at this point would be a public relations mess...
but the way things are going now, there's going to be a public
relations mess anyway, and the longer it's left the worse it's going
to be. Fortunately, people get over that sort of thing; there'll be a
big furore about it for awhile, then everyone will forget about IA64
and get on with their lives.
So - at least in this armchair general's opinion ^.^ - what Intel
needs to do is start getting Alpha products out ASAP, get Microsoft to
pick up the Alpha version of Windows again, and discontinue IA64 as
gracefully as possible.
Now, maybe they're already doing this in secret, in which case kudos
to them. If not - well, some Intel people read this newsgroup - if any
of you want to take this idea and follow up on it, be my guest.
Happy New Year everyone!
--
"Pity for the guilty is treachery to the innocent."
mailto:rwal...@esatclear.ie
http://www.esatclear.ie/~rwallace
Eric Smith
> That leaves Intel with a problem - in the long run, they have to come
> up with a 64 bit story or cede the high ground to AMD and ultimately
> be replaced by them.
>
> As luck would have it, there's actually a solution at hand. Alpha is
> the undisputed performance leader despite the meager trickle of
> resources it's been getting, and has the nontrivial advantage of being
> a proven established architecture with good quality compilers,
> operating systems, x86 emulator and even a Windows port already
> written. And as of last summer... Intel own Alpha.
I don't know anything about Intel's corporate culture, but at many large
companies, any employee that suggested that the company's major
direction was a disaster AFTER the company had spent hundreds of
millions of dollars on it, but BEFORE it had actually crashed and
burned, would be branded as "not a team player". Such an employee would
be ignored, demoted, or fired, no matter how compelling his or her
arguments were.
I guestimate that the probability of Intel replacing IA64 with something
else BEFORE it has had a chance to fail in the marketplace to be
a slightly less than epsilon.
Rumor has it that they are working on their own 64-bit x86, which I
suspect will be positioned "inbetween" the Pentium IV and the IA64.
Unless they screw that up too, it seems quite likely that it will
effectively replace IA64 just as the x86 replaced the 8800/iAPX 432.
If AMD is wildly successful with x86-64 (Hammer), and Intel's 64-bit x86
is not, it would be quite amusing if Intel eventually had to clone AMD's
architecture.
cjt
Yes, it would. Let's hope AMD has some good patent attorneys.
Jeremy Fox
: Rumor has it that they are working on their own 64-bit x86, which I
: suspect will be positioned "inbetween" the Pentium IV and the IA64.
Any more info on this rumor, or is that all that is known?
--
------------------------
Jeremy T. Fox
jer...@stanford.edu
del cecchi
"Russell Wallace" <r...@eircom.net> wrote in message
news:3c30d798....@news.eircom.net...
trolling, trolling, trolling. Keep those alphaphiles rolling. eeehaw
Assaf Sarfati
NGs, and I'd like to put in my $0.02 worth:
As a "power user" of a PC (running Windows, but using heavy-duty CAD S/W),
what I'd like best is a PC which allows my CAD S/W enough performance and
memory space to run (I am now constantly running out of memory space)
WITHOUT forcing me to move to a non-standard OS or applications (sorry,
but that's MS-Windows, whatever Linux, Unix or Mac guys&gals say - just see
market-share).
For example: I use MS-Word (at least for writing/reading specs), and I don't
want to use something "almost like" Word, which other people (who don't need
or want 64-bit workstations) can't read/write.
Even if MS ports MS-Word to any of the 64-bit CPUs, why should I have to use
a different version (probably not as up-to-date as their main-line)? it gets
even worse for other utility S/W; why should someone who wrote a neat shareware
program bother porting it to an exotic OS?
The bottom line is: 64-bit is great, but backwards compatibility is even
greater. This is something that Intel should know - they've kept S/W
compatibility for ages (I'm sure that their engineers howled in agony every
time a new processor project was started and they were told "must run DOS
programs!").
On that basis, I believe that the only reasonable replacement to x86 is x86-64
(and if I am wrong, a few years from now I will eat my crystal ball).
Jason Ozolins
> Even if MS ports MS-Word to any of the 64-bit CPUs, why should I have to use
> a different version (probably not as up-to-date as their main-line)? it gets
> even worse for other utility S/W; why should someone who wrote a neat shareware
> program bother porting it to an exotic OS?
>
> The bottom line is: 64-bit is great, but backwards compatibility is even
> greater. This is something that Intel should know - they've kept S/W
> compatibility for ages (I'm sure that their engineers howled in agony every
> time a new processor project was started and they were told "must run DOS
> programs!").
>
> On that basis, I believe that the only reasonable replacement to x86 is x86-64
> (and if I am wrong, a few years from now I will eat my crystal ball).
Well, Transmeta have demonstrated a chip which offers acceptable x86
performance (especially as contrasted with the x86 performance offered
by Itanium), and yet has a completely non-x86 native architecture.
Transmeta surely ought to be able to turn out a processor which does
both x86 JIT compilation, and JIT compilation for some generic 64-bit
RISC architecture; it's just a question of how fast the resulting
processor executes code in the 64-bit mode. I seem to recall rumours
that Transmeta were originally targeting high performance rather than
the low power consumption they ended up emphasizing in their current
products, but if they had had Itanium-sized power (and money) budgets,
this might have turned out differently... :-)
And for complete backward compatibility, run a Windows sandbox in a
VMware-style virtual machine, which eliminates the "x86 DLLs tromping
over native DLLs" problem that others have mentioned regarding Digital's
x86 compatibility under Windows NT for Alpha. If all you care about in
the x86 space is office automation and shareware utilities, the
performance of this approach should be acceptable, certainly better than
I imagine x86 performance on Itanium's successors will be.
Nick Maclaren
Assaf Sarfati <assaf_...@yahoo.com> wrote:
>
>The bottom line is: 64-bit is great, but backwards compatibility is even
>greater. This is something that Intel should know - they've kept S/W
>compatibility for ages (I'm sure that their engineers howled in agony every
>time a new processor project was started and they were told "must run DOS
>programs!").
Deja vue. That is exactly what was said about the System/370
and IBM MVT/MVS back in the 1970s. Those new-fangled systems using
different hardware and operating systems never had a chance.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Nick Maclaren
Eric Smith <eric-no-s...@brouhaha.com> wrote:
>
>I don't know anything about Intel's corporate culture, but at many large
>companies, any employee that suggested that the company's major
>direction was a disaster AFTER the company had spent hundreds of
>millions of dollars on it, but BEFORE it had actually crashed and
>burned, would be branded as "not a team player". Such an employee would
>be ignored, demoted, or fired, no matter how compelling his or her
>arguments were.
That is correct, and the vindictiveness would increase as the employee's
perspectiveness became more apparent, reaching a peak after he had been
proved right in all particulars - and ESPECIALLY if he had pointed out
an alternative strategy that was rejected but successfully taken up by
another organisation.
Been there - done that :-(
>I guestimate that the probability of Intel replacing IA64 with something
>else BEFORE it has had a chance to fail in the marketplace to be
>a slightly less than epsilon.
Not so. There is a management imbecility that takes the form of
deciding that a troubled project must be uncreated, irrespective of
whether it overcomes its troubles. Therefore ANY decision taken must
be reversed, and the wisdom of doing so may not be questioned. This
is usually an indication that the company will collapse shortly
thereafter. Witness ICL on George versus VME (or whatever it was),
and similar examples.
I don't think that Intel have reached that state.
Rupert Pigott
news:Yo9Y7.3710$ag1.1...@eagle.america.net...
>
> "Russell Wallace" <r...@eircom.net> wrote in message
> news:3c30d798....@news.eircom.net...
> > Hi all,
> >
> > A few years ago when IA64 was first announced, I said "Great! Now we
> > can put a good architecture on 90% of desktops to replace this x86
> > mess!"
> >
> > When the performance figures for Merced started coming out I said "Oh
> > well, strike one, but I'm sure the next version will be better - if
> > they can make x86 run fast they can make anything run fast".
[SNIPETY SNIP]
> > "Pity for the guilty is treachery to the innocent."
> > mailto:rwal...@esatclear.ie
> > http://www.esatclear.ie/~rwallace
>
> trolling, trolling, trolling. Keep those alphaphiles rolling. eeehaw
Doesn't this guy remind you of the 2 + 2 spam-bot ?
Cheers,
Rupert
Paul DeMone
Rupert Pigott wrote:
[...]
> > > "Pity for the guilty is treachery to the innocent."
> > > mailto:rwal...@esatclear.ie
> > > http://www.esatclear.ie/~rwallace
> >
> > trolling, trolling, trolling. Keep those alphaphiles rolling. eeehaw
>
> Doesn't this guy remind you of the 2 + 2 spam-bot ?
Del is not that bad. He is just sad that in a few more years all
threads on comp.arch won't end up talking about Alpha and he will
have one last thing to complain about. :-)
As far as the guy before who thought Alpha will be revived, it reminds
me of a black comedian I saw on the tube long time ago. He said something
along the lines of "Alright, I have a special message to all the white
people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
over it.
--
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! =-----
Chris Morgan
> As far as the guy before who thought Alpha will be revived, it reminds
> me of a black comedian I saw on the tube long time ago. He said something
> along the lines of "Alright, I have a special message to all the white
> people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
> over it.
There's a song by Living Colour by that title also :
"Picture a rotten elvis,
shopping for fresh fruit
You can't 'cause
Chorus:
Elvis is dead
Elvis is dead
Elvis is dead
Elvis is dead
Elvis is dead"
etc
We could change the words :
"Alpha was a good performer,
on stage he was electrifying" etc.
--
Chris Morgan <cm at mihalis.net> http://www.mihalis.net
Temp sig. - Enquire within
Douglas Siebert
You might be using what you call "high end CAD software" but if you
haven't run into any problem with the address limits inherent in 32 bit
CPUs you aren't really a high end CAD user. All the major CAD vendors
(at least on the EE side, it wasn't as big of a problem as quickly on the
ME side) did 64 bit ports as quickly as possible. Solaris even lost some
of the very high end CAD market that needed 64 bits sooner than Sun was
able to provide it. When you consider the investment in the software
involved, even the high end Unix workstation's cost is fairly minor. The
cost of a PC is lost in the noise. They'd all get a PC alongside their
workstations if they wanted one, there has never been a requirement to
have everything on a single machine.
While I agree with you that x86-64 will be a better alternative than
IA-64, at least in the short/medium term, I find your reasoning rather
suspect. Why you think the IA-64 Office port will be inferior or behind
the IA-32 one? They will both be for Windows, after all. The Mac
version of Office is up to date -- in fact, since it runs on a different
release schedule than the Windows version, it is sometimes ahead of the
Windows version. It isn't like anyone every eagerly awaits the latest
Office version or feels left out if they are one rev behind. Or are you
one of those people who always upgrades immediately, and have been
running Office XP since June?
--
Douglas Siebert dsie...@excisethis.khamsin.net
He who laughs last thinks slowest.
John Dallman
Fox) wrote:
> Eric Smith <eric-no-s...@brouhaha.com> wrote:
> : Rumor has it that they are working on their own 64-bit x86, which I
> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
> Any more info on this rumor, or is that all that is known?
It's been a rumour for some years, but I've never managed to track down
anything real on it. If it exists, then one would expect them to keep it
very secret.
---
John Dallman j...@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"
Toon Moene
> The
> cost of a PC is lost in the noise. They'd all get a PC alongside their
> workstations if they wanted one, there has never been a requirement to
> have everything on a single machine.
The niche market I live in there aren't even any PC's for
scientists/engineers anymore. Everyone has a Linux PC + VMWare on
his/her desk.
Granted, this is in weather forecasting - the desk-top processing of
which (mostly graphical renderings of results coming out of
Cray/Fujitsu/NEC etc. vector processors) is well within the realm of
32-bit addressing.
--
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)
Bill Todd
"Paul DeMone" <pde...@igs.net> wrote in message
news:3C31F75B...@igs.net...
>
>
> Rupert Pigott wrote:
> [...]
> > > > "Pity for the guilty is treachery to the innocent."
> > > > mailto:rwal...@esatclear.ie
> > > > http://www.esatclear.ie/~rwallace
> > >
> > > trolling, trolling, trolling. Keep those alphaphiles rolling. eeehaw
> >
> > Doesn't this guy remind you of the 2 + 2 spam-bot ?
>
> Del is not that bad. He is just sad that in a few more years all
> threads on comp.arch won't end up talking about Alpha and he will
> have one last thing to complain about. :-)
But his line above *was* at least funny. And I must admit that it was not
entirely clear to me who the antecedent of 'this guy' was meant to be...
>
> As far as the guy before who thought Alpha will be revived, it reminds
> me of a black comedian I saw on the tube long time ago. He said something
> along the lines of "Alright, I have a special message to all the white
> people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
> over it.
I think the analogy is misplaced. It might apply to any suggestion that
*Compaq* revive Alpha, but that was not the suggestion presented.
Dismissing the idea that Intel would embrace Alpha, while certainly
consistent with all conventional wisdom, really should be accompanied by a
suggested (and more credible) *alternative* option for Intel in the face of
IA64's quite-possible collapse. The x86-64 Intel Oregon project would
qualify, of course, but only if accompanied by some evidence that it was
other than mythical.
- bill
del cecchi
"Bill Todd" <bill...@metrocast.net> wrote in message
news:CRqY7.479745$8q.40...@bin2.nnrp.aus1.giganews.com...
spambot. Not the worst thing I have ever been called. But he could
have been talking about the original poster, for sure. Anyway, didn't
we just finish about a two week thread of "Intel bought Alpha to replace
Itanium/McKinley" ?
When they decide to do it, would somebody email me a few days before? I
have some stock transactions to make. :-)
The question of what kind of quick and dirty x86 offshoot Intel could do
to fight off AMD in the event of massive disinterest in IA64 is
certainly interesting. Certainly Intel owns the low end server market
with x86, AMD isn't in the running.
del cecchi
Rupert Pigott
on... :)
Bill Todd <bill...@metrocast.net> wrote in message
news:CRqY7.479745$8q.40...@bin2.nnrp.aus1.giganews.com...
>
> "Paul DeMone" <pde...@igs.net> wrote in message
> news:3C31F75B...@igs.net...
> >
> >
> > Rupert Pigott wrote:
> > [...]
> > > > > "Pity for the guilty is treachery to the innocent."
> > > > > mailto:rwal...@esatclear.ie
> > > > > http://www.esatclear.ie/~rwallace
> > > >
> > > > trolling, trolling, trolling. Keep those alphaphiles rolling.
eeehaw
> > >
> > > Doesn't this guy remind you of the 2 + 2 spam-bot ?
> >
> > Del is not that bad. He is just sad that in a few more years all
> > threads on comp.arch won't end up talking about Alpha and he will
> > have one last thing to complain about. :-)
>
> But his line above *was* at least funny. And I must admit that it was not
> entirely clear to me who the antecedent of 'this guy' was meant to be...
>
> >
> > As far as the guy before who thought Alpha will be revived, it reminds
> > me of a black comedian I saw on the tube long time ago. He said
something
> > along the lines of "Alright, I have a special message to all the white
> > people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
> > over it.
>
> I think the analogy is misplaced. It might apply to any suggestion that
> *Compaq* revive Alpha, but that was not the suggestion presented.
[SNIP]
Paul DeMone
Rupert Pigott wrote:
>
> Err, actually I screwed up... I was referring to the guy Del was commenting
> on... :)
I knew that all along, I was just having a bit of fun at Del's
expense. He's a trooper and will get over it. :-)
Assaf Sarfati
> assaf_...@yahoo.com (Assaf Sarfati) writes:
> You might be using what you call "high end CAD software" but if you
> haven't run into any problem with the address limits inherent in 32 bit
> CPUs you aren't really a high end CAD user. All the major CAD vendors
> (at least on the EE side, it wasn't as big of a problem as quickly on the
> ME side) did 64 bit ports as quickly as possible. Solaris even lost some
> of the very high end CAD market that needed 64 bits sooner than Sun was
> able to provide it. When you consider the investment in the software
> involved, even the high end Unix workstation's cost is fairly minor. The
> cost of a PC is lost in the noise. They'd all get a PC alongside their
> workstations if they wanted one, there has never been a requirement to
> have everything on a single machine.
>
> While I agree with you that x86-64 will be a better alternative than
> IA-64, at least in the short/medium term, I find your reasoning rather
> suspect. Why you think the IA-64 Office port will be inferior or behind
> the IA-32 one? They will both be for Windows, after all. The Mac
> version of Office is up to date -- in fact, since it runs on a different
> release schedule than the Windows version, it is sometimes ahead of the
> Windows version. It isn't like anyone every eagerly awaits the latest
> Office version or feels left out if they are one rev behind. Or are you
> one of those people who always upgrades immediately, and have been
> running Office XP since June?
The "pretty high-end" CAD SW I'm using is HDL simulation, synthesis and FPGA
Place&Route tools. Recent FPGAs have become large enough to build a respectable
SOC on them, which is what I'm doing. I am constantly running out of memory in
the P&R SW; I also have problems in gate-level simulations.
I haven't updated my OS/Office etc. recently and I have no intention of doing
it any time soom, since MS seems to concentrate on the dumb, know-nothing
(probably non-existent) user. Each version becomes less friendly to a
person who wants the SW to work the way he prefers instead of the way MS
*thinks* he should work (more about that in a separate, 3000-line rant).
What I'm saying is: I like, very much, the convenience of using "standard"
SW for the rest of my work; I also like the fact that the CAD SW I'm using
is pretty low-cost since it's also intended for low- to mid-range designs
and budget.
Sure, if I had to, I'd learn to use Unix/Linux and its applications; if I
had to, I'd pay for the 64-bit versions of the SW. But I like the fact that
I don't have to, most of the time.
The Unix versions of the CAD SW I'm using (HDL simulator, synthesis tools
etc.) are *much* more expensive than the PC versions.
Russell Wallace
wrote:
>trolling, trolling, trolling. Keep those alphaphiles rolling. eeehaw
Trollee will eat you later!! Trollee kill!!
That said - no, I really wasn't trolling. In case you're wondering,
that wasn't "Alpha must survive!" - that won't happen unless someone
finds a business case for it, irrespective of the technical merits.
That was primarily: Oops, IA64 seems to be a disaster irretrievable
even with Intel's resources. So what will they do now?
Possibility: use a proven performance leader that they just bought.
Alternative: as correctly suggested, they might have their own x86-64
in the pipeline. Maybe that will work.
Or maybe they'll end up copying AMD. I guess we'll see how things go.
Nick Maclaren
del cecchi <dce...@msn.com> wrote:
>
>The question of what kind of quick and dirty x86 offshoot Intel could do
>to fight off AMD in the event of massive disinterest in IA64 is
>certainly interesting. Certainly Intel owns the low end server market
>with x86, AMD isn't in the running.
"Intel is currently occupying", please! That situation could change
overnight, and is predicated primarily on the OEMs and application
vendors changing their primary allegiance. Few buyers of such things
know even how to find out what architecture their system is running.
Brig Campbell
"Jeremy Fox" <jer...@Stanford.EDU> wrote in message
news:a0r6ev$565$1...@usenet.Stanford.EDU...
> Eric Smith <eric-no-s...@brouhaha.com> wrote:
>
> : Rumor has it that they are working on their own 64-bit x86, which I
> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
>
> Any more info on this rumor, or is that all that is known?
http://213.219.40.69/14120102.htm
Apology: Intel's X86-64 Skunkworks
-brig
@stanford.edu
Douglas Siebert
>In article <a0r6ev$565$1...@usenet.Stanford.EDU>, jer...@Stanford.EDU (Jeremy
>Fox) wrote:
>> Eric Smith <eric-no-s...@brouhaha.com> wrote:
>> : Rumor has it that they are working on their own 64-bit x86, which I
>> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
>> Any more info on this rumor, or is that all that is known?
>It's been a rumour for some years, but I've never managed to track down
>anything real on it. If it exists, then one would expect them to keep it
>very secret.
The question is whether there is/ever was anything behind this rumor. If
there never was such a thing and Intel never even considered it, the
rumors would still exist because it makes logical sense for Intel to do
this. Of course, they have to overcome the resistance of the IA-64
people who would be very much against it, but I'll bet there is still a
bit of NIH sentiment within Intel regarding IA-64 in some places. x86
may be ugly, but its all theirs :) For AMD to come along to take over
the future direction of the ISA would be very unpalatable to a lot of
people within Intel.
Sander Vesik
> In article <r8sY7.3916$ag1.1...@eagle.america.net>,
> del cecchi <dce...@msn.com> wrote:
>>
>>The question of what kind of quick and dirty x86 offshoot Intel could do
>>to fight off AMD in the event of massive disinterest in IA64 is
>>certainly interesting. Certainly Intel owns the low end server market
>>with x86, AMD isn't in the running.
> "Intel is currently occupying", please! That situation could change
> overnight, and is predicated primarily on the OEMs and application
> vendors changing their primary allegiance. Few buyers of such things
> know even how to find out what architecture their system is running.
But this will not happen before the dual athlon MB-s are about 2x more
widespread, but seeing as ASUS has finally got there, it might just be
a matter of months.
Far more threatening to Intel should sound the fact that AMD is seriously
at its SMP (and possibly Xeon) system cashcow - an area where intel hasn't
faced competition before. All IMVHO, of course...
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email: nm...@cam.ac.uk
> Tel.: +44 1223 334761 Fax: +44 1223 334679
--
Sander
+++ Out of cheese error +++
Alex Colvin
>>> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
>>> Any more info on this rumor, or is that all that is known?
I would be surprised if they *didn't* have such a project. Not only
should they guard against unforseen disaster, but they should also prepare
to attack AMD in its own niche.
Going forward, how hard is it for IA-64 to emulate Hammer?
--
mac the naïf
Nick Maclaren
Sander Vesik <san...@haldjas.folklore.ee> wrote:
>Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>> In article <r8sY7.3916$ag1.1...@eagle.america.net>,
>> del cecchi <dce...@msn.com> wrote:
>>>
>>>The question of what kind of quick and dirty x86 offshoot Intel could do
>>>to fight off AMD in the event of massive disinterest in IA64 is
>>>certainly interesting. Certainly Intel owns the low end server market
>>>with x86, AMD isn't in the running.
>
>> "Intel is currently occupying", please! That situation could change
>> overnight, and is predicated primarily on the OEMs and application
>> vendors changing their primary allegiance. Few buyers of such things
>> know even how to find out what architecture their system is running.
>
>But this will not happen before the dual athlon MB-s are about 2x more
>widespread, but seeing as ASUS has finally got there, it might just be
>a matter of months.
Yes, quite. "Overnight" in this context is from the viewpoint of
someone located at the North Pole :-)
>Far more threatening to Intel should sound the fact that AMD is seriously
>at its SMP (and possibly Xeon) system cashcow - an area where intel hasn't
>faced competition before. All IMVHO, of course...
That is the very context that the thread is discussing! While AMD
might make inroads into Intel's monopoly of the very small server
market, there is a chance that it will actually elbow the IA-64
line into second place. And it is unclear that the IA-64 line will
be competitive except as a near-monopoly.
An obvious stepping stone to that is the SMP IA-32 market, which
is currently solidly Intel. But its importance is as a stepping
stone and not as anything that AMD is likely to achieve in the time
before before AMD replaces its IA-32 line by the x86-64 one in that
segment (c. 18 months, at my guess).
Intel is in no immediate danger of a cash meltdown, but is in a very
serious danger of being sidelined in its flagship architecture the
way that Motorola was.
Nick Maclaren
Dead easy. No problem at all. Intel already has 95% of the code
written and running, because x86-64 is a minor upgrade to IA-32
as far as those aspects go.
Of course, it would run like a drain, which rather negates the
point :-)
Bernd Paysan
> As far as the guy before who thought Alpha will be revived, it reminds
> me of a black comedian I saw on the tube long time ago. He said something
> along the lines of "Alright, I have a special message to all the white
> people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
> over it.
Didn't Intel already announce that the result of the Alpha team will be
a IPF ("Intel Performance Failure") "with Alpha technology"? What Alpha
technology do they mean they need to buy or could be included in IA-64?
They have a SMT product already, so they don't need to wait for results
from the EV8 team for that knowledge. They might require expertise in
those stuff Pat Gelsinger claims AMD doesn't have (for the "real big
machines", e.g. more than 2 Itanic CPUs ;-), e.g. some help how to
include the memory controller in the CPU, and how to make a
point-to-point interconnect network for a CC/NUMA architecture.
The result might not necessary be a real Alpha CPU (just to not lose the
face), but it is not so far-fetched that Intel might abandon the IA-64
architecture. The only project I'm aware that's being worked on with
IA-64 instruction set is the McKinley, the follow-up projects have been
scrapped and replaced by shrinked McKinleys. Customer support is not an
issue with some hundred Itanic machines sold.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Nick Maclaren
Bernd Paysan <bernd....@gmx.de> wrote:
>Paul DeMone schrieb:
>> As far as the guy before who thought Alpha will be revived, it reminds
>> me of a black comedian I saw on the tube long time ago. He said something
>> along the lines of "Alright, I have a special message to all the white
>> people in the crowd tonight. Listen carefully ok? ELVIS IS DEAD! Get
>> over it.
>
>Didn't Intel already announce that the result of the Alpha team will be
>a IPF ("Intel Performance Failure") "with Alpha technology"? What Alpha
>technology do they mean they need to buy or could be included in IA-64?
>They have a SMT product already, so they don't need to wait for results
>from the EV8 team for that knowledge. They might require expertise in
>those stuff Pat Gelsinger claims AMD doesn't have (for the "real big
>machines", e.g. more than 2 Itanic CPUs ;-), e.g. some help how to
>include the memory controller in the CPU, and how to make a
>point-to-point interconnect network for a CC/NUMA architecture.
One could argue how much of an SMT system the Pentium 4 really is,
but let us assume that it is one. The problem is merging that
technology with the IA-64 design, and it would be a nightmare.
My guess is that they DON'T want the EV8 technology, but they DO
want the skilled people - I should dearly love to know how long
the period is before those people can leave Intel without penalty,
but have not heard.
>The result might not necessary be a real Alpha CPU (just to not lose the
>face), but it is not so far-fetched that Intel might abandon the IA-64
>architecture. The only project I'm aware that's being worked on with
>IA-64 instruction set is the McKinley, the follow-up projects have been
>scrapped and replaced by shrinked McKinleys. Customer support is not an
>issue with some hundred Itanic machines sold.
To be fair to Intel, there are some thousands (perhaps even tens of
thousands) in OEMs and software houses, who are actually more important
than end customers to Intel's future. In Intel's heyday, it could
afford to make changes that would cost them serious money, but now
it is in a slightly more precarious boat.
George William Herbert
>>>> : Rumor has it that they are working on their own 64-bit x86, which I
>>>> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
>>>> Any more info on this rumor, or is that all that is known?
>
>I would be surprised if they *didn't* have such a project. Not only
>should they guard against unforseen disaster, but they should also prepare
>to attack AMD in its own niche.
One of the lessons that I've learned bluntly in industry,
big and small, and which Christensen's "The Innovators Dillemma"
generalizes, is that companies rarely have such disruptive
alternate projects in progress. You would think that covering
bases would be smart, but there's huge resistance to disrupt your
own plans and current product stream with new ideas.
There are companies which are exceptions to this, either by
accident or design having the sort of self-competing behaviour
that lets that sort of R&D go on. But they're not the rule,
and Intel's recent public behaviour indicates a high degree
of GroupThink internally.
That does not amount to "I know for a fact that they haven't";
but contrary to your statement, there is very good reason to
be suprised if they do have such a project...
-george william herbert
gher...@retro.com
Nick Maclaren
George William Herbert <gher...@gw.retro.com> wrote:
>Alex Colvin <al...@world.std.com> wrote:
>>>>> : Rumor has it that they are working on their own 64-bit x86, which I
>>>>> : suspect will be positioned "inbetween" the Pentium IV and the IA64.
>>>>> Any more info on this rumor, or is that all that is known?
>>
>>I would be surprised if they *didn't* have such a project. Not only
>>should they guard against unforseen disaster, but they should also prepare
>>to attack AMD in its own niche.
>
>One of the lessons that I've learned bluntly in industry,
>big and small, and which Christensen's "The Innovators Dillemma"
>generalizes, is that companies rarely have such disruptive
>alternate projects in progress. You would think that covering
>bases would be smart, but there's huge resistance to disrupt your
>own plans and current product stream with new ideas.
Partly because they don't know how to handle the management of a
project that will probably go nowhere - staff morale is a very hard
thing to maintain and, without morale, you get poor results and
even leaks.
>There are companies which are exceptions to this, either by
>accident or design having the sort of self-competing behaviour
>that lets that sort of R&D go on. But they're not the rule,
>and Intel's recent public behaviour indicates a high degree
>of GroupThink internally.
HP did that with PA-RISC after having announced its IA-64 strategy.
But that was the 'old' HP - I wonder if the current CEO would do
as well?
Jay Braun
> Hi all,
>
> A few years ago when IA64 was first announced, I said "Great! Now we
> can put a good architecture on 90% of desktops to replace this x86
> mess!"
>
> When the performance figures for Merced started coming out I said "Oh
> well, strike one, but I'm sure the next version will be better - if
> they can make x86 run fast they can make anything run fast".
>
> downwards and at this point it looks like a real possibility that IA64
> is an irretrievable disaster and there's nothing that can be done to
> make it competitive.
>
> If that happens, it's dead and the only question is how long before
> the life support machine is turned off. It'll be hard enough to
> transition from x86 to a superior architecture; no amount of marketing
> will make the world transition to an inferior one. (It's not just
> performance either - heat dissipation is a serious problem with
> today's Pentiums and getting worse every year; Itanium's big jump
> there might be a showstopper by itself.)
>
> That leaves Intel with a problem - in the long run, they have to come
> up with a 64 bit story or cede the high ground to AMD and ultimately
> be replaced by them.
>
> As luck would have it, there's actually a solution at hand. Alpha is
> the undisputed performance leader despite the meager trickle of
> resources it's been getting, and has the nontrivial advantage of being
> a proven established architecture with good quality compilers,
> operating systems, x86 emulator and even a Windows port already
> written. And as of last summer... Intel own Alpha.
>
> Of course a switch at this point would be a public relations mess...
> but the way things are going now, there's going to be a public
> relations mess anyway, and the longer it's left the worse it's going
> to be. Fortunately, people get over that sort of thing; there'll be a
> big furore about it for awhile, then everyone will forget about IA64
> and get on with their lives.
>
> So - at least in this armchair general's opinion ^.^ - what Intel
> needs to do is start getting Alpha products out ASAP, get Microsoft to
> pick up the Alpha version of Windows again, and discontinue IA64 as
> gracefully as possible.
>
> Now, maybe they're already doing this in secret, in which case kudos
> to them. If not - well, some Intel people read this newsgroup - if any
> of you want to take this idea and follow up on it, be my guest.
>
> Happy New Year everyone!
Although I am a Linux user, and am involved in an application that
will soon require the additional virtual address space afforded by
64-bit architecture, I believe that no 64-bit processor can become the
"commodity" offering unless it runs some version of MS Windows. That
is why x86 is currently the commodity 32-bit choice, and IA-64 is
still in front in the 64-bit world. Alpha lost when Microsoft
withdrew its support; DEC and Compaq bungling only sealed its fate.
AMD's Hammer (x86-64) has received more favorable newsgroup press than
IA-64, but until they can get Microsoft on board, they will not be
able to generate the volume required to become "commodity". I'm
rooting for AMD, but a major shift will be required for them to
succeed.
Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
Windows is ported to UltraSparc III. If I were Scott, I'd even offer
to do the kissing while Bill does the bending, and get my chip to make
Intel's and AMD's offerings too late to be relevant. And, for Linux
users, we could capitalize on the work that has already been done on
UltraLinux, and bring it to the point where it can run 64-bit
applications.
An alternative fantasy: Windows on the PowerPC, both 32- and 64-bit.
A coup for Motorola, a reconciliation between IBM and Microsoft, and
the shaft for Apple.
Jay
Rupert Pigott
news:4ce97a1a.02010...@posting.google.com...
[SNIP]
> An alternative fantasy: Windows on the PowerPC, both 32- and 64-bit.
> A coup for Motorola, a reconciliation between IBM and Microsoft, and
> the shaft for Apple.
Ah, you could have your heaven on earth with NT 3.5 & 3.51. Best of luck to
you. :)
Cheers,
Rupert
Bernd Paysan
> The "pretty high-end" CAD SW I'm using is HDL simulation, synthesis and FPGA
> Place&Route tools. Recent FPGAs have become large enough to build a respectable
> SOC on them, which is what I'm doing. I am constantly running out of memory in
> the P&R SW; I also have problems in gate-level simulations.
Up to now, most PCs have other limits (for memory size) than the 32 bit
addressing. The last Athlon we bought in the office for fast gate-level
simulations has "just" 1GB RAM, and since the board has just 2 DDR-SDRAM
slots, it's not possible to equip this board with much more - you can't
get more than 512MB on a single DIMM. It's not a problem for us, all
simulations run in memory, no swapping.
> The Unix versions of the CAD SW I'm using (HDL simulator, synthesis tools
> etc.) are *much* more expensive than the PC versions.
That's in fact true, especially if you compare with Altera's Qartus web
edition (for free on Windows). However, Altera announced that they will
port Quartus to Linux, and I hope that they treat it as "PC", and give
it the same price.
Bernd Paysan
> Or maybe they'll end up copying AMD. I guess we'll see how things go.
They have no easy way out. When IBM stopped making PCs (and started
building PS/2 systems with microchannel), they could get over the
disaster by simply adopting the PCI bus, defined by Intel. They hadn't
to clone Compaq.
Pat Gelsinger said "We innovate, AMD immitates". He means that when AMD
introduces SIMD-floating point (3Dnow!), Intel will come a year later
with something incompatible (though basically the same); the word
"innovate" here is used as by Bill Gates. I'm pretty sure if they do
x86-64, they'll do it in a sufficiently different way to how AMD does
it, so that AMD will have to put some work into the decoder stage of the
Hammer to get it Intel-compatible again.
Paul DeMone
Bernd Paysan wrote:
[...]
> The result might not necessary be a real Alpha CPU (just to not lose the
> face), but it is not so far-fetched that Intel might abandon the IA-64
> architecture. The only project I'm aware that's being worked on with
> IA-64 instruction set is the McKinley, the follow-up projects have been
> scrapped and replaced by shrinked McKinleys. Customer support is not an
> issue with some hundred Itanic machines sold.
The former EV8 team now at Intel is working on an all-new IA64 core
design. McKinley doesn't leave much on table when it comes to a new
single threaded IA64 two-banger. Doing IA64 wider than a two-banger
without some form of hardware multithreading seems like a waste of
time. So I'd guess the new core will be multithreading whether or
not it is a two banger or something wider.
Eric Smith
> Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
> Windows is ported to UltraSparc III. If I were Scott, I'd even offer
> to do the kissing while Bill does the bending, and get my chip to make
> Intel's and AMD's offerings too late to be relevant.
Even if they did it, no one would buy it. Remember that there were not
enough sales of NT on the Alpha, MIPS, or PowerPC to justify keeping
those ports alive. And on the Alpha, DEC actually did a credible job
of binary translation of x86 binaries.
But give people a choice between Windows on an UltraSparc, and Windows
on an Itanium, almost everyone will take the Itanium. Because even though
it won't have fantastic x86 performance, it will still beat the performance
of x86 with binary translation on an UltraSparc.
> An alternative fantasy: Windows on the PowerPC, both 32- and 64-bit.
> A coup for Motorola, a reconciliation between IBM and Microsoft, and
> the shaft for Apple.
You never explained why you think Windows for the Hammer (x86-64)
wouldn't fly, but any sensible person can see that it would be *much*
more likely to be successful in the marketplace than Windows on
UltraSparc III, PowerPC, Alpha, or MIPS would.
Microsoft may not be going around banging the x86-64 drum, but that
doesn't mean that they won't support it. The real issue is whether
AMD delivers working parts in a timely manner, such that they are
performance-competitive with Intel's high-end offerings. Five years
ago I wouldn't have expect that, but the Athlon shows that they
can do it.
If Intel doesn't do a good job of pulling a rabbit out of a hat, it's
entirely possible that a year from now AMD will once again be making
the highest-performance x86 processors. They're still pretty close
to that now.
John Dallman
Maclaren) wrote:
> To be fair to Intel, there are some thousands (perhaps even tens of
> thousands) in OEMs and software houses, who are actually more important
> than end customers to Intel's future. In Intel's heyday, it could
> afford to make changes that would cost them serious money, but now
> it is in a slightly more precarious boat.
Yup. I've spent about half my time over the last two years digging out and
reporting IA-64 compiler bugs. If that were to end up being wasted - well,
my management would be quite unhappy, and I'd have, shall we say, reduced
morale with respect to supporting a new Intel architecture. Phrases like
"this time, we want real SPEC figures before we commit to any work" might
be used.
John Dallman
lyng...@aol.com (Jay Braun) wrote:
> Although I am a Linux user, and am involved in an application that
> will soon require the additional virtual address space afforded by
> 64-bit architecture, I believe that no 64-bit processor can become the
> "commodity" offering unless it runs some version of MS Windows.
I think you're right.
> That is why x86 is currently the commodity 32-bit choice, and IA-64 is
> still in front in the 64-bit world. Alpha lost when Microsoft
> withdrew its support; DEC and Compaq bungling only sealed its fate.
Windows on Alpha was killed off when Compaq decided to stop paying MS to
maintain it. That was August 1999, IIRC, a few weeks after the first
Itaniums ran. You can see why Compaq would have taken the decision, given
that few people expected Itanium to be so delayed at the time.
> AMD's Hammer (x86-64) has received more favorable newsgroup press than
> IA-64, but until they can get Microsoft on board, they will not be
> able to generate the volume required to become "commodity". I'm
> rooting for AMD, but a major shift will be required for them to
> succeed.
AMD aren't saying anything about MS at present. It just could be that
they've decided to make sure all the ducks are in line before they
announce; I'll wait and see.
> Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
> Windows is ported to UltraSparc III. If I were Scott, I'd even offer
> to do the kissing while Bill does the bending, and get my chip to make
> Intel's and AMD's offerings too late to be relevant.
Getting Windows running on UltraSparc could be done reasonably quickly.
Sadly, all the device drivers, and the commodity-priced hardware, and the
tuning, and the distribution, and all of that, would take rather longer.
Two years, minimum, I reckon. And the tuning matters. Alpha NT never
seemed as well-tuned as x86 NT - it worked OK, but it ran slower than VMS
on the same hardware.
> An alternative fantasy: Windows on the PowerPC, both 32- and 64-bit.
> A coup for Motorola, a reconciliation between IBM and Microsoft, and
> the shaft for Apple.
It happened. No one bought it, because the IBM hardware was about four
times the price of leading-edge Intel-based hardware at the time, and ran
slower. Eventually, IBM gave up paying MS to update it. Windows needs
commodity-priced hardware to succeed, and Intel and AMD are used to that
idea.
cjt
>
><snip>
> But give people a choice between Windows on an UltraSparc, and Windows
> on an Itanium, almost everyone will take the Itanium. Because even though
> it won't have fantastic x86 performance, it will still beat the performance
> of x86 with binary translation on an UltraSparc.
>
I'm not so sure. Doesn't the Itanium itself emulate an X86 in software
faster than it will run X86 code in X86 mode? So why couldn't an UltraSparc?
del cecchi
"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:a0vtcq$93q$1...@pegasus.csx.cam.ac.uk...
> In article <3C323A18...@gmx.de>,
> Bernd Paysan <bernd....@gmx.de> wrote:
> >
> >Didn't Intel already announce that the result of the Alpha team will
be
> >a IPF ("Intel Performance Failure") "with Alpha technology"? What
Alpha
> >technology do they mean they need to buy or could be included in
IA-64?
> >They have a SMT product already, so they don't need to wait for
results
> >from the EV8 team for that knowledge. They might require expertise in
> >those stuff Pat Gelsinger claims AMD doesn't have (for the "real big
> >machines", e.g. more than 2 Itanic CPUs ;-), e.g. some help how to
> >include the memory controller in the CPU, and how to make a
> >point-to-point interconnect network for a CC/NUMA architecture.
They don't need DECites for this. There are others that know how.
Directory cache coherence been around since DASH at Stanford or before.
>
> One could argue how much of an SMT system the Pentium 4 really is,
> but let us assume that it is one. The problem is merging that
> technology with the IA-64 design, and it would be a nightmare.
> My guess is that they DON'T want the EV8 technology, but they DO
> want the skilled people - I should dearly love to know how long
> the period is before those people can leave Intel without penalty,
> but have not heard.
Typically the signing bonuses take 2 years or there about. Stock
options can take longer. Non-Compete clauses and "trade secret" things
are generally shorter.
Come on Aaron, how much they give you, and how long do you have to stay?
>
> >The result might not necessary be a real Alpha CPU (just to not lose
the
> >face), but it is not so far-fetched that Intel might abandon the
IA-64
> >architecture. The only project I'm aware that's being worked on with
> >IA-64 instruction set is the McKinley, the follow-up projects have
been
> >scrapped and replaced by shrinked McKinleys. Customer support is not
an
> >issue with some hundred Itanic machines sold.
Like a McKinley shrink in a new process is not a "project"?
>
> To be fair to Intel, there are some thousands (perhaps even tens of
> thousands) in OEMs and software houses, who are actually more
important
> than end customers to Intel's future. In Intel's heyday, it could
> afford to make changes that would cost them serious money, but now
> it is in a slightly more precarious boat.
A few Systems Companies also.
>
>
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email: nm...@cam.ac.uk
> Tel.: +44 1223 334761 Fax: +44 1223 334679
del cecchi (some snippage, sorry forgot to mark)
del cecchi
news:<3c30d798....@news.eircom.net>...
> > Hi all,
> >
> > A few years ago when IA64 was first announced, I said "Great! Now we
> > can put a good architecture on 90% of desktops to replace this x86
> > mess!"
> >
> >
> > So - at least in this armchair general's opinion ^.^ - what Intel
> > needs to do is start getting Alpha products out ASAP, get Microsoft
to
> > pick up the Alpha version of Windows again, and discontinue IA64 as
> > gracefully as possible.
Could you send me some of what you are chemically recreating with?
> >
> > Now, maybe they're already doing this in secret, in which case kudos
> > to them. If not - well, some Intel people read this newsgroup - if
any
> > of you want to take this idea and follow up on it, be my guest.
> >
> > Happy New Year everyone!
>
> Although I am a Linux user, and am involved in an application that
> will soon require the additional virtual address space afforded by
> 64-bit architecture, I believe that no 64-bit processor can become the
> "commodity" offering unless it runs some version of MS Windows. That
> is why x86 is currently the commodity 32-bit choice, and IA-64 is
> still in front in the 64-bit world. Alpha lost when Microsoft
> withdrew its support; DEC and Compaq bungling only sealed its fate.
>
> AMD's Hammer (x86-64) has received more favorable newsgroup press than
> IA-64, but until they can get Microsoft on board, they will not be
> able to generate the volume required to become "commodity". I'm
> rooting for AMD, but a major shift will be required for them to
> succeed.
>
> Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
> Windows is ported to UltraSparc III. If I were Scott, I'd even offer
> to do the kissing while Bill does the bending, and get my chip to make
> Intel's and AMD's offerings too late to be relevant. And, for Linux
> users, we could capitalize on the work that has already been done on
> UltraLinux, and bring it to the point where it can run 64-bit
> applications.
This is a serious question, not sarcasm. Isn't there a 64 bit linux on
PowerPC among other ISAs? Is the Linux that runs on Z9000 32 bit?
>
> An alternative fantasy: Windows on the PowerPC, both 32- and 64-bit.
> A coup for Motorola, a reconciliation between IBM and Microsoft, and
> the shaft for Apple.
Maybe you should switch to fantasies about supermodels. I think they
are more likely. :-)
>
> Jay
aaron spink
"del cecchi" <dce...@msn.com> wrote in message
news:PKOY7.4125$ag1.1...@eagle.america.net...
> They don't need DECites for this. There are others that know how.
> Directory cache coherence been around since DASH at Stanford or before.
>
band(several of which were involved in EV7 in some form or another), neither
DASH nor FLASH were/are anywhere in the same league as something like EV7,
Power4, or Hammer.
Come on Del, you know there is a difference between research, esp college
research, and actual viable products.
> Come on Aaron, how much they give you, and how long do you have to stay?
>
Thats private. I don't know of any restrictions on the info except my own
personal restrictions. Don't discuss salary and bonuses on the usenet with
people you might one day want to hire you. Somehow it can always be used
against you. You can probably guess the quality of the offers by the number
of people who took them, though.
Aaron Spink
speaking for myself
del cecchi
"aaron spink" <aaron...@earthlink.net> wrote in message
news:O%QY7.9934$%C1.9...@newsread1.prod.itd.earthlink.net...
say how much. :-) Two Years?
I was just pointing out that Intel didn't need to buy the Alpha team,
wonderful as they are, to do a CCNuma system in which the nodes are
connected by a network. IBM has done it, SGI has done it, Stanford has
done it. Dolphin has done it.
My take is that cpq got a lump sum payment and a cross license of some
sort. After all, one has to have a license to use an Intel processor
because all sorts of stuff like the busses is patented. And Intel also
arranged, probably along with giving cpq some money, to acquire a number
of talented engineers.
What else intel threw in the deal isn't public (yet).
del
Douglas Siebert
>AMD's Hammer (x86-64) has received more favorable newsgroup press than
>IA-64, but until they can get Microsoft on board, they will not be
>able to generate the volume required to become "commodity". I'm
>rooting for AMD, but a major shift will be required for them to
>succeed.
I don't remember the exact details, but there was a bit of a stir sometime
last spring when someone found something in a Windows XP beta code devkit
that referred to a define "AMD64" in an include file. Anyone have the
Windows XP 64 bit devkit, is that there (or if not, was it in an older
version and then hastily removed to avoid pissing off Intel?)
Microsoft has nothing to gain by backing IA64 at the expense of x86-64,
especially given that Linux will be fully supporting x86-64 boxes from
day one. They'll play both horses, and drop support for whichever one
isn't going anywhere. Same reason they dropped support for NT on MIPS,
PowerPC and later Alpha. When NT first came out they really thought
there was a chance that the RISC guys could lower costs enough to
compete with x86 boxes in the workstation/small server space. I remember
all the posts here from Alpha lovers who said the 21164PC was going to
kick Intel where it hurt. By the time they made the $2500 system price
point they were aiming at, PCs were passing $1000 and still dropping.
I think a lot of potential players in the x86-64 space are probably
laying low until the release date is set in stone.
Eric Smith
> I'm not so sure. Doesn't the Itanium itself emulate an X86 in software
> faster than it will run X86 code in X86 mode? So why couldn't an UltraSparc?
With what software emulator? Hard to believe that they could make the
x86 mode perform that badly.
Nick Maclaren
del cecchi <dce...@msn.com> wrote:
>
>> >The result might not necessary be a real Alpha CPU (just to not lose
>the
>> >face), but it is not so far-fetched that Intel might abandon the
>IA-64
>> >architecture. The only project I'm aware that's being worked on with
>> >IA-64 instruction set is the McKinley, the follow-up projects have
>been
>> >scrapped and replaced by shrinked McKinleys. Customer support is not
>an
>> >issue with some hundred Itanic machines sold.
>
>Like a McKinley shrink in a new process is not a "project"?
In this context, no, not really. Remember that the original plan
was for either one or two new designs for the Madison and Deerfield.
I know that a process shrink and speed bump isn't just a matter of
reducing the die, but it is a vastly smaller task than designing a
new chip!
[ You know all the following, of course. ]
The point is that all serious chip vendors have chip N in production,
N+1 in development and N+2 in design (or similar), because of the
long lead times. Intel and HP started that way on the IA-64, but
during the Merced problem years the N+2 design projects curled up
at the edges and died. Now, I should very much like to know why
that happened and how the management could have been so moronic to
let it happen, but I don't.
>> To be fair to Intel, there are some thousands (perhaps even tens of
>> thousands) in OEMs and software houses, who are actually more
>important
>> than end customers to Intel's future. In Intel's heyday, it could
>> afford to make changes that would cost them serious money, but now
>> it is in a slightly more precarious boat.
>
>A few Systems Companies also.
Yes. I was regarding them as sort of OEMs. But they would find it
a lot easier to switch supplier than 'pure' OEMs. Five years ago,
Intel held the whip hand in discussions with IBM - nowadays, the
boot should be on the other foot [*]. I can't tell you whether IBM
is taking advantage of this, but I do know that a lot of the technical
staff and junior management would have to be muzzled to stop them :-)
[*] Certainly, Sir Jasper, immediately, Sir Jasper.
Dennis O'Connor
> One could argue how much of an SMT system the Pentium 4 really is,
Not really, if you know anything about it.
> but let us assume that it is one. The problem is merging that
> technology with the IA-64 design, and it would be a nightmare.
Have you any actual experience with the design of
multi-threaded hardware ? If so, where do you imagine
the difficulty is ?
I won't be surprised if you don't actually know, tho.
--
Dennis O'Connor dm...@primenet.com
Not speaking for my employer, of course.
Anton Ertl
lyng...@aol.com (Jay Braun) writes:
>Although I am a Linux user, and am involved in an application that
>will soon require the additional virtual address space afforded by
>64-bit architecture, I believe that no 64-bit processor can become the
>"commodity" offering unless it runs some version of MS Windows. That
>is why x86 is currently the commodity 32-bit choice, and IA-64 is
>still in front in the 64-bit world.
In what way is IA-64 in front?
>AMD's Hammer (x86-64) has received more favorable newsgroup press than
>IA-64, but until they can get Microsoft on board, they will not be
>able to generate the volume required to become "commodity".
I expect Hammer to run Windows from day 1, without much (if any)
support from MS. And I expect it to replace the other AMD processors
like the Athlon replaced the K6 line, and therefore I expect it to
become a commodity.
Now MS porting Win64 to x86-64 is a different issue, but that's not
needed to make Hammer a commodity; three-button mice are a commodity
even though MS does not support the third button (at least not W98 on
my Logitech mouse). I guess when >80% of all newly-sold 64-bit
machines are x86-64 (and I expect that for 2004), Intel will have to
pay dearly for MS to not port Win64 to that platform.
OTOH, Win64 won't be important until it is available on commodity
machines, and some mass-market application runs only on Win64.
So I guess Intel thinks they have time to wait for IA-64 to flop in a
way that everyone sees, and only then present their Pentium64 (or
whatever it will be called) architecture and do to x86-64 what SSE has
done to 3Dnow. They may be right, but then, they may not.
>Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
>Windows is ported to UltraSparc III. If I were Scott, I'd even offer
>to do the kissing while Bill does the bending, and get my chip to make
>Intel's and AMD's offerings too late to be relevant.
Why should SPARC fare any better in this game than MIPS, PPC,
Alpha or IA-64? I see no chance for Windows on SPARC.
> And, for Linux
>users, we could capitalize on the work that has already been done on
>UltraLinux, and bring it to the point where it can run 64-bit
>applications.
I have been running 64-bit applications on Linux-Alpha since 1997; why
should I wait for UltraLinux (what's missing there, BTW?). If you
want a cheap 64-bit Linux platform now, your best bet is to look
around for a second-hand Alpha. In two years, I guess it will be to
buy a new Hammer.
- 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
Nick Maclaren
In article <10100530...@nnrp1.phx1.gblx.net>, "Dennis O'Connor" <dm...@primenet.com> writes:
|> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote
|> > One could argue how much of an SMT system the Pentium 4 really is,
|>
|> Not really, if you know anything about it.
In article <9n2kho$42q$1...@nnrp3.phx.gblx.net>, "Dennis O'Connor" <dm...@primenet.com> writes:
|> "Ketil Z Malde" <ke...@ii.uib.no> wrote ...
|> > nm...@cus.cam.ac.uk (Nick Maclaren) writes:
|> > > HP will know perfectly well how fiendish a task it will be to
|> > > merge EV8 technology into IA-64,
|> >
|> > Any reason Intel will try to do that?
|>
|> More to the point, what is this "EV8 technology" that Nick
|> Maclaren is talking about ? For example, it's not SMT:
|> Intel's already shown Pentium(R) 4 processors that have that.
Nobody could regard you as being a slave to consistency :-)
|> > but let us assume that it is one. The problem is merging that
|> > technology with the IA-64 design, and it would be a nightmare.
|>
|> Have you any actual experience with the design of
|> multi-threaded hardware ? If so, where do you imagine
|> the difficulty is ?
No, of course I haven't. But I HAVE experience with trying to
pick up the pieces after the designers have shipped a working
product that didn't ....
As I have posted repeatedly, I can't speak for what problems will
occur in the actual hardware design, but I CAN speak from actual
experience that getting the interrupt handling right and getting
good optimisation for such a beast will be hell, or worse.
|> I won't be surprised if you don't actually know, tho.
How much experience of field debugging of first level interrupt
handler bugs and optimising compiler / hardware incompatibilities
do you have, then?
cjt
>
<snip>
>
> So I guess Intel thinks they have time to wait for IA-64 to flop in a
> way that everyone sees, and only then present their Pentium64 (or
> whatever it will be called) architecture and do to x86-64 what SSE has
> done to 3Dnow. They may be right, but then, they may not.
Shouldn't the successor to the Pentium be the Hexium?
Dennis O'Connor
> "Dennis O'Connor" <dm...@primenet.com> writes:
> |> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote
> |> > One could argue how much of an SMT system the Pentium 4 really is,
> |>
> |> Not really, if you know anything about it.
>
> |> More to the point, what is this "EV8 technology" that Nick
> |> Maclaren is talking about ? For example, it's not SMT:
> |> Intel's already shown Pentium(R) 4 processors that have that.
>
> Nobody could regard you as being a slave to consistency :-)
Excuse me ? My statements are completely consistent: it can not
be argued whether some Pentium(R) 4 processors have SMT or
not, because they inarguably do.
> |> > but let us assume that it is one. The problem is merging that
> |> > technology with the IA-64 design, and it would be a nightmare.
> |>
> |> Have you any actual experience with the design of
> |> multi-threaded hardware ? If so, where do you imagine
> |> the difficulty is ?
>
> No, of course I haven't.
Yeah, I didn't think you did. So, your one more amateur making
self-serving wishful claims about things he knows nothing about.
Y'know, ever since Compaq axed Alpha, the S/N ratio in
this group has gone way down. Pity, really.
--
Dennis O'Connor dm...@primenet.com
Not speaking for my employer.
Nick Maclaren
In article <10100711...@nnrp1.phx1.gblx.net>,
"Dennis O'Connor" <dm...@primenet.com> writes:
|>
|> > |> > but let us assume that it is one. The problem is merging that
|> > |> > technology with the IA-64 design, and it would be a nightmare.
|> > |>
|> > |> Have you any actual experience with the design of
|> > |> multi-threaded hardware ? If so, where do you imagine
|> > |> the difficulty is ?
|> >
|> > No, of course I haven't.
|>
|> Yeah, I didn't think you did. So, your one more amateur making
|> self-serving wishful claims about things he knows nothing about.
Well snipped, Sir! If you can't win your argument any other way,
try removing the context. Now, I shall repeat MY statement and
question:
No, of course I haven't. But I HAVE experience with trying to
pick up the pieces after the designers have shipped a working
product that didn't ....
How much experience of field debugging of first level interrupt
handler bugs and optimising compiler / hardware incompatibilities
do you have, then?
Frankly, in this context, you are the amateur.
|> Y'know, ever since Compaq axed Alpha, the S/N ratio in
|> this group has gone way down. Pity, really.
Yes, it is very sad. One hopes that the ex-Alpha people who have
moved to Intel manage to retain their competence for a while,
despite the influence of their new environment.
Dennis O'Connor
> "Dennis O'Connor" <dm...@primenet.com> writes:
> |>
> |> > |> > but let us assume that it is one. The problem is merging that
> |> > |> > technology with the IA-64 design, and it would be a nightmare.
> |> > |>
> |> > |> Have you any actual experience with the design of
> |> > |> multi-threaded hardware ? If so, where do you imagine
> |> > |> the difficulty is ?
> |> >
> |> > No, of course I haven't.
> |>
> |> Yeah, I didn't think you did. So, your one more amateur making
> |> self-serving wishful claims about things he knows nothing about.
>
> Well snipped, Sir!
Speaking of which, shouldn't you have apologized for
your snipe at my consistency, rather than just snipping
the part where you were shown to be wrong ?
> If you can't win your argument any other way,
> try removing the context. Now, I shall repeat MY statement and
> question:
>
> No, of course I haven't. But I HAVE experience with trying to
> pick up the pieces after the designers have shipped a working
> product that didn't .... [...]
Yawn. I didn't remove any relevant context. You seem to
think your experience in one area qualifies you to make
unsupported claims in another. It doesn't.
> Frankly, in this context, you are the amateur.
'Fraid not, since I'm paid to architect microprocessors.
Not that that makes me an expert on SMT, but it
clearly makes me not an amateur.
> [ ... Senseless rabid Intel-bashing snipped ... tsk tsk tsk ]
Nick, stop letting your emotions make a fool of you.
Sander Vesik
I'm not aware of any commercial x86 emulator for the IA64, but it would
be interesting to see results from even say bochs 8-)
--
Sander
+++ Out of cheese error +++
Sander Vesik
>>Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
>>Windows is ported to UltraSparc III. If I were Scott, I'd even offer
>>to do the kissing while Bill does the bending, and get my chip to make
>>Intel's and AMD's offerings too late to be relevant.
> Why should SPARC fare any better in this game than MIPS, PPC,
> Alpha or IA-64? I see no chance for Windows on SPARC.
Has the largest barrier of windows on sparc - sparc being only big
endian - been removed?
> - 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
--
Bill Todd
"Dennis O'Connor" <dm...@primenet.com> wrote in message
news:10100711...@nnrp1.phx1.gblx.net...
...
> Y'know, ever since Compaq axed Alpha, the S/N ratio in
> this group has gone way down. Pity, really.
A rather surprising attitude from someone who, at least during the 4 years
I've hung around here (I've heard rumors that you may not have been always
thus), has contributed virtually *no* signal at all but just chosen to snipe
(usually incompetently and nastily) at those who attempt to.
The pity is that you apparently have no better way to occupy your time.
- bill
Toon Moene
> Yup. I've spent about half my time over the last two years digging out and
> reporting IA-64 compiler bugs. If that were to end up being wasted - well,
> my management would be quite unhappy, and I'd have, shall we say, reduced
> morale with respect to supporting a new Intel architecture. Phrases like
> "this time, we want real SPEC figures before we commit to any work" might
> be used.
You mean your management just jumped on the IA-64 bandwagon without
having been shown any (real, measurable, repeatable) performance figures
?!??!
Some people just get the processor they deserve.
--
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)
Greg Lindahl
Toon Moene <to...@moene.indiv.nluug.nl> wrote:
>You mean your management just jumped on the IA-64 bandwagon without
>having been shown any (real, measurable, repeatable) performance figures
>?!??!
>
>Some people just get the processor they deserve.
Toon, that's a bit overly harsh. Any company that has to decide before
working silicon and compilers exist has to cope with wild guesses and
small simulations.
For example, AMD has not released a x86-64 simulator useful for
performance simulations. I bet that they have an in-house, very slow
simulator that's accurate for timing, which they won't release to
anyone for any purpose, because it contains lots of proprietary
details about the microarchitecture. So, how do you propose any server
vendor make a good decision about x86-64? No SPEC2000, no way...
greg
Dennis O'Connor
> > this group has gone way down. Pity, really.
>
> A rather surprising attitude from someone who, at least during the 4 years
> I've hung around here (I've heard rumors that you may not have been always
> thus), has contributed virtually *no* signal at all but just chosen to snipe
> (usually incompetently and nastily) at those who attempt to.
Bill, you never did continue with this thread:
http://groups.google.com/groups?selm=9j3b45%242em%241%40pyrite.mv.net
Gee, I can't imagine why not, except, of course, that
you were exactly as full of shit as I said you where.
You are, in fact, one of the habitual cross-posting noise sources.
And will be, until you get over your teen-age-style Alpha angst.
Or will you still be bemoaning Alpha in the year 2025 ?
--
Dennis O'Connor dm...@primenet.com
We don't become a rabid dog to destroy a rabid dog.
Tony Nelson
wrote:
> Shouldn't the successor to the Pentium be the Hexium?
I think Sexium, then Septium. Both bad names for marketing a CPU. They
should have talked it out when they were choosing Pentium in the first
place. Now they're trapped into Pentium + a number.
____________________________________________________________________
TonyN.:' tony...@shore.net
'
Douglas Siebert
>cjt <chel...@prodigy.net> wrote:
>> I'm not so sure. Doesn't the Itanium itself emulate an X86 in software
>> faster than it will run X86 code in X86 mode? So why couldn't an UltraSparc?
>I'm not aware of any commercial x86 emulator for the IA64, but it would
>be interesting to see results from even say bochs 8-)
McKinley could always fix the IA-64 x86 performance problem. But if it
doesn't, and you can still get better x86 performance running VirtualPC
on an original iMac, Intel ought to give up on hardware compatibility
and just do it in software. Otherwise they are just wasting die size,
power/heat budget, and time for development and verification.
It sure would be interesting to know if x86 support has had any impact at
all on the various IA-64 project problems.
Maynard Handley
<dm...@primenet.com> wrote:
> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote ...
> > "Dennis O'Connor" <dm...@primenet.com> writes:
> > |> "Nick Maclaren" <nm...@cus.cam.ac.uk> wrote
> > |> > One could argue how much of an SMT system the Pentium 4 really is,
> > |>
> > |> Not really, if you know anything about it.
> >
> > [Way in the past] "Dennis O'Connor" <dm...@primenet.com> writes:
> > |> More to the point, what is this "EV8 technology" that Nick
> > |> Maclaren is talking about ? For example, it's not SMT:
> > |> Intel's already shown Pentium(R) 4 processors that have that.
> >
> > Nobody could regard you as being a slave to consistency :-)
>
> Excuse me ? My statements are completely consistent: it can not
> be argued whether some Pentium(R) 4 processors have SMT or
> not, because they inarguably do.
So a different question, Dennis.
I assume, bcs IA-32 has no processID type tag for the TLB, that the
threads have to be from the same app. What OS's currently support this,
and are there limitations other than the threads are standard Win32/Posix
threads in the same app?
Maynard
Dennis O'Connor
> "Dennis O'Connor" <dm...@primenet.com> wrote:
> > Excuse me ? My statements are completely consistent: it can not
> > be argued whether some Pentium(R) 4 processors have SMT or
> > not, because they inarguably do.
>
> So a different question, Dennis.
> I assume, bcs IA-32 has no processID type tag for the TLB, that the
> threads have to be from the same app.
From what I know of Pentium(R) 4 processors with multi-threading,
your conclusion is definitely incorrect. To say more, I'd want to first
check what Intel has made public about it.
David T. Wang
: In article <10100711...@nnrp1.phx1.gblx.net>, "Dennis O'Connor"
: <dm...@primenet.com> wrote:
:> Excuse me ? My statements are completely consistent: it can not
:> be argued whether some Pentium(R) 4 processors have SMT or
:> not, because they inarguably do.
: So a different question, Dennis.
: I assume, bcs IA-32 has no processID type tag for the TLB, that the
: threads have to be from the same app. What OS's currently support this,
: and are there limitations other than the threads are standard Win32/Posix
: threads in the same app?
The SMT model in Pentium 4 processors present 2 logical processor to the
OS. The threads can come from anywhere. They don't have to be threads
from the same context.
http://www.intel.com/technology/hyperthread/download/25000802.pdf
Section 2.0
An IA-32 processor with Hyper-threading technology will appear to
software as two independent IA-32 processors, similar to two physical
processors in a traditional DP platform.
I don't know how the TLB was designed to handle the threading capability,
but it would seem to me that the TLB entries must have additional tags
or maybe it has to be partitioned somehow in "SMT mode".
--
E PLURIBUS UNUM
ddaavveewwaanngg@@wwaamm..uummdd..eedduu
Bill Todd
"Dennis O'Connor" <dm...@primenet.com> wrote in message
news:10100981...@nnrp1.phx1.gblx.net...
> "Bill Todd" <bill...@metrocast.net> wrote...
> > "Dennis O'Connor" <dm...@primenet.com> wrote
> > > Y'know, ever since Compaq axed Alpha, the S/N ratio in
> > > this group has gone way down. Pity, really.
> >
> > A rather surprising attitude from someone who, at least during the 4
years
> > I've hung around here (I've heard rumors that you may not have been
always
> > thus), has contributed virtually *no* signal at all but just chosen to
snipe
> > (usually incompetently and nastily) at those who attempt to.
>
> Bill, you never did continue with this thread:
>
> http://groups.google.com/groups?selm=9j3b45%242em%241%40pyrite.mv.net
If you'll check the post you cite, you'll see that I had finished with it.
...
> You are, in fact, one of the habitual cross-posting noise sources.
While you're not really a sufficiently annoying little fart to waste more
time on, I'm getting tired of others apparently objecting to cross-posting
on principle rather than on its merits.
I'll assume that you're not objecting to venues other than comp.arch, since
I've never seen you show up there (save when coming from here). The various
DEC-related groups get cross-posted a lot because people with widely-ranging
interests often don't routinely read more than one, which explains why
Alpha-related discussion often goes to comp.os.vms, comp.unix.tru64, and
comp.sys.dec. Terry sometimes includes vmsnet.alpha and comp.org.decus for
good measure (and when I'm responding to something sent there, so do I), and
denizens of these groups don't complain. Comp.sys.intel may or may not
cover your side of the world with similar adequacy, but it's a start.
The reason comp.arch gets included is because the justifications Compaq gave
for axing Alpha had significant technical content, involving presumed
capabilities of the two architectures (both in isolation and in systems)
several years and product generations down the road. If you know of a
better venue than comp.arch for assessing such claims, I'll be happy to
include it next time around (but will still feel comp.arch is appropriate as
well).
It's easy to understand why Del may get annoyed with the continuing Alpha
discussion: Alpha has always seemed to do effortlessly what IBM has had to
sweat and swear to get Power to do, and while elegance is worthy of respect
so is diligence when it achieves a comparable result (and the reported
elitist attitude of some Alpha development likely didn't help). Intel,
however, should just be so embarrassed that it keeps as quiet as possible:
7 years into a 3-year project all it's come up with is a chip that uses more
power than anything else on the market to produce bottom-of-the-barrel
commercial performance, with little prospect of significant improvement
until such time as the Alpha team may be able to effect at least a partial
rescue.
- bill
Torben Ægidius Mogensen
> Perhaps, Intel will merge Alpha and StrongARM/Xscale together
> to form: 64-bit XScale architecture
> that is very low on power consumption yet all the joys of Alpha arch.
Alpha and ARM are quite different ISA's, so it is by no means obvious
that Alpha technology is immediately applicable to ARM. Nevertheless,
StrongARM (the predecessor to Xscale) was developed by DEC engineers,
probably using experience gained from Alpha. So it may well be that
Xscale can benefit from the later Alpha developments.
However, Intel targets Xscale at low-power applications rather than
ultimate performance (much like ARM Ltd. do with ARM in general), so I
won't hold my breath waiting for a Pentium-beating Xscale. Still, it
is possible to make one if Intel wants.
I'm not really sure the present ARM ISA is a good candidate for a
64-bit architecture. There are some details in the ISA (for example,
constant specification and bitshift indicators) that can't easily be
extended to 64 bits. These problems can be overcome, but the result
will be somewhat irregular. There are already several irregularities
in the ARM ISA due to extensions such as 16-bit load/store etc, and
adding more may complicate decoding enough that it becomes a problem
for extreme performance. A possibility is to design a completely new
64-bit ISA and decode 32-bit ARM instructions to these (like Thumb is
decoded on present ARMs).
> As for x86 compatibility, Intel will probably use some sort of emulation
> or use an x86 decoder to keep the pipeline stages to 20+ like the P4 ...
Adding a decoder could work, since the ARM already has arithmetic
flags, which otherwise can be costly/complicated to emulate on
machines that don't have such. Intel/ARM could use a strategy similar
to Jini (ARM's JVM extension) that in the pipeline decodes simple
instructions to short sequences of ARM code and traps complex
instructions for software emulation. The main complication with that
approach is the non-uniform length of x86 instructions, but there are
standard solutions to that.
ARM has a long history of x86 emulation. Acorns first ARM-based
computer from 1987 had (almost?) from the start a DOS emulator that
emulated 80186 code and standard PC hardware. It was a straight
emulator (no JIT) but managed to run DOS programs at a speed close to
a standard 3.67 MHz PC on an 8MHz ARM2. This was mainly because some
system functions used native ARM code, so not all had to be emulated.
But, from a marketing perspective, I doubt Intel will push an Xscale
or Alpha derivative as a sucessor to IA32. They _may_ develop Alpha or
Xscale as high-performance Linux processors, but they will probably
keep Windows exclusively for IA32 derivatives and IA-64. Such a
strategy will preclude adding hardware support for IA32 emulation to
Xscale or Alpha.
Torben Mogensen (tor...@diku.dk)
Erik Corry
> I assume, bcs IA-32 has no processID type tag for the TLB, that the
I don't think the TLB is visible to software on IA32, so there's
nothing to stop Intel introducing a processID tag in the TLB, or
rather a virtual CPU tag, which is what the hardware knows about.
Ie, the TLB entry is tagged with which virtual CPU it belongs to.
I find it a little sad that x86-64 doesn't have a process ID
tag in the TLB either. While they were revising the x86
architecture they could have added that, plus the ability
to virtualise itself ie VMware accelleration.
--
Erik Corry er...@arbat.com Ceterum censeo, Microsoftem esse delendam!
Interviewer: "Real programmers use cat as their editor."
Bill Joy: "That's right! There you go! It is too much trouble to say ed,
because cat's smaller and only needs two pages of memory."
Erik Corry
> McKinley could always fix the IA-64 x86 performance problem. But if it
But did they think that x86 performance would be more or less
important when they did McKinley. My guess is that McKinley
thought x86 might be fading away, relative to its importance
in the Merced timeframe.
Anyone have figures/experiences of the HP-PA RISC emulation
on Merced? It is mostly software, I guess, though a few
instructions look like they were put in IA64 to make HP-PA
RISC code run faster.
> doesn't, and you can still get better x86 performance running VirtualPC
> on an original iMac, Intel ought to give up on hardware compatibility
> and just do it in software. Otherwise they are just wasting die size,
> power/heat budget, and time for development and verification.
But would a software solution give the same warm fuzzy feeling
of knowing that all and any sofware will work, no matter how
sick and twisted a programmer that wrote it? FX!32 never
managed that, though in reality that was probably more a
software problem, eg. DLLs that had the same name in their
x86 and Alpha versions and got overwritten by x86 installers.
Presumably a Merced can run "OS" like ghost (the disk
duplication utility), those Linux-based delete-the-Windows-
administrator-password floppies, DOS-based PCI card firmware
flashers etc. just to name a few sick and twisted things that
require hardware x86 support.
Sander Vesik
>>cjt <chel...@prodigy.net> wrote:
Yes, but i remember reading a lot of rumours in theis newsgroup that
McKinley would not have x86 hardware at ll. Did this change?
> --
> Douglas Siebert dsie...@excisethis.khamsin.net
> He who laughs last thinks slowest.
--
Nick Maclaren
In article <10101498...@haldjas.folklore.ee>,
Sander Vesik <san...@haldjas.folklore.ee> writes:
|>
|> > It sure would be interesting to know if x86 support has had any impact at
|> > all on the various IA-64 project problems.
|>
|> Yes, but i remember reading a lot of rumours in theis newsgroup that
|> McKinley would not have x86 hardware at ll. Did this change?
More than rumours. Intel's originally stated plans were that the
Merced would not have x86 hardware as such, but some logic for
supporting x86 and PA-RISC emulation, and the McKinley would be a
pure IA-64 system. But that was back in 1995 :-)
Later, I heard a rumour that the plan was changed and that McKinley
would continue such support, but Madison would drop it. I think
that this was even said in some Intel presentations, which would
make it more than a rumour.
However, the amount of x86 support was increased to including it
as a hardware mode. Certainly, the IA-64 Application Developer's
Architecture Guide (1.0, May 1999) says as much. While it says
that extra firmware may be needed, it gives no hint that the x86
support is temporary - quite the converse, in fact, as it describes
it as PART of the IA-64 architecture.
I can't tell you what happened, but I cannot see that the McKinley
will not have such support, given that statement in the documentation.
There is also some evidence that one reason for the rift between Intel
and HP was over this issue. I do know that HP were not keen on x86
hardware support and Intel were - for obvious reasons.
There is one other bit of confirming evidence for that hypothesis.
I heard some fairly reliable rumours in about 1998 that the McKinley
was running slightly AHEAD of schedule, and one solution to the
Merced problems was to cancel it entirely and simply roll out the
McKinley. But, shortly thereafter, the McKinley started to slip
and (as became apparent later) Intel took over complete control of
the McKinley from HP.
If Intel had insisted that x86 support were put into the McKinley,
round about 1998, that would account of all of those phenomena.
But I have not a scrap of hard evidence that is what happened.
Dennis O'Connor
> While you're not really a sufficiently annoying little fart to waste more
Ah, it's more of Bill Todd's legendary maturity.
> time on, I'm getting tired of others apparently objecting to cross-posting
> on principle rather than on its merits.
[... self-serving BS snipped ... ]
> The reason comp.arch gets included is because the justifications Compaq
> gave for axing Alpha had significant technical content,
Oh please, spare us your excuses. You whiners seem to mainly bitch about
DEC, Compaq and more recently HP's management, and post fantasy-CFO
statistics you made up to support your arguments. Relevance to comp.arch:
NIL.
> It's easy to understand why Del may get annoyed with the continuing Alpha
> discussion: Alpha has always seemed to do effortlessly what IBM has had to
> sweat and swear to get Power to do [...]
Rather than believe your disparaging fantasies about why Del objects to
inappropriate cross-posting, I'll believe the reasons he gives. But then,
I find Del credible, and I find you not.
Del Cecchi
"Bill Todd" <bill...@metrocast.net> writes:
|>
snip a bunch of dung flinging
|>
|> I'm getting tired of others apparently objecting to cross-posting
|> on principle rather than on its merits.
No, some of us don't share your view of the merits of crossposting tirades to a
bunch of DEC groups, some intel groups, and comp.arch. Clearly our opinions
differ, and as you have so eloquently stated "I'll post where I damn well please.
If you don't like it don't read it"
|>
|>
|> The reason comp.arch gets included is because the justifications Compaq gave
|> for axing Alpha had significant technical content, involving presumed
|> capabilities of the two architectures (both in isolation and in systems)
|> several years and product generations down the road. If you know of a
|> better venue than comp.arch for assessing such claims, I'll be happy to
|> include it next time around (but will still feel comp.arch is appropriate as
|> well).
Nobody but you thought that the justification for killing Alpha had anything to
do with technical issues. That was an excuse. Follow the money. At least that
is how it looks to me.
|>
|> It's easy to understand why Del may get annoyed with the continuing Alpha
|> discussion: Alpha has always seemed to do effortlessly what IBM has had to
|> sweat and swear to get Power to do, and while elegance is worthy of respect
|> so is diligence when it achieves a comparable result (and the reported
|> elitist attitude of some Alpha development likely didn't help). Intel,
|> however, should just be so embarrassed that it keeps as quiet as possible:
|> 7 years into a 3-year project all it's come up with is a chip that uses more
|> power than anything else on the market to produce bottom-of-the-barrel
|> commercial performance, with little prospect of significant improvement
|> until such time as the Alpha team may be able to effect at least a partial
|> rescue.
|>
|> - bill
|>
|>
I don't get annoyed, I just thought it was sort of funny, the Cult of Alpha. :-)
If Alpha did things effortlessly it would have not been too costly for Compaq to
keep around. It seems to me to have taken a great deal of effort and not gotten
too far.
What was the point of continuing to invest? It was a little faster? Not the
ones shipping. Run VMS? Those folk are prisoners and will use what they are
given. Run Unix? Tru64 is in what place? Given HPUX and Linux, what is the
future of that?
What ever happened to the grand plan to use the same chip set for alpha and AMD?
--
Del Cecchi
cecchi@rchland
Greg Lindahl
Del Cecchi <dce...@vnet.ibm.com> wrote:
> What ever happened to the grand plan to use the same chip set for alpha and AMD?
My god, a technical question!
It happened. The fundamental problem was that Compaq's Alpha chipset
(Tsunami) was extremely expensive, so that AMD people didn't want to
use it. And AMD's chipsets were extremely cheap, in the sense of both
$$ and memory bandwidth, so that Alpha folks weren't that interested
in it.
API/Samsung came out with an actual set of products using Alphas and
AMD's chipset, starting with the UP1000, but it didn't sell that
well. Compaq used their expensive chipset for their low end products
(DS10, DS10L), apparently believing that there wasn't much price
elasticity, and that their customers wanted the higher memory
bandwidth.
If there really was a demand for low-end Alphas, today's AMD 760MPX
would make a fairly good chipset: not so great memory bandwidth, but
the PCI implementation is good. The only nit is that everyone went
back to socketed CPUs, so you'd have to spin a motherboard with a
different socket, and a slightly different PCB.
greg
Nick Maclaren
Um. It isn't quite fair to assume that the failure of the UP1000
and DS10/DS10L to sell was due to lack of demand. There were a
lot of other complications, such as Compaq's 'interesting' rules
on licensing and supporting Tru64 Unix and the compilers. We
looked at the UP1000 quite seriously, and that was one of the
reasons that we didn't like the idea.
Another reason is the delay. When Compaq took over the Alpha, it
was vastly faster than any comparable chip, and better value in
terms of MFlops/$ than the Intel chips. By the time the UP1000
appeared, it was faster but not all that much faster, and it was
no longer better value.
Brig Campbell
"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:a14bd1$liu$1...@pegasus.csx.cam.ac.uk...
<snip>
> I can't tell you what happened, but I cannot see that the McKinley
> will not have such support, given that statement in the documentation.
> There is also some evidence that one reason for the rift between Intel
> and HP was over this issue. I do know that HP were not keen on x86
> hardware support and Intel were - for obvious reasons.
>
Curious, what are the obvious reasons that HP were not keen on x86 support
in McKinley? They wanted to stop the x86 Windows install based from
migrating to IA-64? I thought the purpose for x86 and PA-RISC support was
migration/assimalation.
It's also unclear to me what the value of x86 support will *actually* be in
the market especially considering the performance difference between P4 and
speculations on IA-64 processors. Would someone really purchase a IA-64
based systems, then run x86 programs...
-brig
Nick Maclaren
In article <a14pdl$dn8$1...@si05.rsvl.unisys.com>,
"Brig Campbell" <brig.c...@unisys.com> writes:
|>
|> > I can't tell you what happened, but I cannot see that the McKinley
|> > will not have such support, given that statement in the documentation.
|> > There is also some evidence that one reason for the rift between Intel
|> > and HP was over this issue. I do know that HP were not keen on x86
|> > hardware support and Intel were - for obvious reasons.
|>
|> Curious, what are the obvious reasons that HP were not keen on x86 support
|> in McKinley? They wanted to stop the x86 Windows install based from
|> migrating to IA-64? I thought the purpose for x86 and PA-RISC support was
|> migration/assimalation.
No, not at all. One of original (and good) reasons that RISC took
over from systems like System/390 was that the latter had a huge
amount of historical baggage that caused unnecessary complexity,
which in turn made it hard to get the CPU as a whole both fast and
correct. Complexity is ALWAYS undesirable, and the x86 design is
at least as complex as the System/390 one.
HP wanted the x86 support to be kept out of the CPU, so that all
the hardware effort could be concentrated on optimising a reliably
correct design. They weren't keen on the sort of problems that have
bedevilled the x86 line throughout its life. If you take a look at
that manual I mentioned, chapter 6 is all about x86 support, and it
looks truly horrible.
CPU modes are a nightmare when you come to design and write low-level
interrupt handlers - a foul area that Intel has always had trouble
with - and interact in unspeakable ways with single-chip parallelism
(most especially SMT). Note that it is terribly easy for a hardware
decision to make it impossible for the software to get things right
(not hard, but IMPOSSIBLE), and the history of computing is littered
with examples of that.
Traditional mainframes had (and their modern descendents have) a
failure reason "Interrupt received when CPU was standing on one leg,
and it fell over - sorry about that, but it should be very rare."
Many modern systems attempt to kludge up the failure, and then fail
even more horribly rather later. If this IS very rare, it can be
lived with - if it becomes an hourly occurrence, it can't.
This is one of the reasons that I don't believe that merging EPIC
and SMT will work - even if the hardware is got to work, the chances
of the software working reliably are zilch.
|> It's also unclear to me what the value of x86 support will *actually* be in
|> the market especially considering the performance difference between P4 and
|> speculations on IA-64 processors. Would someone really purchase a IA-64
|> based systems, then run x86 programs...
Some people believe so.
Greg Lindahl
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>Um. It isn't quite fair to assume that the failure of the UP1000
>and DS10/DS10L to sell was due to lack of demand.
I didn't assume that, and I was hoping nobody would start discussing
other crap, but I hoped in vain.
Anyone know of a newsgroup where computer architecture gets discussed?
-- greg
Greg Lindahl
Brig Campbell <brig.c...@unisys.com> wrote:
> Would someone really purchase a IA-64 based systems, then run x86
> programs...
Yes. Companies like Microsoft and Intel, not to mention ISVs, are not
always quick to port their codes. For example, the beta IA64 compilers
from Intel for Linux were 32-bit executables.
How much of Windows do you think is ported now? If I have an IA64
Windows desktop, I'm going to want Powerpoint. Well, Powerpoint never
got ported to Alpha Windows, so apparently it wasn't clean. Which is
better, a slow but working Powerpoint in x86 emulation, or no
Powerpoint?
greg
Anton Ertl
cec...@signa.rchland.ibm.com (Del Cecchi) writes:
>What ever happened to the grand plan to use the same chip set for alpha and AMD?
Works nicely; we received our two UP1500s last week, each with an
800MHz 21264B and an AMD-761 northbridge; the southbridge is from ALI,
and I think this is also used in some systems with AMD CPUs; all other
components work with AMD CPUs, too. The memory bandwidth
(64(bits)*133(MHz)*2(DDR)) is slightly less than on our XP1000
(256(bits)*83(MHz)), but this does not matter much for us (especially
not with 8MB L2 cache), and we can upgrade using single DIMMs instead
of needing them in quadruples.
[BTW, please keep your lines down to about 70 chars]
Alex Colvin
>> programs...
Don't forget all that mobile code (activex and various *.exe enclosures)
Face it, x86 *is* the common portable instruction set. Not JVM.
>Windows desktop, I'm going to want Powerpoint. Well, Powerpoint never
>got ported to Alpha Windows, so apparently it wasn't clean. Which is
>better, a slow but working Powerpoint in x86 emulation, or no
>Powerpoint?
trick question....
--
mac the naïf
Nick Maclaren
>In article <a14qh3$3c4$1...@pegasus.csx.cam.ac.uk>,
>Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>
>>Um. It isn't quite fair to assume that the failure of the UP1000
>>and DS10/DS10L to sell was due to lack of demand.
>
>I didn't assume that, and I was hoping nobody would start discussing
>other crap, but I hoped in vain.
Well, that's what I understood your posting to say. And, on rereading,
I still understand it to say that.
No matter. If your remarks about the poor sales of the UP1000 and
the questionability of the demand for low-end Alphas are worth
explaining, please do so, otherwise let this drop.
Pete Zaitcev
> > programs...
> How much of Windows do you think is ported now? If I have an IA64
> Windows desktop, I'm going to want Powerpoint. Well, Powerpoint never
> got ported to Alpha Windows, so apparently it wasn't clean. Which is
> better, a slow but working Powerpoint in x86 emulation, or no
> Powerpoint?
>
> greg
Cerainly, no Powerpoint is much better :)
-- Pete
(makes slides in xfig with a great success)
P.S. I do get your point about non-ported applications.
Another example is MacOS that took a while to recompile for PPC.
But you took the worst example possible to illustrate the idea!
Paul DeMone
Sander Vesik wrote:
>
[...]
> > It sure would be interesting to know if x86 support has had any impact at
> > all on the various IA-64 project problems.
>
> Yes, but i remember reading a lot of rumours in theis newsgroup that
> McKinley would not have x86 hardware at ll. Did this change?
I once asked this question of somebody in a position to know and
was assured that McKinley supports x86 in silicon. Of course once
the McKinley had a 7 stage pipeline and now it has 8 stages so I
wouldn't put too much weight on it.
--
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! =-----
Hugh McIntyre
|>
|> Has the largest barrier of windows on sparc - sparc being only big
|> endian - been removed?
Yes, little-endian data accesses were added in SPARCV9.
So all UltraSPARC systems support this.
Somehow I'm not expecting to see a Windows port any time
soon though, although it should make x86 emulation easier.
Hugh.
--
| Hugh McIntyre -- Hugh.M...@Eng.Sun.COM |
| CPU/SRAM Design, Microelectronics, Sun Microsystems, Inc. |
| Speaking for myself, not for Sun Microsystems. |
Maynard Handley
> Maynard Handley <nam...@mac.com> wrote:
>
> > I assume, bcs IA-32 has no processID type tag for the TLB, that the
>
> I don't think the TLB is visible to software on IA32, so there's
> nothing to stop Intel introducing a processID tag in the TLB, or
> rather a virtual CPU tag, which is what the hardware knows about.
> Ie, the TLB entry is tagged with which virtual CPU it belongs to.
>
> I find it a little sad that x86-64 doesn't have a process ID
> tag in the TLB either. While they were revising the x86
> architecture they could have added that, plus the ability
> to virtualise itself ie VMware accelleration.
OK, everyone agrees that the threads can come from different processors.
However no-one has answered the other, more important question.
Which OSs support this, and what are the limitations (if any) on the threads.
After all, Del, it's not fair to be angry at people for saying this is not
"real" if it's not yet real enough (through Intel's lack of releasing info
or anything else) to exist in current OSs.
Maynard
del cecchi
"Greg Lindahl" <lin...@pbm.com> wrote in message
news:3c35f6a8$1...@news.meer.net...
> Anyone know of a newsgroup where computer architecture gets discussed?
>
> -- greg
Sure, this one. When someone has something to discuss.
How about, to extend the serial interface thread, Does anyone care to
comment on
future system configurations in the era when multi-GB/s switched
networks are available as
commodities from a variety of suppliers for a few hundred dollars per
port. Also the virtues or
shortcomings of TCP/IP (with offload) compared to the IB datagram and
RDMA model.
del cecchi
del cecchi
del
"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:a14v5o$ku$1...@news.tuwien.ac.at...
David T. Wang
: In article <a140mn$mem$1...@news.net.uni-c.dk>, Erik Corry <er...@arbat.com> wrote:
:> Maynard Handley <nam...@mac.com> wrote:
:>
:> nothing to stop Intel introducing a processID tag in the TLB, or
:> rather a virtual CPU tag, which is what the hardware knows about.
:> Ie, the TLB entry is tagged with which virtual CPU it belongs to.
:>
:> I find it a little sad that x86-64 doesn't have a process ID
:> tag in the TLB either. While they were revising the x86
:> architecture they could have added that, plus the ability
:> to virtualise itself ie VMware accelleration.
: OK, everyone agrees that the threads can come from different processors.
: However no-one has answered the other, more important question.
: Which OSs support this, and what are the limitations (if any) on the threads.
: After all, Del, it's not fair to be angry at people for saying this is not
: "real" if it's not yet real enough (through Intel's lack of releasing info
: or anything else) to exist in current OSs.
I think you mean that threads can come from different processes.
As to which OS supports it, I think that all OS'es that support the previous
Intel MP specifications will support this Intel style SMT. The threading
appears to be transparent to software.
Once again, I will quote the same section I quoted previously
http://www.intel.com/technology/hyperthread/download/25000802.pdf
--------------------------------------------------------------------------
Section 2.0
An IA-32 processor with Hyper-threading technology will appear to
software as two independent IA-32 processors, similar to two physical
processors in a traditional DP platform. This configuration allows
operating system and application software that is designed to run on a
traditional DP or MP system.....
. . . Although existing operating system ... will run correctly ...
--------------------------------------------------------------------------
IMO, this makes it more than clear that as far as the OS sees it,
the logical processors functionally behave like physical processors
(certainly not the performance characteristics though) So you can
shut your eyes and pretend you have a dual processor box. It may be
advantageous, however, to run an OS that knows about the SMT thing,
and gets recoded to avoid possible performance pitfalls.
Felix von Leitner
> AMD aren't saying anything about MS at present. It just could be that
> they've decided to make sure all the ducks are in line before they
> announce; I'll wait and see.
I think this time Microsoft would even do the port themselves.
If AMD can get Linux to run natively and with high performance on
x86-64, Microsoft will support it as well. If Windows runs on the
hardware but is obviously much inferior (only uses 32 bits), it would
make them look really bad. Of course, that argument only counts if
Hammer comes out and is available as competitively priced as today's
Athlon XPs are.
Wasn't there even a rumour on The Inquirer that Microsoft is already
porting?
> > Here's a fantasy: Scott McNealy and Bill Gates kiss and make up, and
> > Windows is ported to UltraSparc III. If I were Scott, I'd even offer
> > to do the kissing while Bill does the bending, and get my chip to make
> > Intel's and AMD's offerings too late to be relevant.
> Getting Windows running on UltraSparc could be done reasonably quickly.
Does anyone have figures on how portable Windows really is?
How big is the hardware abstraction layer?
How much of the graphics stuff is written in assembly language?
> Sadly, all the device drivers, and the commodity-priced hardware, and the
> tuning, and the distribution, and all of that, would take rather longer.
> Two years, minimum, I reckon. And the tuning matters. Alpha NT never
> seemed as well-tuned as x86 NT - it worked OK, but it ran slower than VMS
> on the same hardware.
Wasn't NT on Alpha running in 32-bit mode?
Felix
Felix von Leitner
> I have been running 64-bit applications on Linux-Alpha since 1997; why
> should I wait for UltraLinux (what's missing there, BTW?).
I heard it's a libc and binutils problem, but I don't know.
I wonder about this myself. If it really is a libc problem, I'll gladly
port my diet libc to sparc64.
Felix
Stephen Fuld
news:48sZ7.5902$ag1.1...@eagle.america.net...
>
>
> How about, to extend the serial interface thread, Does anyone care to
> comment on
> future system configurations in the era when multi-GB/s switched
> networks are available as
> commodities from a variety of suppliers for a few hundred dollars per
> port. Also the virtues or
> shortcomings of TCP/IP (with offload) compared to the IB datagram and
> RDMA model.
Sure, I'll bite.
I think IB will be hurt in its volume acceptance by 3GIO. Yes, IB has a lot
of advantages compared to 3GIO, but the lure of legacy program compatibility
makes 3GIO attractive. This will make it the interface of choice for low
end machines, which will take away from the volumes needed for IB. This
presumes the main use of IB is as an interface to storage and networking,
which most every system needs as opposed to the more nitchy (lower volume)
cluster interconnect.
Another issue directly related to what you asked is the acceptance of iWARP.
As best I can tell, this is an attempt to graft RDMA semantics right onto
the network interface. Then, with a TCP offload engine (TOE) and if iWarp
is done right, you elininate a lot of the disadvantages of network
interfaces, which may tip things in their favor, hurting IB.
Don't get me wrong. I like IB, and hope it succeeds. But the delay caused
by the feuding of the two groups that resulted in IB allowed a window for
other technologies before there is wide IB acceptance, and I think that will
hurt.
Is that Comp.Arch'y enough?? :-)
--
- Stephen Fuld
e-mail address disguised to prevent spam
del cecchi
"Maynard Handley" <nam...@mac.com> wrote in message
news:name99-0401...@handma2.apple.com...
What "Del" you talking about? I never commented on this issue at all.
Some other "Del", or maybe "Dennis"?
del cecchi
cjt
<snip>
> How much of Windows do you think is ported now? If I have an IA64
> Windows desktop, I'm going to want Powerpoint. Well, Powerpoint never
> got ported to Alpha Windows, so apparently it wasn't clean. Which is
> better, a slow but working Powerpoint in x86 emulation, or no
> Powerpoint?
>
> greg
That's an easy one. No PowerPoint.
;-)
Peter L. Montgomery
Tony Nelson <tony...@shore.net> writes:
>In article <3C345F4A...@prodigy.net>, cjt <chel...@prodigy.net>
>wrote:
>
>> Shouldn't the successor to the Pentium be the Hexium?
>
>I think Sexium, then Septium. Both bad names for marketing a CPU. They
>should have talked it out when they were choosing Pentium in the first
>place. Now they're trapped into Pentium + a number.
If Pentium is the end of the (2^5)-bit line, then
Sexium (Hexium?) can be the end of the (2^6)-bit line
and Septium the end of the (2^7)-bit line.
To get IA-64 from Itanium, note there are 6 letters after the first I
and 4 following the a.
--
The Republican trickle-down theory says tax cuts encourage spending.
The year 2001 is a counterexample.
Peter-Lawren...@cwi.nl Home: San Rafael, California
Microsoft Research and CWI
Dennis O'Connor
> OK, everyone agrees that the threads can come from different processors.
You mean, different _processes_.
> However no-one has answered the other, more important question.
> Which OSs support this,
Okay, I did 10 seconds of searching on Intel's web site, from home,
and found http://www.intel.com/technology/hyperthread/index.htm.
And there it says: "This technology is largely invisible to the platform.
In fact, many applications are already multi-threaded and only small
changes are needed to make them Hyper-Threading Technology
optimized. Today's MP aware software is compatible with
Hyper-Threading enabled platforms, but further performance
gains can be realized by specifically tuning software [...]"
Now, why couldn't you do that, Maynard ?
It's bad enough that some students don't know how or are to
lazy to use a periodicals index, and can use Web search engines
to find information. But Maynard, can't you even do THAT ?
Do you have to be spoon fed ? Sheesh. How embarrassing.
--
Dennis O'Connor dm...@primenet.com
Not speaking for my employer.
Bill Todd
"Del Cecchi" <cec...@signa.rchland.ibm.com> wrote in message
news:a14mcq$mie$1...@news.rchland.ibm.com...
...
> Nobody but you thought that the justification for killing Alpha had
anything to
> do with technical issues.
Either you've been paying no attention whatsoever, or your wording is
sloppy.
If you meant nobody (*including* me) felt that Alpha was *actually killed*
for technical reasons, then the latter seems the case. If you meant that no
one else felt that Compaq *tried to justify it* on a technical (relative
performance) basis, then not only have you not bothered to check the
citations I offered but you've forgotten Brannon's irate comments on the
subject.
I suppose one could assert that Compaq's attempts in this area were so
laughable that the question of their technical merits should not have been
raised here, but the fact that these assertions have been accepted as
rational by significant numbers of paying, higher-end customers suggests
that discussing them (in a forum competent to do so) is not unreasonable.
Not to mention the attempts some others have made to support them, even
here.
That was an excuse. Follow the money. At least that
> is how it looks to me.
Then you haven't looked very hard.
>
> |>
> |> It's easy to understand why Del may get annoyed with the continuing
Alpha
> |> discussion: Alpha has always seemed to do effortlessly what IBM has
had to
> |> sweat and swear to get Power to do, and while elegance is worthy of
respect
> |> so is diligence when it achieves a comparable result (and the reported
> |> elitist attitude of some Alpha development likely didn't help). Intel,
> |> however, should just be so embarrassed that it keeps as quiet as
possible:
> |> 7 years into a 3-year project all it's come up with is a chip that uses
more
> |> power than anything else on the market to produce bottom-of-the-barrel
> |> commercial performance, with little prospect of significant improvement
> |> until such time as the Alpha team may be able to effect at least a
partial
> |> rescue.
> |>
> |> - bill
> |>
> |>
> I don't get annoyed, I just thought it was sort of funny, the Cult of
Alpha. :-)
Perhaps the slight edge I thought I'd seen a few times in your comments was
a misperception on my part, then. I suspected it might be in part due to
the tendency Alpha had to grab attention despite Power's more robust
presence in the market (and entirely respectable performance in its own
right).
>
> If Alpha did things effortlessly it would have not been too costly for
Compaq to
> keep around. It seems to me to have taken a great deal of effort and not
gotten
> too far.
Don't let facts interfere with your misconceptions - they certainly haven't
so far. And note that my statement was that Alpha *seemed* to achieve its
leadership performance effortlessly, not that it actually did so without
real effort.
>
> What was the point of continuing to invest? It was a little faster? Not
the
> ones shipping.
As compared with what Compaq is replacing it with? Alpha allowed Compaq
systems to compete with anything on the market (when they cared to make the
effort to sell them, anyway). Itanium won't.
Run VMS? Those folk are prisoners and will use what they are
> given.
No. While it's true that only the die-hards were left even before June
25th, there seem to have been signs of significant attrition even among them
since that date.
Run Unix? Tru64 is in what place?
Though a horse race isn't the most applicable comparison one could make,
Tru64 was IIRC in 4th place but gaining ground on everyone ahead of it. And
it returned more profit to Compaq each year than its PC business (which
recently slipped to second place, again indicating that position is far from
everything).
- bill
Bill Todd
> thanks, they really kept that a secret.
There, in a nutshell, is the story of Alpha's market performance (well, that
plus the suspicion that a company which refused to promote its product might
not have much of a commitment to it).
- bill