DEC/Intel deal and Alpha future...
Aaron Spink
rei...@einstein.et.tudelft.nl (R. Lamberts) writes:
> Alpha systems over building IA64 systems? Is there any reason *not* to
> focus on IA64 systems in that situation, and reduce Alpha design effort
> as much as possible without immediately losing existing customers?
Performance! Don't assume that IA64 will be a magic bullet for
intel. They will still be off of the performance curve and by
designing your own chips and systems together as an integrated system
you can come out way ahead. Remember, processors are just the grease
for the systems that they go in. Processors are really quite useless
without a system that can take advantage of them and visa versa. Also
IA64 may leave digital open to concentrate on the high performance
curve since they no longer have a fab to fill, and can use something
else in the lower-mid performance range.
aaron spink
not speaking for dec
Douglas H. Borsom
In article <63njvi$913$1...@elektron.et.tudelft.nl>,
rei...@einstein.et.tudelft.nl (R. Lamberts) wrote:
> I wonder about the implications of DEC selling Digital Semiconductor to
> Intel. At first glance, this looks ominous for Alpha... There are
> issues like:
>
> - DEC will become a fabless design house for Alpha, thereby
> * losing control over process design
The settlement requires Intel to provide certain process technology.
And there's always Mitsubishi and Samsung. Samsung is currently sampling
0.25 micron, 700 MHz 21264 Alpha chips.
> * losing control over fab resource allocation
See answer above.
> * losing market confidence in their products
Well, the fact that Sun is fabless doesn't seem to have hurt confidence
in SPARC. Many analysts predict that more and more companies will follow
a similar path and go fabless.
> * leaving production margin for Intel to collect.
>
> - DEC will build IA64 systems in the future, which may soon reduce
> Alpha to a niche market architecture for 'legacy' DEC system users.
>
> Actually, if DEC is not producing the devices themselves, there may be
> little reason for them to stick to their own architecture when Intel
> starts Merced production. Alpha will require a very expensive design
> effort to stay competetive, and what will be the advantage of building
> Alpha systems over building IA64 systems? Is there any reason *not* to
> focus on IA64 systems in that situation, and reduce Alpha design effort
> as much as possible without immediately losing existing customers?
The cost of any design effort is small beans compared to the cost
of the physical plant to implement the design. It looks like the
Alpha designs currently in the pipeline will give Alpha the
continued performance edge over IA64. And there are still two
big questions for IA64: how fast and how much?
-doug
R. Lamberts
I wonder about the implications of DEC selling Digital Semiconductor to
Intel. At first glance, this looks ominous for Alpha... There are
issues like:
- DEC will become a fabless design house for Alpha, thereby
* losing control over process design
* losing control over fab resource allocation
* losing market confidence in their products
* leaving production margin for Intel to collect.
- DEC will build IA64 systems in the future, which may soon reduce
Alpha to a niche market architecture for 'legacy' DEC system users.
Actually, if DEC is not producing the devices themselves, there may be
little reason for them to stick to their own architecture when Intel
starts Merced production. Alpha will require a very expensive design
effort to stay competetive, and what will be the advantage of building
Alpha systems over building IA64 systems? Is there any reason *not* to
focus on IA64 systems in that situation, and reduce Alpha design effort
as much as possible without immediately losing existing customers?
Admittedly, I am assuming that IA64 implementations will perform well.
Comments?
- Reinoud
Zalman Stern
R. Lamberts (rei...@einstein.et.tudelft.nl) wrote:
: I wonder about the implications of DEC selling Digital Semiconductor to
: Intel. At first glance, this looks ominous for Alpha... There are
: issues like:
From my point of view, things have always "looked" omnious for Alpha. In
terms of longterm economic viability that is. Performance wise, I'd say
things still "look" good though I doubt Alpha will have any significnat
architectural advantage over IA-64. (Which really doesn't matter. IA-32
proves how little instruction set architecture matters in a lot of areas.)
: - DEC will become a fabless design house for Alpha, thereby
: * losing control over process design
: * losing control over fab resource allocation
: * losing market confidence in their products
: * leaving production margin for Intel to collect.
Thereby saving themsleves the enormous sunk costs of maintaining state of
the art fab capacity. Which for Alpha doesn't buy them much because the
volumes are too small. (Note that DEC has taken steps to develope other
product lines and sell excess fab capacity to help pay for those costs.)
: - DEC will build IA64 systems in the future, which may soon reduce
: Alpha to a niche market architecture for 'legacy' DEC system users.
They were going to do that anyway. If anything, the new deal gives DEC a
leg up in the IA-64 systems competition. Keep in mind any damage IA-64
is going to do to Alpha is going to happen pretty much regardless of what
DEC does. Its sort of an "if you can't beat 'em, join 'em" situation.
: Actually, if DEC is not producing the devices themselves, there may be
: little reason for them to stick to their own architecture when Intel
: starts Merced production. Alpha will require a very expensive design
: effort to stay competetive, and what will be the advantage of building
: Alpha systems over building IA64 systems? Is there any reason *not* to
: focus on IA64 systems in that situation, and reduce Alpha design effort
: as much as possible without immediately losing existing customers?
The 21264 generation will be out significantly before IA-64 parts and
should be just as viable as previous generations of Alpha systems in terms
of performance and price/performance vs. competition. DEC has to be
worrying a little about market perception in light of the recent Intel
deal, but I doubt it will matter much. The next generation after that is
more questionable. DEC probably has a pretty solid story there for the
simple reason that customers want to hear it to buy 21264 hardware. So as a
result we might very well see a 21364.
In opinion/speculative mode, I doubt there will be a whole new Alpha
implementation after the 21364. (And the 21364 is not entirely certain is
IA-64 migration works well for DEC.) But realistically, this was true
independent of the DEC/Intel deal.
: Admittedly, I am assuming that IA64 implementations will perform well.
Yes that is an assumption. But Intel's marketshare and development budget
gets them at least two implementations to make IA-64 kick butt and
historically Intel doesn't totally screw up very often. (Which is not to
say that I think their architects have demonstrated good taste in ISA
design :-))
Intel has to make a lot of mistakes to lose. In order for anyone else to
win, they have to do everything incredibly well and hope Intel makes
mistakes. Who can blame DEC for trying to change the rules of the game when
looking at odds like that?
-Z-
Rob Young
In article <63njvi$913$1...@elektron.et.tudelft.nl>, rei...@einstein.et.tudelft.nl (R. Lamberts) writes:
> I wonder about the implications of DEC selling Digital Semiconductor to
> Intel. At first glance, this looks ominous for Alpha... There are
> issues like:
>
> - DEC will become a fabless design house for Alpha, thereby
> * losing control over process design
> * losing control over fab resource allocation
> * losing market confidence in their products
> * leaving production margin for Intel to collect.
All well and good but Intel isn't the only manufacturer of
Alpha AND if you had been paying attention you may have heard
that Samsung will be volume shipping a .25 21264 first half
next year. Actually, "paying attention" is a bit harsh.
You would be hard-pressed to find out that it is a KP21264
(that is what Samsung is calling it) and you would be hard-
pressed to find out anything other than it is a 700 MHz part.
Well not all online rags say "it is 700 MHz, that's about
all we know... Maybe next time we will call someone up and
ask around!!!."
Here is a decent link:
http://www.techweb.com/se/directlink.cgi?EET19971103S0088
"In the meantime, Samsung has pressed ahead. It intends to release the Alpha
chip officially at the same time as Digital, using the Digital-licensed
0.35-micron process. But it has been able to bring the 21264 up sooner, at a
higher speed grade, using its own 0.25-micron CMOS."
Not bad, eh.. The hoped for "shrink" 8 months or so ahead of
schedule. So when it comes to looking at the advantages
disadvantages I believe you would be silly to pass up
the .25 21264 part from Samsung, no? After all it is higher
performing and should be cheaper.
At least that article is more technical, we know now the mystery
700 MHz part is a 21264! Believe they got the time frame
wrong... they (Digital, Samsung, etc.) would have to be
sitting on their thumbs not to get it out the door before
first half '98 not second half as the article above supposes.
> - DEC will build IA64 systems in the future, which may soon reduce
> Alpha to a niche market architecture for 'legacy' DEC system users.
>
> Actually, if DEC is not producing the devices themselves, there may be
> little reason for them to stick to their own architecture when Intel
> starts Merced production. Alpha will require a very expensive design
> effort to stay competetive, and what will be the advantage of building
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Alpha systems over building IA64 systems? Is there any reason *not* to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Much higher performing than IA64. Much higher performing for
at least 4 years as we know (compare 21364 to Merced I).
> focus on IA64 systems in that situation, and reduce Alpha design effort
> as much as possible without immediately losing existing customers?
>
> Admittedly, I am assuming that IA64 implementations will perform well.
>
Oh, IA64 will perform well. Intel talked at length about
Merced II at MPR forum (shipping in 2001). If you look at that .25
21264, you can expect 50 SpecInt95 and 70 Specfp95 according to
Nova (search Usenet for samsung and foundry and 21264).
But never mind 21264 as Digital can crank out the architecture
and be free of the burden of manufacturing. And as Nova
mentions elsewhere, if you think 21264 is something wait until
21364 at 100+ SpecInt95 arriving about the same time as
Merced I (i.e. second half 1999).
Again, will IA64 perform well? Sure. Compared to what though?
Certainly not Alpha, not a fair comparison until 2001... but then again
the shrink of 21364 will be shipping long before then... hummm.
Rob
Rob Young
In article <borsom-0411...@bos-ma11-24.ix.netcom.com>, bor...@ix.netcom.com (Douglas H. Borsom) writes:
>
> The settlement requires Intel to provide certain process technology.
> And there's always Mitsubishi and Samsung. Samsung is currently sampling
> 0.25 micron, 700 MHz 21264 Alpha chips.
>
do a volume .25 part until "May".
In:
http://www.techstocks.com/~wsapi/investor/s-9484/reply-7974
We find:
"In a note to Newsbytes, Samsung sources said: "When the new processor
is in production next summer on the .25 micron process, Samsung
expects a healthy improvement in frequency over and above the 700MHz
parts now being produced. At 600MHz, KP21264 is expected to reach 40
SPECint95 and 60 SPECfp95 rating. At 700MHz the performance ratings
will increase proportionally." [ Bet that 600 MHz KP21264 is
.35 micron and .25 KP21264 starts at 700 MHz, (800 MHz actually
;-) ]
Few gems in there:
"He said that the firm is already ramping up to production and 700MHz
is a conservative speed estimate. "
"Peter Mardahl of the University of California, Berkeley, summed up one
view in an Internet newsgroup posting: "It's vapor right now, but if
you want to sell other vapor against it in 1997 you better have damn
fast vapor."
Whoa, whoa , whoa. What we have here is failure to attribute. Some
men you just can't reach! The honorable Burkhard Neidecker-Lutz
said that Mr. Mardahl. Give credit where credit is due!!!
Rob
Rob Young
In article <63p34o$692$1...@agate.berkeley.edu>, pet...@landau.EECS.Berkeley.EDU (Peter Mardahl) writes:
I said:
>>
>> Whoa, whoa , whoa. What we have here is failure to attribute. Some
>> men you just can't reach! The honorable Burkhard Neidecker-Lutz
>> said that Mr. Mardahl. Give credit where credit is due!!!
>
> I *did* cite Burkhard Neidecker-Lutz in that post. Burkhard posted
> a followup to my post, even.
>
Sorry. Just having a wee bit too much fun at your expense.
"We" know Burkhard said that, someone that wrote it put their
spin on it.
Rob
Peter Mardahl
In article <1997Nov4.235232.1@eisner>,
Rob Young <you...@eisner.decus.org> wrote:
>In article <borsom-0411...@bos-ma11-24.ix.netcom.com>, bor...@ix.netcom.com (Douglas H. Borsom) writes:
>
> "He said that the firm is already ramping up to production and 700MHz
> is a conservative speed estimate. "
>
> "Peter Mardahl of the University of California, Berkeley, summed up one
> view in an Internet newsgroup posting: "It's vapor right now, but if
> you want to sell other vapor against it in 1997 you better have damn
> fast vapor."
>
> men you just can't reach! The honorable Burkhard Neidecker-Lutz
> said that Mr. Mardahl. Give credit where credit is due!!!
I *did* cite Burkhard Neidecker-Lutz in that post. Burkhard posted
a followup to my post, even.
In my post I even made a humourously intended remark about
"Burkhard's words coming back to haunt him" since I was essentially
reposting his words.
Burkhard, will you please back me up on this? I find this
misattribution highly embarassing.
It is easily verified by looking at dejanews anyway, that I
credited those words to Burkhard.
At any rate, the misattribution was not intended by me, and was
in fact none of my doing, and I'm miffed that I was not asked
before "my" words were used. I would have set them straight,
I assure you!
PeterM
Burkhard Neidecker-Lutz
In article <63p34o$692$1...@agate.berkeley.edu> pet...@landau.EECS.Berkeley.EDU (Peter Mardahl) writes:
>In article <1997Nov4.235232.1@eisner>,
>Rob Young <you...@eisner.decus.org> wrote:
>>In article <borsom-0411...@bos-ma11-24.ix.netcom.com>, bor...@ix.netcom.com (Douglas H. Borsom) writes:
>> "Peter Mardahl of the University of California, Berkeley, summed up one
>> view in an Internet newsgroup posting: "It's vapor right now, but if
>> you want to sell other vapor against it in 1997 you better have damn
>> fast vapor."
>>
>> Whoa, whoa , whoa. What we have here is failure to attribute. Some
>> men you just can't reach! The honorable Burkhard Neidecker-Lutz
>> said that Mr. Mardahl. Give credit where credit is due!!!
>
>I *did* cite Burkhard Neidecker-Lutz in that post. Burkhard posted
>a followup to my post, even.
Yes and yes. Peter Mardahl isn't at fault. I also release any copyrights
to that statement :-) , given now that while the 21264 does exist practically
nobody will be able to buy a system with it in 1997, meaning that I have
to swallow my own prediction.
>Burkhard, will you please back me up on this? I find this
>misattribution highly embarassing.
Done.
Burkhard Neidecker-Lutz
EUROMEDIA - Distributed Multimedia Archives for Cooperative TV Production
CEC Karlsruhe , European Applied Research Center, Digital Equip. Corp.
email: nei...@kar.dec.com
Peter Mardahl
In article <63q5vl$s0v$1...@msunews.cl.msu.edu>,
Mark W Brehob <bre...@cps.msu.edu> wrote:
>You know that a significant portion of software _ships_ in with no
>optimization and debug turned on? Software writers find their programs
>break with debug off and finding the bugs is a pain. Time-to-Market.
>I'm still disbelieving that too many folks will ship products with -O3
>or whatever is "safe". Just turning off debug breaks code.
Well, in my experience, the usual case is that the software
was broken, and that having debug on/no optimization just hid the bugs, not
that turning debug off/optimization on caused bugs.
I've often observed this while porting a program from one
platform to another: some bugs just don't bite you on some
platforms, but surface on others, possibly because of different
memory management or compiler or whatever.
PeterM
Doug Siebert
pet...@landau.EECS.Berkeley.EDU (Peter Mardahl) writes:
>Well, in my experience, the usual case is that the software
>was broken, and that having debug on/no optimization just hid the bugs, not
>that turning debug off/optimization on caused bugs.
>I've often observed this while porting a program from one
>platform to another: some bugs just don't bite you on some
>platforms, but surface on others, possibly because of different
>memory management or compiler or whatever.
A few years back, I was responsible for porting a large medical imaging
package from SunOS to Solaris and then HP-UX. The port to Solaris didn't
expose many bugs, since gcc was used on both SunOS and Solaris. On HP-UX
at the time gcc didn't work very well, so I used HP's compiler (which is
what I wanted to use anyway but they had a few modules that used gcc's C
extensions that had to be cleaned up) There were all sorts of bugs that
came up, but I traced every one of them to a flaw in the code rather than
the optimizer. Many of them only reared their head when optimization was
on (at the time you couldn't optimize and enable debug at the same time
with HP's compiler) so it made tracking them down difficult.
Later we got a demo copy of Purify, and it showed all sorts of memory
access violations that didn't cause problems under SunOS or gcc that
should have, and when they were cleaned up all the remaining unexplained
core dumps in the HP version went away. The best thing though was that a
lot of bugs that didn't cause core dumps but "weird things happened" on
the Sun version also went away with these fixes.
--
Douglas Siebert Director of Computing Facilities
douglas...@uiowa.edu Division of Mathematical Sciences, U of Iowa
If you let the system beat you long enough, eventually it'll get tired.
Burkhard Neidecker-Lutz
In article <63njvi$913$1...@elektron.et.tudelft.nl> rei...@einstein.et.tudelft.nl (R. Lamberts) writes:
>- DEC will become a fabless design house for Alpha, thereby
> * losing control over process design
Yes.
> * losing control over fab resource allocation
This assumes knowledge of parts of the contract that aren't public. Also,
there are two more vendors producing Alphas (Samsung and Mitsubishi).
> * losing market confidence in their products
That could well happen if more people misread our announcements. I even
know of high-ranking Digital officials that had trouble last week of
getting this right (you have to read it carefully).
> * leaving production margin for Intel to collect.
You assume that Digital ever *had* a production margin on Alphas. Given
the frantic attempts at filling the FAB6 capacity over the last few
years, that assumption may not hold.
>- DEC will build IA64 systems in the future, which may soon reduce
> Alpha to a niche market architecture for 'legacy' DEC system users.
Digital builds a range of IA32 systems today. Building IA64 systems
is required to stay in the Intel/commodity side of things (especially
for low end servers).
> Alpha will require a very expensive design effort to stay competetive,
Assumption on your part on how large/expensive our design teams are.
Alpha is a very regular and simple architecture. Also an army of
designers cannot do as good a job as a smaller, focused and well
coordinated team.
> what will be the advantage of building Alpha systems over building
> IA64 systems?
Performance. Applications.
>Admittedly, I am assuming that IA64 implementations will perform well.
Given what we've all seen so far, a riscy assumption. IA64 itself is
fine, but depending on very complex compilers and on all third party
software developers of using these said complex compilers at their
highest optimization levels may be something that even Intel will
find hard. Let's say we've had plenty of complaints in the first few
years of Alpha on application performance which turned out to be idiotic
use of compilers for it (like shipping database systems compiled with -O0).
I have no reason to believe that said software vendors will treat any
other non-IA32 CPU with much more care.
Burkhard Neidecker-Lutz
CEC Karlsruhe , European Applied Research Center, Digital Equipment Corporation
email: nei...@kar.dec.com
AlphaServer 4000 5/600: SPECint(_base)95 18.8(17.0), SPECfp(_base)95 29.2(27.0)
Doug Siebert
nei...@kar.dec.com (Burkhard Neidecker-Lutz) writes:
>Given what we've all seen so far, a riscy assumption. IA64 itself is
>fine, but depending on very complex compilers and on all third party
>software developers of using these said complex compilers at their
>highest optimization levels may be something that even Intel will
>find hard. Let's say we've had plenty of complaints in the first few
>years of Alpha on application performance which turned out to be idiotic
>use of compilers for it (like shipping database systems compiled with -O0).
>I have no reason to believe that said software vendors will treat any
>other non-IA32 CPU with much more care.
That's easy for them to fix. Just make -O (or -O3 or whatever you feel is
the "safe" level of optimization) the default for the IA-64 compilers, and
offer some flag to turn optimization off if people want to compile fast.
Sure, they will talk about how their Pentium-133 that is several years old
by that time compiles twice as fast, but given a choice between having slow
compilers and slow compiler output, most people will choose the former.
Mark W Brehob
Doug Siebert (dsie...@icaen.uiowa.edu) wrote:
[Clip]
: That's easy for them to fix. Just make -O (or -O3 or whatever you feel is
: the "safe" level of optimization) the default for the IA-64 compilers, and
: offer some flag to turn optimization off if people want to compile fast.
You know that a significant portion of software _ships_ in with no
optimization and debug turned on? Software writers find their programs
break with debug off and finding the bugs is a pain. Time-to-Market.
I'm still disbelieving that too many folks will ship products with -O3
or whatever is "safe". Just turning off debug breaks code.
Another slight issue:
Does anyone know if the FTC has OKed the DEC/Intel deal? It seems that
it would require some thought.
~~~~~~~~~~~~~~~~~~~~~~~bre...@cps.msu.edu~~~~~~~~~~~~~~~~~~~~~~~~~
| | Why I need publications to teach undergrads I don't know...| |
| -=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |
~~~~~~Mark Brehob: Ultimate Player, Gamer, Computer Geek~~~~~~~~~~
Andrew Ayers
In article <63q5vl$s0v$1...@msunews.cl.msu.edu> bre...@cps.msu.edu (Mark W Brehob) writes:
Doug Siebert (dsie...@icaen.uiowa.edu) wrote:
: That's easy for them to fix. Just make -O (or -O3 or whatever you feel is
: the "safe" level of optimization) the default for the IA-64 compilers, and
: offer some flag to turn optimization off if people want to compile fast.
You know that a significant portion of software _ships_ in with no
optimization and debug turned on? Software writers find their programs
break with debug off and finding the bugs is a pain. Time-to-Market.
I'm still disbelieving that too many folks will ship products with -O3
or whatever is "safe". Just turning off debug breaks code.
We've also found that it can be pretty difficult to get folks to
optimize aggressively, and pretty difficult to get things working
under aggressive optimization, but if you can help one ISV in a given
market to make use of aggressive optimization, the gains are often so
compelling that the rest of the ISVs in the market are at a
significant disadvantage. Of course, if there is no real competition
in the market then you get whatever the dominant ISV feels like giving
you.
-- Andy Ayers
HP High Level Optimizer Group
Zalman Stern
Doug Siebert (dsie...@icaen.uiowa.edu) wrote:
: nei...@kar.dec.com (Burkhard Neidecker-Lutz) writes:
: >I have no reason to believe that said software vendors will treat any
: >other non-IA32 CPU with much more care.
Intel spends a lot more money than DEC does sending engineers to ISVs to
tune the performance of apps for their archtiecture. They come in with a
double whammy of engineering talent (some stunning, some not so) and
marketing "attention" that enables and motivates developers to do the best
possible job on the Intel platform. As with anything else, sometimes it
works, sometimes it doesn't. But no other CPU vendor puts in that kind of
effort.
As an example, a few years back, Intel was getting beaten up on a certain
Photoshop plug-in benchmark relative to Power Macs. (A bogus benchmark, but
that makes no difference in advertising.) Intel tossed a couple engineers
at tuning the inner loop and then gave (as in personal gift) one of the
Windows engineers on the team a dual P6 machine (right after they came out)
in exchange for multithreading the code. (Contrast this to Apple where we
were having arguments about why hardware cache coherency was a good idea if
they wanted working software...) I'd say the above example is indicative of
Intel's "lets solve problems together" attitude.
(Note, DEC could not do a whole lot for themselves by giving developers
Alpha hardware. You gotta have marketshare already to make this technique
worthwhile, but it does give Intel more control over what developers do
than they otherwise would have.)
Now whether Intel decides to support IA-64 aggressively relative to IA-32
is another matter.
-Z-
Eric Hildum
Doug Siebert wrote:
>
> A few years back, I was responsible for porting a large medical imaging
> package from SunOS to Solaris and then HP-UX. The port to Solaris didn't
> expose many bugs, since gcc was used on both SunOS and Solaris. On HP-UX
> at the time gcc didn't work very well, so I used HP's compiler (which is
> what I wanted to use anyway but they had a few modules that used gcc's C
> extensions that had to be cleaned up) There were all sorts of bugs that
> came up, but I traced every one of them to a flaw in the code rather than
> the optimizer. Many of them only reared their head when optimization was
> on (at the time you couldn't optimize and enable debug at the same time
> with HP's compiler) so it made tracking them down difficult.
>
> Later we got a demo copy of Purify, and it showed all sorts of memory
> access violations that didn't cause problems under SunOS or gcc that
> should have, and when they were cleaned up all the remaining unexplained
> core dumps in the HP version went away. The best thing though was that a
> lot of bugs that didn't cause core dumps but "weird things happened" on
> the Sun version also went away with these fixes.
I had similar experiences with porting Unix C programs to VMS. In fact,
I would go so far as to say that the introduction of C and Unix resulted
in a significant increase in the number of bugs in programs. Gradually,
this has turned into a general acceptance of major bugs in software as a
normal, expected occurrance. (How many times have you rebooted Windows
this week?)
>
> --
> Douglas Siebert Director of Computing Facilities
> douglas...@uiowa.edu Division of Mathematical Sciences, U of Iowa
>
> If you let the system beat you long enough, eventually it'll get tired.
Or maybe the system will just get bored...
--
"The idea that Bill Gates has appeared like a knight in shining armour
to lead all customers out of a mire of technological chaos neatly
ignores the fact that it was he who, by peddling second-rate technology,
led them into it in the first place."-Douglas Adams
Eric Hildum
Eric....@Japan.NCR.COM
Paul Kahler
In comp.arch Doug Siebert <dsie...@icaen.uiowa.edu> wrote:
: pet...@landau.EECS.Berkeley.EDU (Peter Mardahl) writes:
: >Well, in my experience, the usual case is that the software
: >was broken, and that having debug on/no optimization just hid the bugs, not
: >that turning debug off/optimization on caused bugs.
When I'm programming at home, I usually turn debug off and optimization
as high as I can get it. When a bug turns up, I switch over to debug and
use it to help find the hard ones. IMHO programmers rely far too
much on tools and far too little on thinking to find bugs (among other
things). Oops, this is getting Way off topic...
BTW, where might I be able to find one of these really fast Alpha machines
running NT to try some code? I don't want to buy one, just compile and see
how fast things are. If anyone can offer limited access to one in the
Detroit area I'd really appreciate it :-) I'm using VC++ and a limited
amount of MFC, so with corresponding tools for Alpha, there should be
very little involved in porting.
Thanks,
___ __ _ _ _
| \ / \ | | | || | phka...@oakland.edu Engineer/Programmer
| _/| || || |_| || |__ " What makes someone care so much?
|_| |_||_| \___/ |____) for things another man can just ignore. " -S.H.
Glenn C. Everhart
In article <63njvi$913$1...@elektron.et.tudelft.nl>
rei...@einstein.et.tudelft.nl (R. Lamberts) wrote:
>
>
> I wonder about the implications of DEC selling Digital Semiconductor to
> Intel. At first glance, this looks ominous for Alpha... There are
> issues like:
>
> - DEC will become a fabless design house for Alpha, thereby
> * losing control over process design
> * losing control over fab resource allocation
> * losing market confidence in their products
> * leaving production margin for Intel to collect.
> - DEC will build IA64 systems in the future, which may soon reduce
> Alpha to a niche market architecture for 'legacy' DEC system users.
>
> Actually, if DEC is not producing the devices themselves, there may be
> little reason for them to stick to their own architecture when Intel
> starts Merced production. Alpha will require a very expensive design
> effort to stay competetive, and what will be the advantage of building
> Alpha systems over building IA64 systems? Is there any reason *not* to
> focus on IA64 systems in that situation, and reduce Alpha design effort
> as much as possible without immediately losing existing customers?
>
> Admittedly, I am assuming that IA64 implementations will perform well.
>
> Comments?
>
> - Reinoud
The reason to stick with Alpha will be to provide a high end system; the
design for the next 1 to 2 generations beyond EV6 is as I hear well along indeed
and due to the Intel agreement will hit the streets now 1-2 years earlier than
expected. That should mean that when Merced hits the streets, Alpha will
have a speed advantage of at least a factor 2. Merced becomes a low end
64 bit chip then.
Also, of course, it will be possible to use VMS Galaxies to run lots of them
at once at levels way beyond what anyone is going to have much luck
working with using SMP techniques. (Your OS is going to do 50 way SMP??
Good luck!)
The main points of galaxies got announced Tuesday, so the notions of
moving CPUs to where the load is (this can be done in a very few instructions
as it turns out) and moving I/O to where it can be handled dynamically
means that problems can be attacked with potentially hundreds of processors
and actually keep gaining performance as you add the last one...
DEC just becomes FABless (as Sun has been for ages) and gains access to the
fab & process of the world's largest CPU maker (who is a DEC customer btw...).
I see no reason to presume Merced will be faster for the foreseeable future.
(Mind, one can't really foresee very far in this business...)
If Merced comes out faster than Alpha, then this analysis is incorrect. If however
Merced comes out as I'm inclined to expect, one might ask whether its line makes
sense long term. Could be Intel would be better off moving over...
The consumer will however win big either way...
Steven Correll
In article <63vg7g$p82$1...@news2.acs.oakland.edu>,
Paul Kahler <phka...@oakland.edu> wrote:
>...I'd really appreciate it :-) I'm using VC++ and a limited
>amount of MFC, so with corresponding tools for Alpha, there should be
>very little involved in porting.
That's what I would have thought, too, but the consultant porting a large
system for my employer from Intel NT to Alpha NT was immediately stymied
when VC++ refused to load the project. Microsoft's suggested workaround was
to re-enter all of the files (over 500 files in 100 directories) and reset
all of the options by hand. I hope they've fixed the bug in the last year,
or that you don't encounter it.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == s...@netcom.com
R. Lamberts
There seem to exist two main views on Alpha future:
1. Alpha cannot withstand the force of IA64; if not the first, then the
second generation IA64 implementation will take away Alpha's advantage.
2. Intel will always target high volume and low performance, so Alpha
will remain the performance choice.
Does *anyone* outside DEC really believe Intel will actually let
go of the high end, high margin portion of the (64-bit) market?
I can't believe this. If they have any sense (and they have shown a
lot of sense so far), they will aim at top performance for their 64-bit
arch and service the low end with IA32. Where else than the high end
can they position their new, incompatible architecture? Only later on
there may be a place for low-end IA64.
So the question is, really, why would IA64 in general, and Merced in
particular, *not* come at least close to Alpha performance? Little as
has been published on EPIC, can they not *at least* pull any
implementation trick that is possible with Alpha? Would they really
make stupid ISA design mistakes again, like with x86? This isn't the
Intel of old days...
(I'm playing devil's advocate here, for many reasons I would like to
see Alpha survive.)
- Reinoud
Paul DeMone
R. Lamberts wrote:
>
> There seem to exist two main views on Alpha future:
>
> 1. Alpha cannot withstand the force of IA64; if not the first, then the
> second generation IA64 implementation will take away Alpha's advantage.
>
> 2. Intel will always target high volume and low performance, so Alpha
> will remain the performance choice.
>
> Does *anyone* outside DEC really believe Intel will actually let
> go of the high end, high margin portion of the (64-bit) market?
I wasn't aware Intel was shipping any 64 bit products so how is it that
they could "let go" of it?
>
> I can't believe this. If they have any sense (and they have shown a
> lot of sense so far), they will aim at top performance for their 64-bit
> arch and service the low end with IA32. Where else than the high end
> can they position their new, incompatible architecture? Only later on
> there may be a place for low-end IA64.
>
> So the question is, really, why would IA64 in general, and Merced in
> particular, *not* come at least close to Alpha performance? Little as
> has been published on EPIC, can they not *at least* pull any
> implementation trick that is possible with Alpha? Would they really
> make stupid ISA design mistakes again, like with x86? This isn't the
> Intel of old days...
EPIC should offer architectural advantages over classic superscalar
RISCs with the same issue width. Some observers (MPR) have stated
that the advantage is on the order of 30-50% but I think this is a
bit optimistic. Anyone remember the old rule of thumb "RISC is 3-5
times faster than CISC in the same technology"? Obviously someone
forgot to tell the Intel P6 design team that a few years back :-O
An other aspect of this is that an architectural advantage is postulated
assuming that everything else is equal. Empirical evidence shows
otherwise how unwise the latter part is. All classic RISCs are rather
similar and one would not expect any particular one to a have a noticible
architectural advantage over the rest. Likewise, the range of semicon-
ductor processes available to RISC vendors are pretty comaprable too.
Yet one RISC, I'll call it brand "A", seems to maintain a significant
performance lead over all the others.
So perhaps the benefits of clever, innovative and inspired CPU design and
engineering carry some weight along with the architecture and process work.
Don't write off Alpha just because of world class hype about IA-64. Do
your part to tell Intel and its camp followers to FUD off ;-)
>
> (I'm playing devil's advocate here, for many reasons I would like to
> see Alpha survive.)
Me too. To paraphrase Gordon Gecko, Competition is good. Us consumers would
a lot worse off if the marketplace had Coke but not Pepsi, Boeing but not
Airbus, and the Detroit big 3 without the Japanese.
Likewise, computer users everywhere will be far better off with a 64 bit
marketplace that had IA-64 *and* Alpha rather than just IA-64.
Now if someone could just do something about Microsponge :-(
>
> - Reinoud
All opinions strictly my own (obviously)
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race
Kanata, Ontario to put more PRECISION and POWER into
dem...@mosaid.com architectures with MIPSed results but
PaulD...@EasyInternet.net ALPHA's well that ends well.
Paul Kahler
In comp.arch Steven Correll <s...@netcom.com> wrote:
: In article <63vg7g$p82$1...@news2.acs.oakland.edu>,
: Paul Kahler <phka...@oakland.edu> wrote:
: >...I'd really appreciate it :-) I'm using VC++ and a limited
: >amount of MFC, so with corresponding tools for Alpha, there should be
: >very little involved in porting.
: That's what I would have thought, too, but the consultant porting a large
: system for my employer from Intel NT to Alpha NT was immediately stymied
: when VC++ refused to load the project. Microsoft's suggested workaround was
: to re-enter all of the files (over 500 files in 100 directories) and reset
: all of the options by hand. I hope they've fixed the bug in the last year,
: or that you don't encounter it.
That's OK, my project is limited to 1 directory and about 20 files. I don't
spend my free time writing huge apps, just small proof of concept type
things :-) I'm pleased with what my K6-166 can do, but I'd be really excited
to see it on a 600MHz Alpha :-) Since it's very floating point intensive
shouldn't I expect much more than a 4x performance increase?
BTW, did your company try that suggested workaround? And what other issues
came up after that? Just wondering in case I do find access to an Alpha ;-)
Peter Mardahl
In article <3463E2...@EasyInternet.net>,
Paul DeMone <PaulD...@EasyInternet.net> wrote:
>R. Lamberts wrote:
> bit optimistic. Anyone remember the old rule of thumb "RISC is 3-5
> times faster than CISC in the same technology"? Obviously someone
> forgot to tell the Intel P6 design team that a few years back :-O
My understanding is that the P6 core is essentially a RISC, and that
the P6 "interprets" x86 code into the "internal" instruction set.
PeterM
John McCalpin
In article <3463E2...@EasyInternet.net>,
Paul DeMone <PaulD...@EasyInternet.net> wrote:
> performance lead over all the others.
Sure -- if you limit your sample space to codes where the Alpha is
faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
"discover" that the Alpha is faster.
However, it is important for comp.arch members to recognize that
this not true for large areas of application space, especially for
number-crunching sorts of jobs.
Every time I review the available applications performance data,
I see that we have a fairly tight race at the top. Normalizing
to the performance of an Origin2000 uniprocessor (195 MHz R10000,
130 MHz/4 MB L2 cache), the eyeballed averaged of engineering
application performance is something like:
vendor performance cpu system clock cache
--------------------------------------------------------------
DEC ~1.05 21164 4100 500 4 MB
SGI 1.0 R10000 Origin 195 4 MB
HP ~0.8 PA-8000 K-460 180 1+1 MB
Sun ~0.7 Ultra2 UE5002 250 2(?) MB
IBM ~0.7 P2SC SP 120 ???
Intel ~0.3 P6 various 200 512 kB ?
--------------------------------------------------------------
I apologize in advance for any minor errors -- I am typing this
from memory at home on a Saturday morning....
Very little data is available from the 625 MHz Alphas, the 236 MHz
PA-8200's, the 300 MHz Ultra2, or the 300 MHz PII --- but it is clear
from the SPEC results that we can expect relatively small changes in
performance here, and no change in the rankings. I *do* have
data for faster R10000's, but since we have not announced availability
yet....
Of course, it seems likely that the 21264 will change the picture
for a while -- but *historically* the performance advantage of
Alpha has been minor and entirely over-hyped.
Since this is comp.arch, we should all recite together:
"Computer performance is more than the cpu clock frequency"
"Computer performance is more than the cpu clock frequency"
"Computer performance is more than the cpu clock frequency"
"Computer performance is more than the cpu clock frequency"
"Computer performance is more than the cpu clock frequency"
"Computer performance is more than the cpu clock frequency"
Even better, we should all get in the habit of thinking about
*performance limiters* rather than *performance boosters".
It is typically the *weakest link* in the system that controls
application performance, and this can be any of:
CPU: speed
internal parallelism
latency tolerance
internal bottlenecks
Cache: size
bandwidth
latency
Memory: size
bandwidth
latency
I/O: connectivity
bandwidth
latency
network:bandwidth
latency
cpu overhead
applications:
availability
quality of ports
O/S: reliability
sophistication at effectively using hardware
internal bottlenecks
the list can go on, but the point is clear.
> Likewise, computer users everywhere will be far better off with a 64 bit
> marketplace that had IA-64 *and* Alpha rather than just IA-64.
The 64-bit marketplace has two players today -- SGI and DEC.
SGI has much larger market share in UNIX workstations (2x and
growing), mid-range servers (>3x) and HPC (>3.5x).
Of course Cray Research (a Silicon Graphics company) has been
shipping 64-bit hardware and software for over 20 years, though
few of us make enough money to own one of these personally.
Sun has 64-bit hardware, and clearly plans to release a 64-bit O/S.
HP has 64-bit hardware, and seems to be upgrading its O/S to 64-bit
in a staged fashion. IBM has 64-bit hardware, but I have not been
following them -- they may also do a 64-bit O/S.
Of course, the Intel behemoth may swamp/assimilate all of us, but
we already have a competitive 64-bit market, and one that will be
a lot richer with full 64-bit solutions before IA-64 becomes something
that you can take home.
--
--
John D. McCalpin, Ph.D. Supercomputing Performance Analyst
Technical Computing Group http://reality.sgi.com/mccalpin/
Silicon Graphics, Inc. mcca...@sgi.com 650-933-7407
Paul DeMone
John McCalpin wrote:
>
> In article <3463E2...@EasyInternet.net>,
> Paul DeMone <PaulD...@EasyInternet.net> wrote:
> > Yet one RISC, I'll call it brand "A", seems to maintain a significant
> > performance lead over all the others.
>
> Sure -- if you limit your sample space to codes where the Alpha is
> faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
> "discover" that the Alpha is faster.
>
> However, it is important for comp.arch members to recognize that
> this not true for large areas of application space, especially for
> number-crunching sorts of jobs.
*Some* types of number-crunching sort of jobs.
>
> Every time I review the available applications performance data,
> I see that we have a fairly tight race at the top. Normalizing
> to the performance of an Origin2000 uniprocessor (195 MHz R10000,
> 130 MHz/4 MB L2 cache), the eyeballed averaged of engineering
> application performance is something like:
What exactly is your set of engineering applications? No doubt
hand chosen from SGI marketing bumpf to put your current employer
in the most positive light?
BTW, I intensely despise the widely touted viewpoint that SPEC95
results are next to worthless. Why don't the vendors who currently
cannot come close to Alpha on SPECint95 (and have no advantage on
SPECfp95 despite much more expensive memory systems) spend half the
energy used deprecating SPEC to improving the integer capability
of their own chips instead? It certainly would help their competitive
position vs x86 NT workstation/servers for integer and *mildy FP
intensive* FP applications (i.e. most).
Now tell me, did DEC single handedly subvert the SPEC organization?
I was under the impression that SGI, Sun, IBM, and Motorola are all
members of SPEC. These guys helped set up the rules and select the
various programs. Now don't piss all over SPEC just because it shows
your chips in a less than superlative light.
Most engineering apps contain a major element of scalar integer
processing in them and typically aren't limited by the "supercomputer
extreme" end of the spectrum (important in its own right but don't
let the tail wag the dog) of pouring through huge data sets in main
memory performing one or two operations on each datum.
BTW, the latest issue of EET included an article that quoted someone who
evaluated workstations (for Motorola IIRC) who said the best simplified
method of comparing boxes for engineering apps is to take their SPEC95
scores and weight them 70% integer and 30% FP. The Alpha comes off
pretty good in this respect n'est pas?
Granted all that, I agree the 21164 device does not have a memory
bandwidth commensurate with the rest of the capabilities of this
device. DEC recognized this and has apparently put things right
in the 21264.
>
> vendor performance cpu system clock cache
> --------------------------------------------------------------
> DEC ~1.05 21164 4100 500 4 MB
> SGI 1.0 R10000 Origin 195 4 MB
> HP ~0.8 PA-8000 K-460 180 1+1 MB
> Sun ~0.7 Ultra2 UE5002 250 2(?) MB
> IBM ~0.7 P2SC SP 120 ???
> Intel ~0.3 P6 various 200 512 kB ?
> --------------------------------------------------------------
normalized comparison on what? executing/emulating MIPS IV
object code files? Do tell...
> I apologize in advance for any minor errors -- I am typing this
> from memory at home on a Saturday morning....
>
> Very little data is available from the 625 MHz Alphas, the 236 MHz
> PA-8200's, the 300 MHz Ultra2, or the 300 MHz PII --- but it is clear
> from the SPEC results that we can expect relatively small changes in
> performance here, and no change in the rankings. I *do* have
> data for faster R10000's, but since we have not announced availability
> yet....
Ahh, the Intel perfected "I'd tell you now but then I would have to
kill you" reply or maybe the Fred Pollack "wait for the next chip, it
will knock your socks off!" gem.
Seriously, I *do* hope SGI/MIPS introduces some hot new silicon soon;
I hate it when Intel creeps too close to integer parity with the high
end of any major RISC family.
>
> Of course, it seems likely that the 21264 will change the picture
> for a while -- but *historically* the performance advantage of
> Alpha has been minor and entirely over-hyped.
O H Y E S ! <forehead slap>
That's the problem with DEC and its Alpha CPU, it is overhyped!!!
I just cannot open a newspaper, trade rag, or turn on my TV without
being bombarded with Alpha ads ;-)
As for Alpha having minor performance advantage-
1) FP performance compared to other high end RISCs (esp PA-RISC)
- TRUE: leadership goes back and forth, back and forth...
2) integer performance compared to x86 and other RISCs
- FALSE: with a few noticably exceptions (0.35 um P6 intro)
Alpha has held a consistent integer lead, typically as high as
50%, occasionaly a lot more, over other RISC and x86 flagship
CPUs
Why is x86 creeping ever upwards despite its ludicrous FP capabilities?
Perhaps certain RISC vendors should put a nicely framed "Its the integer
stupid!" on the cubicle walls of its designers. However, at this stage
it is likely a moot point for some of these companies, given the CPU
design lead time and management leanings to shipping PII workstations :-(
>
> Since this is comp.arch, we should all recite together:
>
> "Computer performance is more than the cpu clock frequency"[snip]
> "Computer performance is more than the cpu clock frequency"
If my employer's high end chip in late 1997 was a 200 MHz RISC
processor (maybe 250, have NEC's 0.25 um R10Ks reached customers
yet?) I would want people chanting that too ;-)
How about chanting this for a while while waiting for a synopsis
compile, a place and route, a DRC/LVS run, or even a SPICE (nearly
90% integer) simulation:
"For computationally intensive scalar integer code CPU clock
frequency is damn important"
Cannot argue with that. All of these aspects are important for a
well balanced, useful, general purpose box.
> the list can go on, but the point is clear.
>
> > Likewise, computer users everywhere will be far better off with a 64 bit
> > marketplace that had IA-64 *and* Alpha rather than just IA-64.
>
> The 64-bit marketplace has two players today -- SGI and DEC.
> SGI has much larger market share in UNIX workstations (2x and
> growing), mid-range servers (>3x) and HPC (>3.5x).
Tricky, tricky stats! I guess Alpha boxes and desktops running NT
don't count because the operating system isn't currently 64 bits?
The hardware is still 64 bits nevertheless.
>
> Of course Cray Research (a Silicon Graphics company) has been
> shipping 64-bit hardware and software for over 20 years, though
> few of us make enough money to own one of these personally.
>
> Sun has 64-bit hardware, and clearly plans to release a 64-bit O/S.
> HP has 64-bit hardware, and seems to be upgrading its O/S to 64-bit
> in a staged fashion. IBM has 64-bit hardware, but I have not been
> following them -- they may also do a 64-bit O/S.
>
> Of course, the Intel behemoth may swamp/assimilate all of us, but
> we already have a competitive 64-bit market, and one that will be
> a lot richer with full 64-bit solutions before IA-64 becomes something
> that you can take home.
I agree, more the merrier.
> --
> --
> John D. McCalpin, Ph.D. Supercomputing Performance Analyst
> Technical Computing Group http://reality.sgi.com/mccalpin/
> Silicon Graphics, Inc. mcca...@sgi.com 650-933-7407
All opinions strictly my own (obviously)
BTW,
I have no material, professional, or other vested interest in the success
or failure of any given ISA other than an engineer's desire (although not
expectation) to see technical excellence prevail over marketing hype/anti-
competitive business practices and competition prevail over monopoly.
Zalman Stern
Paul DeMone (PaulD...@EasyInternet.net) wrote:
[Hammers John McCalpin.]
That SPEC95 does not adequately represent significant areas of applications
performance is not news. (Notably, SPEC is not testing memory
bandwidth/latency and I/O performance much.) Seems a little harsh to
crucify someone for suggesting looking at something other than SPEC.
It was pretty ridiculous for John to post the performace table with no
mention of what applications (or specific types of applications) it
involves. A cursory summary would have given the numbers a lot more
credibility.
For me, the line about faster chips amounted to "They've got faster clocks
coming out, we've got faster clocks coming out."
I expect the biggest win for the 21264 will be its memory performance.
Which is not to say its core is less than stellar, but if the early info is
true, many applications will get a lot more of the theoretically available
performance with the '264 than they did with the earlier Alphas. Note that
I see this as more being hard engineering than DEC just all of the sudden
deciding to care about memory bandwidth. (Price point may have a bit to do
with it too. 21264's are not low end :-)) (Note that the P2SC is a good
implementation to compare too. Its been doing well in many areas because of
its memory subsystem. Another lower clock rate example too.)
If there's been a single definite performance leader in recent history, its
been Alpha. (In fact I'd just simplify and say "Alpha held the performance
lead for the 1990s." Which has a few minor problems but is basically
true. I'm sure some will disagree. I'm assuming they already own 1998. 1990
is sort of conceeded by default. 1999 is up for grabs.)
-Z-
Bill Broadley
Paul DeMone <PaulD...@EasyInternet.net> wrote:
: What exactly is your set of engineering applications? No doubt
: hand chosen from SGI marketing bumpf to put your current employer
: in the most positive light?
Isn't that a bit harsh for an SGI rep that quotes his machines
5% behind Alpha?
For the longest time the highend for Digital/Sgi was:
SGI Origin2000 R10000 195 4M+32/32 9.48 19.0 Nov96 www.specb
DEC 500/500 A21164 48/500 8M+96+8/8 15.0 20.4 Aug96 Digital
5% seems like a pretty fair ballbark. Yes it's actually 7.36%, then again
the SGI has better memory bandwidth (stream), and better scalability.
SGI also posted what I believe is the highest specfp95 score so far 62.5
granted it was parallized across 8 cpu's.
Yes for those workloads that are more int the alpha has a bigger advantage.
SGI's seems to be alot more focused on HPC/floating point based scientific
apps, 3-d graphics. Not that they aren't trying to enter new markets.
: > vendor performance cpu system clock cache
: > --------------------------------------------------------------
: > DEC ~1.05 21164 4100 500 4 MB
: > SGI 1.0 R10000 Origin 195 4 MB
: > HP ~0.8 PA-8000 K-460 180 1+1 MB
: > Sun ~0.7 Ultra2 UE5002 250 2(?) MB
: > IBM ~0.7 P2SC SP 120 ???
: > Intel ~0.3 P6 various 200 512 kB ?
: > --------------------------------------------------------------
Lets keep in mind any generalization of floating point performance
in computers has a counter example, the above is very reasonable
for a generalization.
This chart looks a bit dated, and IMHO kinda surprisingly low
numbers for HP. I have an HP J282 which has higher specfp95 then
the origin 195 Mhz R10k, it's I believe 6 months old. HP's
got better specint, better specfp, and comparable but a bit lower
memory bandwidth. I also have a new 300 Mhz Ultra 2. But the above
chart fits specfp and my similiar benchmarks pretty close.
Very believeable for any kinda of floating point application.
Recent marketing talks about C240's (25 specfp95), and 4100/600's
with 8 mb caches which both reorganize the ordering for floating
point performance. I was quoted 12 weeks on the C240, and the 4100/533
was quoted by digital as their fastest rawhide just 3 weeks or so
ago.
I notice that even today:
http://www.digital.com/alphaserver/performance/4100_perf.html
Doesn't list the 600 Mhz 4100.
Hardly grounds for accusations of marketing motivated drivel...
: normalized comparison on what? executing/emulating MIPS IV
: object code files? Do tell...
Just about any floating point type app would be believeable.
: Ahh, the Intel perfected "I'd tell you now but then I would have to
: kill you" reply or maybe the Fred Pollack "wait for the next chip, it
: will knock your socks off!" gem.
Seems to be a favorite comment by the powerpc crowd, echoed at every
chip announcement back to and including the 601. Digital and HP have
both brought out cpu's and/or clock speeds since SGI hit 195 Mhz, it's
a game that changes leaders often, but more often then not it's Digital.
Again acknowledge in the above chart. Seems like Digital reacts rather
quickly, seems like new digital machines were announced within weeks
of the Pentium Pro that beat the 300 Mhz 21164, within weeks of HP hitting
20 specfp95, and within weeks of HP hitting 25 specfp95. I think in
many cases it was days.
: Seriously, I *do* hope SGI/MIPS introduces some hot new silicon soon;
: I hate it when Intel creeps too close to integer parity with the high
: end of any major RISC family.
Using your 0.7 int - 0.3 fp I get 10.565 for a $3k dell vs 12.336 for
an Origin 2000.
: 2) integer performance compared to x86 and other RISCs
: - FALSE: with a few noticably exceptions (0.35 um P6 intro)
: Alpha has held a consistent integer lead, typically as high as
: 50%, occasionaly a lot more, over other RISC and x86 flagship
: CPUs
Well today it's like 4.29 % (hmmm less then 5%). (vs c240)
: Tricky, tricky stats! I guess Alpha boxes and desktops running NT
: don't count because the operating system isn't currently 64 bits?
: The hardware is still 64 bits nevertheless.
I think few people decide to buy machines because they are 64 bit despite
32 bit environments. Comp.arch is one thing, selling to a market is
another.
: > Of course, the Intel behemoth may swamp/assimilate all of us, but
: > we already have a competitive 64-bit market, and one that will be
: > a lot richer with full 64-bit solutions before IA-64 becomes something
: > that you can take home.
: I agree, more the merrier.
Well today you can take home a 64 bit machine with a 64 bit os for $1900
less monitor. I'd love for there to be an option besides a 21164pc+linux,
but for now it's pretty good. To bad sgi's going with Intel on the low end
which removes much value added except maybe a killer 3-d card. Maybe SGI
will transform itself into a 3d video card company for pc's.
Seems like digitals delivering IMHO what the O2 promised, affordable 64
bit computing that you can afford to take home.
--
Bill Broadley Bi...@math.ucdavis.edu UCD Math Sys-Admin
Linux is great. http://math.ucdavis.edu/~bill PGP-ok
John McCalpin
In article <3464DD...@EasyInternet.net>,
Paul DeMone <PaulD...@EasyInternet.net> wrote:
>John McCalpin wrote:
>>
>> However, it is important for comp.arch members to recognize that
>> this not true for large areas of application space, especially for
>> number-crunching sorts of jobs.
>
> *Some* types of number-crunching sort of jobs.
Yes, but categorization is difficult.
>> Every time I review the available applications performance data,
>> I see that we have a fairly tight race at the top.
>
> What exactly is your set of engineering applications? No doubt
> hand chosen from SGI marketing bumpf to put your current employer
> in the most positive light?
The set was "hand-picked" to include all the published data that
I can find for third-party engineering applications run on competitors
systems that are close to current. The test set included ABAQUS
Explicit, ABAQUS Standard, ANSYS, MSC/NASTRAN, FIDAP, and the NCAR
CCM2 climate model. I have some additional data in-house, but
is is all under NDA's from the software vendors, so I can hardly
post it here. I do not believe that the "secret" data changes the
basic ranking.
The one data point that I deliberately omitted was for a petroleum
reservoir model that looks pretty good on the IBM SP (about 1.1 times
as fast as the Origin2000), and which if included would raise the P2SC
average a bit. I omitted it because, although accurate and important
to people in the oil industry, I do not think that this code is used
outside of that fairly narrow area.
If you have any suggestions on where to find more appropriate data,
I am all ears.... Insulting my integrity is not going to help anyone
understand the issues better.
> BTW, I intensely despise the widely touted viewpoint that SPEC95
> results are next to worthless.
It is certainly a widely held opinion. I do not know any workloads
that correlate well with SPECint95 (which is no surprise, given what I
actually look at for a living), but SPECfp95 is the best single
predictor of *mean* application performance that I am aware of. It
still has some systematic errors, but these are in the 10-20% range,
which is easy enough to ignore. SPEC95 falls short in representing
throughput on large servers (in part) because it ignores the I/O
component, but since this bias is acknowledged up front, it is not a
fundamental problem.
>> vendor performance cpu system clock cache
>> --------------------------------------------------------------
>> DEC ~1.05 21164 4100 500 4 MB
>> SGI 1.0 R10000 Origin 195 4 MB
>> HP ~0.8 PA-8000 K-460 180 1+1 MB
>> Sun ~0.7 Ultra2 UE5002 250 2(?) MB
>> IBM ~0.7 P2SC SP 120 ???
>> Intel ~0.3 P6 various 200 512 kB ?
>> --------------------------------------------------------------
>
> normalized comparison on what? executing/emulating MIPS IV
> object code files? Do tell...
The comparison is for the performance on the standard benchmark sets
for ABAQUS Explicit, ABAQUS Standard, a benchmark problem for ANSYS,
a set of benchmarks for MSC/NASTRAN, a small set of benchmarks for
FIDAP, and the NCAR CCM2 climate model.
Since I do get paid by SGI, I should point out that the SGI machines
traditionally do better relative to the competition as the problem
sizes increase beyond those used in these simple benchmarks.
>> I *do* have
>> data for faster R10000's, but since we have not announced availability
>> yet....
>
> Ahh, the Intel perfected "I'd tell you now but then I would have to
> kill you" reply or maybe the Fred Pollack "wait for the next chip, it
> will knock your socks off!" gem.
I suppose some people don't recognize integrity unless it bites them.
Since I do not have data for the HP, DEC, and Intel cpus that have
started shipping in the last month or few, it hardly seems fair to
present SGI data on machines that we will not ship for a little while
yet.
> O H Y E S ! <forehead slap>
>
> That's the problem with DEC and its Alpha CPU, it is overhyped!!!
It is not a problem with either DEC or Alpha -- it is a problem for
people trying to get an objective understanding of the relevant issues
in computer performance modelling.
> Why is x86 creeping ever upwards despite its ludicrous FP capabilities?
software availability ==> volume ==> "good enough" displaces "better"
>> The 64-bit marketplace has two players today -- SGI and DEC.
>> SGI has much larger market share in UNIX workstations (2x and
>> growing), mid-range servers (>3x) and HPC (>3.5x).
>
> Tricky, tricky stats! I guess Alpha boxes and desktops running NT
> don't count because the operating system isn't currently 64 bits?
> The hardware is still 64 bits nevertheless.
Hardware does not do very much for you without software, and
in particular, 64-bit hardware with 32-bit OS limitations is
effectively a 32-bit system as far as the user is concerned.
I don't know the status of 64-bit NT on Alpha -- does it exist yet?
What about LINUX and VMS?
>I have no material, professional, or other vested interest in the success
>or failure of any given ISA other than an engineer's desire (although not
>expectation) to see technical excellence prevail over marketing hype/anti-
>competitive business practices and competition prevail over monopoly.
It would be nice, wouldn't it.... I won't hold my breath....
Serge Pachkovsky
Glenn C. Everhart (ever...@gce.com.gov) wrote:
: Also, of course, it will be possible to use VMS Galaxies to run lots of them
: at once at levels way beyond what anyone is going to have much luck
: working with using SMP techniques. (Your OS is going to do 50 way SMP??
: Good luck!)
Sorry, but IRIX does it *right* *now* on bigger Origin 2000's.
/Serge.P
--
Russian guy from the Zurich university...
Zalman Stern
Peter Mardahl (pet...@maxwell.EECS.Berkeley.EDUNOSPAM) wrote:
: My understanding is that the P6 core is essentially a RISC, and that
: the P6 "interprets" x86 code into the "internal" instruction set.
Seems if lies get posted often enough, even I get tired of correcting
them. Let it be so...
-Z-
Paul DeMone
John McCalpin wrote:
>
> In article <3464DD...@EasyInternet.net>,
> >> I see that we have a fairly tight race at the top.
> >
> > What exactly is your set of engineering applications? No doubt
> > hand chosen from SGI marketing bumpf to put your current employer
> > in the most positive light?
>
> The set was "hand-picked" to include all the published data that
> I can find for third-party engineering applications run on competitors
> systems that are close to current. The test set included ABAQUS
> Explicit, ABAQUS Standard, ANSYS, MSC/NASTRAN, FIDAP, and the NCAR
> CCM2 climate model. I have some additional data in-house, but
> is is all under NDA's from the software vendors, so I can hardly
> post it here. I do not believe that the "secret" data changes the
> basic ranking.
Thank you for clarifying that. I presume your final single datum
was a geometric mean with equal weighting to each application?
>
> The one data point that I deliberately omitted was for a petroleum
> reservoir model that looks pretty good on the IBM SP (about 1.1 times
> as fast as the Origin2000), and which if included would raise the P2SC
> average a bit. I omitted it because, although accurate and important
> to people in the oil industry, I do not think that this code is used
> outside of that fairly narrow area.
>
> If you have any suggestions on where to find more appropriate data,
> I am all ears.... Insulting my integrity is not going to help anyone
> understand the issues better.
My appologies if you feel your integrity questioned. I was more
concerned with calling you to task for throwing out a benchmark
result ranking a 500 MHz 21164 as 5% faster than a 195 MHz R10K
without clarifying what that benchmark consisted of, particularly
when most other objective observers would place the performance
of the Alpha well ahead of the R10K for most applications.
[snip]
> >> I *do* have
> >> data for faster R10000's, but since we have not announced availability
> >> yet....
> >
> > Ahh, the Intel perfected "I'd tell you now but then I would have to
> > kill you" reply or maybe the Fred Pollack "wait for the next chip, it
> > will knock your socks off!" gem.
>
> I suppose some people don't recognize integrity unless it bites them.
Perhaps integrity would be better served by basing arguments on the
fastest machines shipping now rather than alluding to some mysterious
hot box or hot chip that hasn't seen the light of day.
>
> Since I do not have data for the HP, DEC, and Intel cpus that have
> started shipping in the last month or few, it hardly seems fair to
> present SGI data on machines that we will not ship for a little while
> yet.
Fair enough, deal with is what is shipping now. Comparing vapour to
vapour is a losing game.
>
> > O H Y E S ! <forehead slap>
> >
> > That's the problem with DEC and its Alpha CPU, it is overhyped!!!
>
> It is not a problem with either DEC or Alpha -- it is a problem for
> people trying to get an objective understanding of the relevant issues
> in computer performance modelling.
And one important aspect of this understanding is that the scalar
integer performance of a CPU is important for even most applications
that are considered FP intensive. Many RISC designs shipping now are
unbalanced in this regards with stunted integer capability compared
to their FP performance.
[snip]
> --
> --
> John D. McCalpin, Ph.D. Supercomputing Performance Analyst
> Technical Computing Group http://reality.sgi.com/mccalpin/
> Silicon Graphics, Inc. mcca...@sgi.com 650-933-7407
--
Paul DeMone
Bill Broadley wrote:
[snip]
>
> : 2) integer performance compared to x86 and other RISCs
>
> : - FALSE: with a few noticably exceptions (0.35 um P6 intro)
> : Alpha has held a consistent integer lead, typically as high as
> : 50%, occasionaly a lot more, over other RISC and x86 flagship
> : CPUs
>
> Well today it's like 4.29 % (hmmm less then 5%). (vs c240)
Well if you want to compare with the spanking new C240 why not try
the latest Alpha results of 18.8 SPECint95 (AS 4100 IIRC); this
gives 8.7% advantage. This is well below the typical Alpha advantage.
and is due to HP's bringing up its integer performance with an unusually
large delta as well as DEC's several month slip with the 21264. Early
next year the usual pattern will likely resume.
>
> : Tricky, tricky stats! I guess Alpha boxes and desktops running NT
> : don't count because the operating system isn't currently 64 bits?
> : The hardware is still 64 bits nevertheless.
>
> I think few people decide to buy machines because they are 64 bit despite
> 32 bit environments. Comp.arch is one thing, selling to a market is
> another.
A 64 bit hardware installed base running a 32 bit OS is just a CDROM
away from being a 64 bit environment in all respects. This is a lot
different from a 32 bit hardware base that would require board or
box swaps to upgrade. Most customers understand the difference.
>
> : > Of course, the Intel behemoth may swamp/assimilate all of us, but
> : > we already have a competitive 64-bit market, and one that will be
> : > a lot richer with full 64-bit solutions before IA-64 becomes something
> : > that you can take home.
>
> : I agree, more the merrier.
>
> Well today you can take home a 64 bit machine with a 64 bit os for $1900
> less monitor. I'd love for there to be an option besides a 21164pc+linux,
> but for now it's pretty good. To bad sgi's going with Intel on the low end
> which removes much value added except maybe a killer 3-d card. Maybe SGI
> will transform itself into a 3d video card company for pc's.
Great! just what the world needs, another 3D chip/board supplier. What
are we up to now, 40 or so? SGI's name would be a powerful brand but
it is questionable if SGI's corporate climate could adapt to the cost
structure needed to survive in this market. Of course their MIPS
subsidiary did an excellent engineering job on the $150 Nintendo
64, but then again it wasn't up to SGI to manufacture them ;-)
>
> Seems like digitals delivering IMHO what the O2 promised, affordable 64
> bit computing that you can afford to take home.
>
> --
> Bill Broadley Bi...@math.ucdavis.edu UCD Math Sys-Admin
> Linux is great. http://math.ucdavis.edu/~bill PGP-ok
--
Paul DeMone
Zalman Stern wrote:
>
> Paul DeMone (PaulD...@EasyInternet.net) wrote:
> [Hammers John McCalpin.]
Yikes!
>
> That SPEC95 does not adequately represent significant areas of applications
> performance is not news. (Notably, SPEC is not testing memory
> bandwidth/latency and I/O performance much.) Seems a little harsh to
Testing I/O wasn't an objective but the stated justification of the SPEC
organization in replacing the SPEC92 suite with SPEC95 was to stress
the memory subsystem and reduce misleading results from small but fast
caches. Given the rapid pace of advances in cache size, application
and data set size, and main memory size, the SPEC suite has a relatively
short useful lifespan. Perhaps SPEC98 could include measures to ensure
a more distant "best before" date.
Those who complained bitterly about how misleading SPEC is should be
the first in line with new code and suggestions how to better represent
their little corner of the computing universe.
> crucify someone for suggesting looking at something other than SPEC.
No, I didn't "crucify" Mr. McCalpin for suggesting something other
than SPEC. But to paraphrase the old aphorism about democracy, SPEC95
is the worst benchmark for technical computing - except for all the rest.
Given its open, multilateral derivation with the participation of most
major computer companies, including Mr McCalpin's current employer, I
would suggest that an unnamed benchmark suite pulled out of his hat is
not justification to overturn SPEC-based relative performance ratings
and indeed its very use is objectionable.
>
> It was pretty ridiculous for John to post the performace table with no
> mention of what applications (or specific types of applications) it
> involves. A cursory summary would have given the numbers a lot more
> credibility.
I strongly agree.
>
> For me, the line about faster chips amounted to "They've got faster clocks
> coming out, we've got faster clocks coming out."
>
> I expect the biggest win for the 21264 will be its memory performance.
> Which is not to say its core is less than stellar, but if the early info is
> true, many applications will get a lot more of the theoretically available
> performance with the '264 than they did with the earlier Alphas. Note that
> I see this as more being hard engineering than DEC just all of the sudden
> deciding to care about memory bandwidth. (Price point may have a bit to do
> with it too. 21264's are not low end :-)) (Note that the P2SC is a good
From what I have seen of what it is going to compete against it, at least
in the technical computing arena, the 21264 could indeed be one of the
lowest cost options (particularly with a shrink to a comparable process).
> implementation to compare too. Its been doing well in many areas because of
> its memory subsystem. Another lower clock rate example too.)
>
> If there's been a single definite performance leader in recent history, its
> been Alpha. (In fact I'd just simplify and say "Alpha held the performance
> lead for the 1990s." Which has a few minor problems but is basically
> true. I'm sure some will disagree. I'm assuming they already own 1998. 1990
> is sort of conceeded by default. 1999 is up for grabs.)
At the Microprocessor Forum Intel seemed to almost downplay the performance
of the first IA-64 device (Merced) in deference to the followup chip. If
people are expecting Intel to depose Alpha as performance king perhaps the
true battle won't start until 2001. For the others, HP, Sun and IBM all have
good stories on how they will keep up. As for SGI/MIPS, I am afraid their
roadmap looks a bit bumpy until past year 2000.
Seeing how all this plays out is one of my favourite spectator sports (or
maybe soap opera is more appropriate ;-) Regardless, the ongoing bitter
rivalry and competition cannot help but be good news for users and buyers
of technical computing hardware whoever they chose.
>
> -Z-
Chris Morgan
Paul DeMone <PaulD...@EasyInternet.net> writes:
Of course their MIPS
> subsidiary did an excellent engineering job on the $150 Nintendo
> 64, but then again it wasn't up to SGI to manufacture them ;-)
I thought $150 was just the deposit and you paid the rest in
installments every time you buy a cartridge?
Chris
--
"everything remotely enjoyable turns out to be
powerfully addictive and expensive and bad for you"
- Lizzy Bryant
Larry Kilgallen
In article <borsom-0411...@bos-ma11-24.ix.netcom.com>, bor...@ix.netcom.com (Douglas H. Borsom) writes:
> Well, the fact that Sun is fabless doesn't seem to have hurt confidence
> in SPARC. Many analysts predict that more and more companies will follow
> a similar path and go fabless.
Those analysts must be wrong. How can "more and more" system companies
go FABless when IBM seems to be the only one left with a FAB ?
(Corrections to add other current FABfull system vendors are welcome.)
Larry Kilgallen
Peter Mayne
On 7 Nov 1997 21:34:39 GMT, phka...@oakland.edu (Paul Kahler) wrote:
>BTW, did your company try that suggested workaround? And what other issues
>came up after that? Just wondering in case I do find access to an Alpha ;-)
If you develop on an x86 system, the project won't have an Alpha
target (unsurprisingly). When you copy the files to an Alpha, create
an Alpha project based on an existing x86 project (takes about 20
seconds) and hit the build button.
Microsoft come up with the strangest solutions sometimes. 8-)
PJDM
Digital Equipment Corporation (Australia), Canberra, ACT
-------------------------------------------------------------------------------
These are my opinions, and have nothing to do with Digital.
This was edited by a wheelbarrow full of walruses.
Paul DeMone
Nick Maclaren wrote:
>
> In article <01bced23$5040e600$LocalHost@bengtl>,
> Bengt Larsson <ben...@maths.lth.se> wrote:[snip]
> >Well, personally I think the "It's the bandwidth, stupid" campaign
> >has been almost too successful. I've seen people like Andrew
> >Harrison, of Sun, argue in comp.benchmarks that their machine
> >had higher Stream bandwidth than some other machine and therefore
> >it must be much better. Really, that kind of simplification
> >doesn't help things either.
>
> Yes, quite! My pet hobby-horse ("it's the latency") is now being taken
> very seriously by chip designers, after years and years of the dogma
> that bigger caches solve everything. But Email from some designers
> indicates that the REALLY look-ahead ones are now considering problems
> that will arise after both the bandwidth and latency problems have been
> reduced :-)
The big problem down the road is thermal management. What is the point
where single die CPU power dissipation induces excessive system level
costs or forces system level components to be spaced apart more widely
than desirable? Is 100 W the knee in the curve above which system cost
spirals upwards?
For some parts of the embedded CPU market, namely those targeted for
battery powered devices, MIPs/W (for whatever a MIPs is worth, but that
is a thread for another day) is now an important metric. Maybe in a few
years the crucial measurement of an ISA/microarchitecture/process design
point will be its SPECintXX/W or SPECfpXX/W as this might limit the clock
frequency for a cost effective, competitive box.
It is interesting to consider how such a design criteria would apply to
IA-64 devices as opposed to wide issue superscalar implementations of
classic RISC ISAs. Maybe throwing out millions of transistors of instr-
uction issue/execution dependency checking logic (which essentially does
no useful work on its own) unneeded in an EPIC CPU will be an important
contribution to its computational thermal efficiency. OTOH, maybe an EPIC
CPU gets burned (excuse the pun) by power consumed by predicated instruct-
ions that get issued, executed, but whose results gets discarded in the
writeback pipestage (assuming the predicate is calculated too late to
perform an early abort of a falsely predicated instructions).
In general, the thermal issue might put a whole different spin on the
value of different degrees and types of speculative execution if power
dissipation ultimately caps clock frequency instead of critical path delay.
[snip]
> Nick Maclaren,
> University of Cambridge Computer Laboratory,
> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
> Email: nm...@cam.ac.uk
> Tel.: +44 1223 334761 Fax: +44 1223 334679
All opinions strictly my own.
Doug Siebert
Paul DeMone <PaulD...@EasyInternet.net> writes:
> Well if you want to compare with the spanking new C240 why not try
> the latest Alpha results of 18.8 SPECint95 (AS 4100 IIRC); this
> gives 8.7% advantage. This is well below the typical Alpha advantage.
> and is due to HP's bringing up its integer performance with an unusually
> large delta as well as DEC's several month slip with the 21264. Early
> next year the usual pattern will likely resume.
HP's got the PA-8500 in H1 '98, I don't think it will be as fast as the
21264, but it will probably be close. Plus it will be the first PA-8000
series chip designed for the entire PA product line, so it won't take too
long after its introduction before even the low end of the HP product
line carries this chip. How long will Digital's low end product line be
using the 21164? I think the low end is getting more and more important
in keeping volumes up against the invasion of NT & Linux running on cheap
but quite fast for integer work x86 hardware.
Bengt Larsson
John McCalpin <mcca...@frakir.engr.sgi.com> wrote in
<6424p7$n2f$1...@murrow.corp.sgi.com>...
> In article <3463E2...@EasyInternet.net>,
> Paul DeMone <PaulD...@EasyInternet.net> wrote:
> > Yet one RISC, I'll call it brand "A", seems to maintain a significant
> > performance lead over all the others.
>
> Sure -- if you limit your sample space to codes where the Alpha is
> faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
> "discover" that the Alpha is faster.
>
> this not true for large areas of application space, especially for
> number-crunching sorts of jobs.
Well, personally I think the "It's the bandwidth, stupid" campaign
has been almost too successful. I've seen people like Andrew
Harrison, of Sun, argue in comp.benchmarks that their machine
had higher Stream bandwidth than some other machine
and therefore it must be much better. Really, that kind of simplification
doesn't help things either.
Characterizing performance by any single number (you mention
SPECfp95 as good in a later message) is, however you do it, a gross
simplification. It doesn't matter what the number actually is,
nor does it matter what it measures (unless of course it is your
real application).
As any statistician knows, correlation does not mean causation.
Even if SPECfp95 correlates with the performance of your own application
that doesn't mean that they have anything in common. It may be likely,
but you don't know.
What I mean is that you can't gain _understanding_ of performance
by juggling composite benchmark numbers, or by combining them.
> Of course, it seems likely that the 21264 will change the picture
> for a while -- but *historically* the performance advantage of
> Alpha has been minor and entirely over-hyped.
Well, I don't know about that. It hasn't been as important
in the market as DEC likely would have wanted. Performance
isn't everything (even real, honest-to-God performance, or price/
performance, on your own application).
John McCalpin
In article <346556...@EasyInternet.net>,
Paul DeMone <PaulD...@EasyInternet.net> wrote:
>John McCalpin wrote:
>>
>> In article <3464DD...@EasyInternet.net>,
>> >> I see that we have a fairly tight race at the top.
>> >
>> > What exactly is your set of engineering applications?
>>
>> I can find for third-party engineering applications run on competitors
>> systems that are close to current.
>
> was a geometric mean with equal weighting to each application?
Yes -- each code's tests were first averaged (when there was more
than one number), and then I averaged across the available codes.
Not all codes were available for all cases, but there were 3-4
for each system.
The scatter in the data was about +/- 20% relative to each mean.
Given the small number of data points, it is appropriate to
consider the mean to be rather fuzzy.....
> Perhaps integrity would be better served by basing arguments on the
> fastest machines shipping now rather than alluding to some mysterious
> hot box or hot chip that hasn't seen the light of day.
Just because a vendor has announced a box and submitted SPEC results
does not mean that third-party engineering software vendors have them
in hand, have completed certifying their applications, and have
published the benchmark results. This really does take quite a few
months --- there are very few results available even for the "almost"
current machines that I listed, and none at all for the newest machines
that are "shipping now" (PA-8200, 21164@625, PentiumII, Ultra2@300, etc).
Nick Maclaren
>> Paul DeMone <PaulD...@EasyInternet.net> wrote:
>> > Yet one RISC, I'll call it brand "A", seems to maintain a significant
>> > performance lead over all the others.
>>
>> Sure -- if you limit your sample space to codes where the Alpha is
>> faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
>> "discover" that the Alpha is faster.
>>
>> However, it is important for comp.arch members to recognize that
>> this not true for large areas of application space, especially for
>> number-crunching sorts of jobs.
>
>Well, personally I think the "It's the bandwidth, stupid" campaign
>has been almost too successful. I've seen people like Andrew
>Harrison, of Sun, argue in comp.benchmarks that their machine
>had higher Stream bandwidth than some other machine and therefore
>it must be much better. Really, that kind of simplification
>doesn't help things either.
Yes, quite! My pet hobby-horse ("it's the latency") is now being taken
very seriously by chip designers, after years and years of the dogma
that bigger caches solve everything. But Email from some designers
indicates that the REALLY look-ahead ones are now considering problems
that will arise after both the bandwidth and latency problems have been
reduced :-)
>Characterizing performance by any single number (you mention
>SPECfp95 as good in a later message) is, however you do it, a gross
>simplification. It doesn't matter what the number actually is,
>nor does it matter what it measures (unless of course it is your
>real application).
And, even then, it is data dependent. Plenty of applications are CPU
limited on some sizes or classes of data, and memory limited on others.
So even 'appropriate' benchmarks can be misleading.
>> Of course, it seems likely that the 21264 will change the picture
>> for a while -- but *historically* the performance advantage of
>> Alpha has been minor and entirely over-hyped.
>
>Well, I don't know about that. It hasn't been as important
>in the market as DEC likely would have wanted. Performance
>isn't everything (even real, honest-to-God performance, or price/
>performance, on your own application).
Part of the problem is that many (or even most) of the limiting codes
are so unspeakable and uncontrollable that few people even try to
benchmark them. X Windows and NFS servers are examples. You CAN try
some standard benchmarks, but they don't correlate very well with real
life (because of the data dependence mentioned above).
So a lot of customers in both commerce and academia operate by buying
and arbitrary configuration, and either upgrading it or replicating it
if it isn't man enough for the job. Which leads to the attitude of
getting another one of what we know, rather than the best available.
Paul DeMone
Chris Morgan wrote:
>
> Paul DeMone <PaulD...@EasyInternet.net> writes:
>
> Of course their MIPS
> > subsidiary did an excellent engineering job on the $150 Nintendo
> > 64, but then again it wasn't up to SGI to manufacture them ;-)
>
> I thought $150 was just the deposit and you paid the rest in
> installments every time you buy a cartridge?
Nicely put.
Some observers believe Nintendo actually loses money on each N64 console
sale but makes up the difference in licensing whatever IP is used to
make the ROM cartridges proprietary.
I guess an aggressive competitor with deep pockets could just keeping
buying up N64 consoles for landfill until Nintendo went out of business ;-)
>
> Chris
>
> --
> "everything remotely enjoyable turns out to be
> powerfully addictive and expensive and bad for you"
> - Lizzy Bryant
--
Andrew Harrison SUNUK Consultancy
Bengt Larsson wrote:
> John McCalpin <mcca...@frakir.engr.sgi.com> wrote in
> <6424p7$n2f$1...@murrow.corp.sgi.com>...
> > In article <3463E2...@EasyInternet.net>,
> > Paul DeMone <PaulD...@EasyInternet.net> wrote:
> > > Yet one RISC, I'll call it brand "A", seems to maintain a significant
> > > performance lead over all the others.
> >
> > Sure -- if you limit your sample space to codes where the Alpha is
> > faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
> > "discover" that the Alpha is faster.
> >
> > However, it is important for comp.arch members to recognize that
> > this not true for large areas of application space, especially for
> > number-crunching sorts of jobs.
>
> Well, personally I think the "It's the bandwidth, stupid" campaign
> has been almost too successful. I've seen people like Andrew
> Harrison, of Sun, argue in comp.benchmarks that their machine
> had higher Stream bandwidth than some other machine
> and therefore it must be much better. Really, that kind of simplification
> doesn't help things either.
>
No I don't think I have ever argued this, throughput is important, latency
isalso important. Streams performance for instance is not a good predictor
of TPC-C performance, TPC-C is not always a good predictor of real
world DBMS application performance.
However if you have a high throughput low latency system you are likely
to be in a better possition than a low throughput high latency system.
Bandwidth does become a real issue for things like Data Warehouse
applications where full table scans are being run against large tables
since bandwidth can directly effect disk read performance (all other
things like FS being equal).
> Characterizing performance by any single number (you mention
> SPECfp95 as good in a later message) is, however you do it, a gross
> simplification. It doesn't matter what the number actually is,
> nor does it matter what it measures (unless of course it is your
> real application).
>
> As any statistician knows, correlation does not mean causation.
> Even if SPECfp95 correlates with the performance of your own application
> that doesn't mean that they have anything in common. It may be likely,
> but you don't know.
>
> What I mean is that you can't gain _understanding_ of performance
> by juggling composite benchmark numbers, or by combining them.
>
> > Of course, it seems likely that the 21264 will change the picture
> > for a while -- but *historically* the performance advantage of
> > Alpha has been minor and entirely over-hyped.
>
> Well, I don't know about that. It hasn't been as important
> in the market as DEC likely would have wanted. Performance
> isn't everything (even real, honest-to-God performance, or price/
> performance, on your own application).
The 21264 may change the picture but only if Digital match it with a
decent low latency high throughput backplane, the TurboLaser does
not really fit the bill.
Regards
Andrew Harrison
Senior Consultant SunUK
Steve Loughran
Peter Mardahl wrote:
>
> In article <63q5vl$s0v$1...@msunews.cl.msu.edu>,
> Mark W Brehob <bre...@cps.msu.edu> wrote:
>
> >You know that a significant portion of software _ships_ in with no
> >optimization and debug turned on? Software writers find their programs
> >break with debug off and finding the bugs is a pain. Time-to-Market.
If you are competing on a TTM basis against competitors for whom quality
is priority #237, and performance somewhere below that, then code
performance is often sacrificed. It isn't just a matter of turning on
max optimisations after all, but profiling the app and QA-ing the output
of the optimiser. That can be pretty time consuming, and hard to justify
holding up an app which is otherwise "ready"
> >I'm still disbelieving that too many folks will ship products with -O3
> >or whatever is "safe". Just turning off debug breaks code.
>
> Well, in my experience, the usual case is that the software
> was broken, and that having debug on/no optimization just hid the bugs, not
> that turning debug off/optimization on caused bugs.
You must have been lucky and not had to ship C/C++ code built with the
initial version of Microsoft Visual Studio 97: the "aggressive" floating
point opimiser could generate code that simply wouldn't work -and on one
app I found it simply failed to generate whole chunks of code. Although
fixed by service pack 1, I ended up having to keep a copy of the
previous compiler around to generate the release builds until that
service pack was available and I'd QA'd it.
Incidentally, this compiler still doesn't unroll loops, showing that
someone has chosen a different set of "aggressive" optimisations from
classic workstation compilers. But funnily enough, the WinCE cross
compiler for MIPS does...
-Steve
--
Steve Loughran, HP Labs, UK
http://www-uk.hpl.hp.com/people/slo/
Andrew Duane USG/PE
In article <zalmanEJ...@netcom.com> zal...@netcom.com (Zalman Stern) writes:
>Intel spends a lot more money than DEC does sending engineers to ISVs to
>tune the performance of apps for their archtiecture. They come in with a
>double whammy of engineering talent (some stunning, some not so) and
>marketing "attention" that enables and motivates developers to do the best
>possible job on the Intel platform. As with anything else, sometimes it
>works, sometimes it doesn't. But no other CPU vendor puts in that kind of
>effort.
Do you have figures for both companies?
I can't speak for Intel, but I know Digital spends quite a bit of
time and money sending engineers to customer sites to tune, improve,
and adapt code that "should" perform better.
It's just that the OS groups do it, not the Semiconductor group.
BTDT, with several customers.
--
Andrew L. Duane (JOT-7) du...@zk3.dec.com
Digital Equipment Corporation (603)-884-1294
110 Spit Brook Road
M/S ZKO3-3/U14
Nashua, NH 03062-2698
Del Cecchi
In article <6424p7$n2f$1...@murrow.corp.sgi.com>, mcca...@frakir.engr.sgi.com (John McCalpin) writes:
[mungo snip]
|> IBM has 64-bit hardware, but I have not been
|> following them -- they may also do a 64-bit O/S.
IBM has two (2) 64 bit os's. OS/400 has been out for quite a while and AIX 4.3.
Or are you one of those folks for whom the words "Operating System" == UNIX. :-)
|>
|> Of course, the Intel behemoth may swamp/assimilate all of us, but
|> we already have a competitive 64-bit market, and one that will be
|> a lot richer with full 64-bit solutions before IA-64 becomes something
|> that you can take home.
And with DEC porting Ultix, and HP porting HPUX and MPE......
"Who's afraid of the big bad wolf?"
"Who's afraid of the big bad wolf?"
"Who's afraid of the big bad wolf?"
|> --
|> --
|> John D. McCalpin, Ph.D. Supercomputing Performance Analyst
|> Technical Computing Group http://reality.sgi.com/mccalpin/
|> Silicon Graphics, Inc. mcca...@sgi.com 650-933-7407
--
Del Cecchi
Personal Opinions Only.
John Hascall
Paul DeMone <PaulD...@EasyInternet.net> wrote:
} The big problem down the road is thermal management. ...
I'm still betting on it being microwave shielding... :)
John
--
John Hascall, Software Engr. Shut up, be happy. The conveniences you
ISU Computation Center demanded are now mandatory. -Jello Biafra
mailto:jo...@iastate.edu
http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
Aaron Spink
Bill Broadley <bi...@math.ucdavis.edu> writes:
> For the longest time the highend for Digital/Sgi was:
> SGI Origin2000 R10000 195 4M+32/32 9.48 19.0 Nov96 www.specb
> DEC 500/500 A21164 48/500 8M+96+8/8 15.0 20.4 Aug96 Digital
Well, being a 2-3 months earlier with a machine that costs a lot less
has to account for something. :)
> SGI also posted what I believe is the highest specfp95 score so far 62.5
> granted it was parallized across 8 cpu's.
>
Not according to www.specbench.org which is the Authority on Spec95.
The fastest 10+ multi CPU results are all alpha as well as the fastest
single FP result which is ~15% faster than the next closest which is
a HP 8200 @ 236Mhz.
aaron spink
not speaking for dec
and yes I might be biased.
Philip Vitale
> (John D. McCalpin)
> IBM has 64-bit hardware, but I have not been
> following them
IBM has been shipping 64-bit PowerAS processors in the AS/400 series
for two years now.
An overview of the early PowerAS processors (A10 and A30) appeared
in the July 31, 1995 issue of Microprocessor Report.
The latest PowerAS processor (that is shipping) is the A35. A twelve
processor system based on the A35 was audited at 25,149 tpmC.
> -- [IBM] may also do a 64-bit O/S.
OS/400 for the PowerAS shipped two years ago, and is a full-fledged
64-bit operating system. (The AS/400 series also ships with a 64-bit
version of DB2.)
Beyond supporting 64-bit system code, OS/400 applications that were
originally developed and compiled on CISC platforms can make full use
of the capabilities offered by the PowerAS processors--(including
expanded addressing)--without intervention by the user.
The AS/400 home page: http://www.as400.ibm.com
-phil
Phil Vitale
IBM, AS/400
vit...@vnet.ibm.com
DISCLAIMER: I speak only for myself and not as an official representative of IBM.
Jan Vorbrueggen
mcca...@frakir.engr.sgi.com (John McCalpin) writes:
> What about LINUX and VMS?
Both are 64 bits internally, obviously with support for old 32 bit
applications in the case of VMS.
Jan
Zalman Stern
Andrew Duane USG/PE (du...@hunch.zk3.dec.com) wrote:
[Intel spends more money thatn DEC on helping ISV's tune performance.]
: Do you have figures for both companies?
No, and now that I think about it, I might be wrong :-) But if I say "in
the desktop market" perhaps it makes a bit more sense. (And spending more
money there probably wouldn't help DEC any.)
: I can't speak for Intel, but I know Digital spends quite a bit of
: time and money sending engineers to customer sites to tune, improve,
: and adapt code that "should" perform better.
My point was in regard to statements that getting performance out of an
IA-64 implementation will require new engineering expertise, particularly
expertise which is in short supply at comapnies that write desktop
software. I predict Intel will spend aggresively on this problem with
successful results in many areas. They already have a significant developer
support infrastructure in place (including tools development such as the
reference compiler and VTune).
-Z-
Jan Vorbrueggen
Paul DeMone <PaulD...@EasyInternet.net> writes:
> The big problem down the road is thermal management. What is the point
> where single die CPU power dissipation induces excessive system level
> costs or forces system level components to be spaced apart more widely
> than desirable? Is 100 W the knee in the curve above which system cost
> spirals upwards?
I shouldn't think so. You can get rid of an awful lot of heat with heat pipes
in a small space. DEC did an experiment with a more than 100W processors years
ago, and that wasn't a problem, they said explicitly. System cost - well,
that's another matter.
Jan
Rob Rodgers
zal...@netcom.com (Zalman Stern) wrote:
>My point was in regard to statements that getting performance out of an
>IA-64 implementation will require new engineering expertise, particularly
>expertise which is in short supply at comapnies that write desktop
>software. I predict Intel will spend aggresively on this problem with
>successful results in many areas. They already have a significant developer
>support infrastructure in place (including tools development such as the
>reference compiler and VTune).
I thought it was sort of settled that the Intel reference compiler
wasn't particularly good? My impression was that it wasn't even as
good as MS's VC5 for Pentium & Pro output.
Vtune is probably the best performance tuning _learning tool_ ever,
though.
----
http://www.wam.umd.edu/~rsrodger
"I did not get my Spaghetti-O's, I got spaghetti! I want the
press to know this." - Thomas Grasso, executed (OK) 3/20/95
Bruce Hoult
OK, the Pentium Pro is a RISC. Great. Fine.
So why is it that Intel hires engineers who are so stupid that their
RISC designs are so much slower and bigger than everyone else's RISC chips,
and use so much more power?
I mean, as recently as yesterday I was really, really impressed with how
smart the Intel guys must be to get that old clunker patched-up CISC
instruction set to go so damned fast. But now that I've been educated
that it's in actual fact a RISC -- and I have to take their word for it,
since I don't use one -- well, I guess those Intel ingineirs must be just
as thick as pigshit to make a RISC chip that big and slow and hot. Right?
-- Bruce
--
'We have no intention of shipping another bloated operating system and
forcing that down the throats of our Windows customers'
-- Paul Maritz, Microsoft Group Vice President
Casper H.S. Dik - Network Security Engineer
[[ Reply by email or post, don't do both ]]
p...@ocisgi7.unizh.ch (Serge Pachkovsky) writes:
>Glenn C. Everhart (ever...@gce.com.gov) wrote:
>: Also, of course, it will be possible to use VMS Galaxies to run lots of them
>: at once at levels way beyond what anyone is going to have much luck
>: working with using SMP techniques. (Your OS is going to do 50 way SMP??
>: Good luck!)
>Sorry, but IRIX does it *right* *now* on bigger Origin 2000's.
The Origin 2000 isn't an SMP machine, it's a NUMA machine.
(Solaris, OTOH, does run on SMP systems with more than 50 processors)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
John McCalpin
In article <sfqzpnc...@kraftwerk.pa.dec.com>,
Aaron Spink <sp...@kraftwerk.pa.dec.com> wrote:
>
>> SGI also posted what I believe is the highest specfp95 score so far 62.5
>> granted it was parallized across 8 cpu's.
>>
>Not according to www.specbench.org which is the Authority on Spec95.
I believe that our results were submitted to SPEC at the same
time as the press release (last week). They should show up
on the SPEC web site real soon now....
Also, note that our 62.5 result was on 16 cpus.
The comparison table looks like:
Parallel
System SPECfp95
========================== ========
Origin2000DS-195 (4CPU) 37.6
Origin2000DS-195 (8CPU) 52
Origin2000RK-195 (16CPU) 62.5
DEC4100 5/466 (4CPU) 36.1
DEC8200 5/625 (4CPU) 44
DEC8400 5/625 (4CPU) 45
DEC8400 5/625 (8CPU) 56.7
========================== ========
Be sure you check the pricing on these boxes before you decide
that the DEC lead at 8 cpus means much. The 8-cpu DEC 8400
system costs almost 3x as much as the 8-cpu Origin2000.
>The fastest 10+ multi CPU results are all alpha
Of course, this has been made much easier by the fact that
SGI has not submitted any automagically parallelized results
until last week.
Dror Maydan
Also, these are peak numbers. The baseline numbers for
the 8 CPU DEC8400 5/625 is 45.5 while the baseline numbers for
the 8 CPU Origin 2000 are 48.6
Dror
Patrick Chase
In article <346632...@EasyInternet.net>, Paul DeMone <PaulD...@EasyInternet.net> writes:
|> The big problem down the road is thermal management. [...]
|>
|> For some parts of the embedded CPU market, namely those targeted for
|> battery powered devices, MIPs/W (for whatever a MIPs is worth, but that
|> is a thread for another day) is now an important metric.
The use of MIPS/W as a metric has little to do with thermal management,
and everything to do with power consumption. These are two sides of the
same coin, but it's important to note that embedded designers worry more
about where the power is coming from than where it's going.
As a mechanical engineer by training, I don't really see dissipating
100 W (or even a couple hundred) as a noteworthy challenge. You may need
to go to approaches which are more elaborate than a simple heat sink, but
the cost/complexity of the necessary hardware still pales in comparison
to that of the CPU itself.
You can build one heck of a refrigeration system for a lot less than the
cost of a top of the line CPU...
Regards,
Patrick; Not speaking for Hewlett-Packard...
Anil Thomas Maliyekkel
Philip Vitale (vit...@rs47397.rchland.ibm.com) wrote:
: > (John D. McCalpin)
: > IBM has 64-bit hardware, but I have not been
: > following them
: IBM has been shipping 64-bit PowerAS processors in the AS/400 series
: for two years now.
: An overview of the early PowerAS processors (A10 and A30) appeared
: in the July 31, 1995 issue of Microprocessor Report.
: The latest PowerAS processor (that is shipping) is the A35. A twelve
: processor system based on the A35 was audited at 25,149 tpmC.
: > -- [IBM] may also do a 64-bit O/S.
: OS/400 for the PowerAS shipped two years ago, and is a full-fledged
: 64-bit operating system. (The AS/400 series also ships with a 64-bit
: version of DB2.)
This same processor is used in the RS/6000 S70 (it goes under the name
PowerPC RS64). It runs AIX 4.3 which supports both 32 bit and
64 bit (if the hardware supports it) applications.
Terje Mathisen
Rob Rodgers wrote:
> I thought it was sort of settled that the Intel reference compiler
> wasn't particularly good? My impression was that it wasn't even as
> good as MS's VC5 for Pentium & Pro output.
The latest Ref Compiler is definitely close to MSVC5 in optimization, what
it does a lot better is to support MMX operations, both in the inline
assembler, and in the form of compiler intrinsics.
The latter option is of course a far cry from an auto-parallelising
compiler, capable of taking (char *) loops and turn them into 8-wide
operations, but it does make it a lot easier to test out MMX algorithms.
> Vtune is probably the best performance tuning _learning tool_ ever,
> though.
Which is a Good Thing (tm), since it seems like performance tuning is
rapidly becoming a lost art.
Terje
--
- <Terje.M...@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
Doug Siebert
pat...@sdd.hp.com (Patrick Chase) writes:
>As a mechanical engineer by training, I don't really see dissipating
>100 W (or even a couple hundred) as a noteworthy challenge. You may need
>to go to approaches which are more elaborate than a simple heat sink, but
>the cost/complexity of the necessary hardware still pales in comparison
>to that of the CPU itself.
>You can build one heck of a refrigeration system for a lot less than the
>cost of a top of the line CPU...
So, out of curiousity, why doesn't HP do this for top of the line systems?
Maybe people don't want a machine with a noisy and hot refrigeration system
on their desk -- fine, then they buy the cheaper model with the slower CPU.
Or is reducing heat not that effective in clocking up current PA-8xxx CPUs?
And even if HP doesn't do it, why don't others? Intel showed a 400MHz+
Pentium II earlier this year, and DEC a 760MHz 21164, so it definitely works
for them. I'd think if nothing else Intel would want to sell it to get
the jump up in the SPEC95 list it would give them. And some gamers might
actually buy the thing if it gives them a few more frames per second in
Quake :)
Colin Plumb
In article <zalmanEJ...@netcom.com>,
Zalman Stern <zal...@netcom.com> wrote:
> (Note, DEC could not do a whole lot for themselves by giving developers
> Alpha hardware. You gotta have marketshare already to make this technique
> worthwhile, but it does give Intel more control over what developers do
> than they otherwise would have.)
I'd say that giving Linus a nice hot Alpha box was a pretty clever move
in this direction. It's not that simple (they also had some staff doing
a 32-bit Linus port to the Alpha until Linus, who did a 64-bit port
because it was cooler, caught up, and they probably gave a few more boxes
away), but that's one giveaway that has more than paid for itself.
> As an example, a few years back, Intel was getting beaten up on a certain
> Photoshop plug-in benchmark relative to Power Macs. (A bogus benchmark, but
> that makes no difference in advertising.)
I have some encryption code which is always going to run a lot faster
on a PowerPC than any IA32 platform. The inner loop is very sequential,
and has some memory accesses. With enough registers, I can parallelize
it and hide the latency by interleaving multiple instances.
On the x86, there are only enough registers to do one instance.
--
-Colin
John R. Mashey
In article <34655C...@EasyInternet.net>, Paul DeMone <PaulD...@EasyInternet.net> writes:
|> > : 2) integer performance compared to x86 and other RISCs
|> >
|> > : - FALSE: with a few noticably exceptions (0.35 um P6 intro)
|> > : Alpha has held a consistent integer lead, typically as high as
|> > : 50%, occasionaly a lot more, over other RISC and x86 flagship
|> > : CPUs
|> >
|> > Well today it's like 4.29 % (hmmm less then 5%). (vs c240)
|>
|> Well if you want to compare with the spanking new C240 why not try
|> the latest Alpha results of 18.8 SPECint95 (AS 4100 IIRC); this
Sigh. "Integer performance" != SPECint.
"floating point performance" != SPECfp
SPECint is a set of benchmarks that tell you something about integer performance
for certain sizes of code, often with ultra-heroic compiler tuning that
sometimes doesn't happen on real applications, some fo which includes
pattern recognition of the specific source code that breaks real applications,
etc.
SPECfp is a set of benchmarks that tell you something about floating poinbt
code of certain sizes, often with... (etc)
In general, statements of the form:
X has better integer perofrmance than Y ....
For example, SPECint....
are wrong.
Reality would be much better served if people would say:
"Integer performance, as measured by SPECint, of X is better than
that of Y" to remind people of what is, or isn't measured.
For instance, in an Origin system, the following:
- Improving the L2 cache speed by 1.5X.
- Quadrupling the L2 cache.
- Increasing the main memory bandwidth.
- Decreasing the main memory latency.
Don't affect SPECint95 very much, since the on-chip caches get fairly
good hit rates. Nevertheless, in larger codes, in various combinations,
such changes can have noticable effects [of course, all of these tests are
on unnanounced machines, or one we may never actually build].
In fact, a whole lot of hardware features found to be useful i nvarious
real codes don't really help SPECint very much.
I've said this before, and I guess I'll have to keep saying it:
1) SPEC benchmarks are useful; they sure improved the state of the world over
Whetstone & Dhrystone & vacuous mips-ratings; newer ones will
continue to be useful, I hope.
2) People have *got* to use them for what they're good for, and not
propagate over-generalizations.
3) The best thing about SPEC is the provision of large amounts of consistent
data: search among the benchamrks for ones that are good predictors for
your own codes, and ignore most of the rest. The problem is that many codes
are not very well predicted by them, despite being real codes of the
sort that McCalpin cited.
4) Finally, remember that SPECint & SPECfp (done as 1-CPU benchmarks on
multiprocessors) tell you very little themselves about scaling, i.e.,
a processor A might have SPECfp 1.5X higher than processor B,
but 8 of them might not have higher SPECthruput 1.5X higher than B.
--
-john mashey DISCLAIMER: <generic disclaimer: I speak for me only...>
EMAIL: ma...@sgi.com DDD: 650-933-3090 FAX: 650-932-3090
USPS: Silicon Graphics/Cray Research 6L-005,
2011 N. Shoreline Blvd, Mountain View, CA 94043-1389
a...@muc.de
kilg...@eisner.decus.org (Larry Kilgallen) writes:
> Those analysts must be wrong. How can "more and more" system companies
> go FABless when IBM seems to be the only one left with a FAB ?
>
> (Corrections to add other current FABfull system vendors are welcome.)
AMD ?
-Andi
M Sweger
Jan Vorbrueggen (j...@mailhost.neuroinformatik.ruhr-uni-bochum.de) wrote:
: Paul DeMone <PaulD...@EasyInternet.net> writes:
: > The big problem down the road is thermal management. What is the point
: Jan
Hi,
What then is the maximum amount of heat that can be gotten rid of
by using heat pipes? Of course, within reasonable limits since a heat pipe
could be really big.
--
Mike,
mik...@whiterose.net
M Sweger
Patrick Chase (pat...@sdd.hp.com) wrote:
: In article <346632...@EasyInternet.net>, Paul DeMone <PaulD...@EasyInternet.net> writes:
: |> The big problem down the road is thermal management. [...]
: |>
: |> For some parts of the embedded CPU market, namely those targeted for
: |> battery powered devices, MIPs/W (for whatever a MIPs is worth, but that
: |> is a thread for another day) is now an important metric.
: The use of MIPS/W as a metric has little to do with thermal management,
: and everything to do with power consumption. These are two sides of the
: same coin, but it's important to note that embedded designers worry more
: about where the power is coming from than where it's going.
: As a mechanical engineer by training, I don't really see dissipating
: 100 W (or even a couple hundred) as a noteworthy challenge. You may need
: to go to approaches which are more elaborate than a simple heat sink, but
: the cost/complexity of the necessary hardware still pales in comparison
: to that of the CPU itself.
: You can build one heck of a refrigeration system for a lot less than the
: cost of a top of the line CPU...
: Regards,
: Patrick; Not speaking for Hewlett-Packard...
Hi,
Since technology has practically reduced a cyrogenic pump down
to a coffee cup (or just about), why not shrink it some more to fit the
top a Pentium processor then heat problems will be gone for awhile?
--
Mike,
mik...@whiterose.net
Jan Vorbrueggen
mik...@dhp.com (M Sweger) writes:
> What then is the maximum amount of heat that can be gotten rid of
> by using heat pipes? Of course, within reasonable limits since a heat pipe
> could be really big.
From the sizes I remember of the heat pipes I've seen, and the size of a
current microprocessor package, I'd say 1kW is trivial, and 10kW should be
possible. It then is more of a problem of actually getting all the heat from
the junctions to the heat pipes, and of cooling the heat pipes (a heat pipe
has a thermal conductivity at least ten times that of a solid copper rod, so
you have a lot to do to cool them).
Jan
Larry Kilgallen
I don't know much about AMD, but I had thought of them as a chip vendor
rather than a system vendor. I presume they make motherboards as a
vehicle to sell their chips, and they may even sell some with boxes
around them to prove to potential motherboard customers the viability
of their motherboard design. But is AMD really in the system business ?
Larry Kilgallen
Zalman Stern
Bruce Hoult (Br...@hoult.actrix.gen.nz) wrote:
: zal...@netcom.com (Zalman Stern) writes:
: > Peter Mardahl (pet...@maxwell.EECS.Berkeley.EDUNOSPAM) wrote:
: > : My understanding is that the P6 core is essentially a RISC, and that
: > : the P6 "interprets" x86 code into the "internal" instruction set.
: >
: > Seems if lies get posted often enough, even I get tired of correcting
: > them. Let it be so...
: OK, the Pentium Pro is a RISC. Great. Fine.
If you are responding to me, then you are sadly mistaken. I believe RISC is
only meaningful as a term applied to user visible instruction set
architectures as opposed to "artifacts of particular implementations." As
such, saying the P6 "something-or-other" is RISC "something-or-other" is
just terminology obfuscation. (Just like all the phraseology used in the
food industry, U.S. at least, to describe something that is not entirely
unlike cheese. E.g. "cheese food," "processed cheese food," etc.)
Anyone who has read this newsgroup for a while has seen this
argument (usually in the context of "What is RISC") and probably seen my
posts on it. Its a dead horse by now. See also Mike Haertel's post, which
is pretty definitive on the topic in my mind.
-Z-
Patrick Chase
In article <zalmanEJ...@netcom.com>, zal...@netcom.com (Zalman Stern) writes:
|> Anyone who has read this newsgroup for a while has seen this
|> argument (usually in the context of "What is RISC") and probably seen my
|> posts on it. Its a dead horse by now. See also Mike Haertel's post, which
|> is pretty definitive on the topic in my mind.
Also, go to Dejanews, select the old database, and find one of the many
repostings of John Mashey's classic "What is RISC" article. Hint: Zalman
has (as usual) hit the nail on the head: The terms RISC and CISC apply
only to instruction sets, not to implementations.
Regards,
Patrick
Not speaking for my employer, Hewlett-Packard...
Paul DeMone
Mike Haertel wrote:
[snip]
> My personal take on the matter is that as far as performance
> is concerned, the instruction set has at most a second
> order effect. (Provided it's not too horrible.) Of
> course, I work for Intel and I am in exactly the business
> of implementing a fairly horrible instruction set to have
> decent performance, so I may be biased. :-)
I sure hope Mike isn't on the Merced team :-O
--
Paul W. DeMone The 801 experiment SPARCed an ARMs race
Kanata, Ontario to put more PRECISION and POWER into
dem...@mosaid.com architectures with MIPSed results but
PaulD...@EasyInternet.net ALPHA's well that ends well.
Mike Haertel
[reposted due to lousy news server]
In article <640qti$6i3$1...@maxwell.EECS.Berkeley.EDU>, Peter Mardahl wrote:
>> bit optimistic. Anyone remember the old rule of thumb "RISC is 3-5
>> times faster than CISC in the same technology"? Obviously someone
>> forgot to tell the Intel P6 design team that a few years back :-O
>
>My understanding is that the P6 core is essentially a RISC, and that
>the P6 "interprets" x86 code into the "internal" instruction set.
The details of the P6 implementation are irrelevent.
The claim was that RISC instruction sets would have much
faster implementations than CISC instruction sets; this
is what the P6 proved wrong. Despite the fact that the
P6 microcode looks somewhat (not very) reminiscent of a
RISC instruction set, the fact remains that what P6
implements is very definitely a CISC instruction set.
Paul DeMone
Zalman Stern wrote:
>
> Aaron Spink (sp...@kraftwerk.pa.dec.com) wrote:
> : I think what is a much more usefull term to describe an actual
> : processor are the terms short tick and long tick. Digital uses the
> : term short tick a lot to decribe the design philosophy that when into
> : creating the micro-arch and the simple definition is optimize for the
> : highest percentage cases and for clock speed. Something like the
> : Power2/P2SC from IBM would be on the long tick methodology of doing
> : everything well, even if it means sacrificing processor clock speed.
> : Its not exactly speed demon/braniac but it has some simularities.
>
> In your opinion, where does the 21264 fall?
The 21264 probably still falls in the short tick philosophy.
For example, DEC split the four integer units into two "clusters".
Data that has to be forwarded between the two clusters takes a one
cycle latency hit. This asymmetry reduces "IPC performance" on
integer code by about one percent, IIRC. OTOH, not grouping the
four integer units into clusters would have meant taking a non-trivial
clock frequency hit to allow the longer critical path. Result: net win.
BTW, I think categorizing the long tick methodology as "doing everything
well" is quite misleading. If the clock frequency is quite constrained
in order to fit in a long critical path needed by some baroque instr-
uction or addressing mode into a single clock cycle or phase, then I
would call it "doing everything slowly".
>
> Does the instruction set architecture influence this decision? Or is it
> just that certain mindsets pervade certain camps so the point of view that
> went into the architecture tends to go into the implementation too. (Which
> isn't necessarily a bad thing. Sometimes having "good sacred cows" keeps
> you from arguing about the same damn things over and over again.)
>
> For the real highend, why would one ever choose long tick? (Perhaps
> commercial highend is different than scientific highend...)
I don't this want to sound like one of those "you may be a redneck" jokes,
but if you are like HP and seem to be always fabbing your CPUs in processes
one or two generations behind most of your competitors, then maybe you
should be looking at a long tick philosophy ;-)
>
> -Z-
Paul DeMone
John R. Mashey wrote:
[snip]
> For instance, in an Origin system, the following:
> - Improving the L2 cache speed by 1.5X.
> - Quadrupling the L2 cache.
> - Increasing the main memory bandwidth.
> - Decreasing the main memory latency.
>
> Don't affect SPECint95 very much, since the on-chip caches get fairly
> good hit rates. Nevertheless, in larger codes, in various combinations,
> such changes can have noticable effects [of course, all of these tests are
> on unnanounced machines, or one we may never actually build].
> In fact, a whole lot of hardware features found to be useful i nvarious
> real codes don't really help SPECint very much.
Given the continued and rapid increase of both processor performance and the
sizes of cache and main memory (SPEC95 was designed to run on machines with as
little as 64 Mbyte of main memory), it is a trivial exercise to criticize a
three year old benchmark suite as not accurately modelling some applications
being run today. But, however much you may criticize it, SPEC95 is superior
to any other available benchmark collection for general purpose technical
computing. SPEC95 cleaned up a lot of the problems with SPEC92 by eliminating
the KAP-able matrix300 program and somewhat restricting the compiler option
gamesmanship. SPEC also enjoys wide spread industry participation and avoids
being a silly proprietary metric like "icomp's", "VUP's", or system 390 "MIPs".
Perhaps you can prevail on the owners of your "real codes" to allow you
to offer them to the System Performance Evaluation Corp. for inclusion
into the next release of the SPEC benchmarks. (SPEC98 ?)
[snip]
> --
> -john mashey DISCLAIMER: <generic disclaimer: I speak for me only...>
> EMAIL: ma...@sgi.com DDD: 650-933-3090 FAX: 650-932-3090
> USPS: Silicon Graphics/Cray Research 6L-005,
> 2011 N. Shoreline Blvd, Mountain View, CA 94043-1389
--
Burkhard Neidecker-Lutz
In article <64bb1n$caa$1...@murrow.corp.sgi.com> ma...@mash.engr.sgi.com (John R. Mashey) writes:
>|> <mention of Alpha by somebody else>
>
>SPECint is a set of benchmarks that tell you something about integer performance
>for certain sizes of code, often with ultra-heroic compiler tuning that
>sometimes doesn't happen on real applications, some fo which includes
>pattern recognition of the specific source code that breaks real applications,
>etc.
While I generally agree with what Mr. Mashey said here, I'd just like to
point out that some of the more recent SPEC results for the Alpha aren't
done anymore with "heroic" tuning and that very much mainstream compilers
and operating systems (even if you may not like them :-) ) are being
used with similar results to the "heroic" stuff. Witness the SPEC
results for the Digital Personal Workstation series under NT, done
with straight Microsoft Visual C++ and Visual Fortran Compiler (and,
admittedly, SPIKE, but using that is as simple as a "lint" run would
be on Unix).
Burkhard Neidecker-Lutz
CEC Karlsruhe , European Applied Research Center, Digital Equipment Corporation
email: nei...@kar.dec.com
"9 of the 10 most loaded Web sites run on Digital Unix and 72 of the top 100..."
Aaron Spink
pat...@sdd.hp.com (Patrick Chase) writes:
> has (as usual) hit the nail on the head: The terms RISC and CISC apply
> only to instruction sets, not to implementations.
>
I think what is a much more usefull term to describe an actual
processor are the terms short tick and long tick. Digital uses the
term short tick a lot to decribe the design philosophy that when into
creating the micro-arch and the simple definition is optimize for the
highest percentage cases and for clock speed. Something like the
Power2/P2SC from IBM would be on the long tick methodology of doing
everything well, even if it means sacrificing processor clock speed.
Its not exactly speed demon/braniac but it has some simularities.
aaron spink
not speaking for dec
Zalman Stern
Aaron Spink (sp...@kraftwerk.pa.dec.com) wrote:
: I think what is a much more usefull term to describe an actual
: processor are the terms short tick and long tick. Digital uses the
: term short tick a lot to decribe the design philosophy that when into
: creating the micro-arch and the simple definition is optimize for the
: highest percentage cases and for clock speed. Something like the
: Power2/P2SC from IBM would be on the long tick methodology of doing
: everything well, even if it means sacrificing processor clock speed.
: Its not exactly speed demon/braniac but it has some simularities.
In your opinion, where does the 21264 fall?
Does the instruction set architecture influence this decision? Or is it
just that certain mindsets pervade certain camps so the point of view that
went into the architecture tends to go into the implementation too. (Which
isn't necessarily a bad thing. Sometimes having "good sacred cows" keeps
you from arguing about the same damn things over and over again.)
For the real highend, why would one ever choose long tick? (Perhaps
commercial highend is different than scientific highend...)
-Z-
Stephen Carpenter
> time as the press release (last week). They should show up
> on the SPEC web site real soon now....
>
> Also, note that our 62.5 result was on 16 cpus.
>
> The comparison table looks like:
> Parallel
> System SPECfp95
> ========================== ========
> Origin2000DS-195 (4CPU) 37.6
> Origin2000DS-195 (8CPU) 52
> Origin2000RK-195 (16CPU) 62.5
>
> DEC4100 5/466 (4CPU) 36.1
> DEC8200 5/625 (4CPU) 44
> DEC8400 5/625 (4CPU) 45
> DEC8400 5/625 (8CPU) 56.7
> ========================== ========
>
> Be sure you check the pricing on these boxes before you decide
> that the DEC lead at 8 cpus means much. The 8-cpu DEC 8400
> system costs almost 3x as much as the 8-cpu Origin2000.
>
Using the current specbench.org data the table should be:
Parallel
System SPECfp95
============================ ========
Origin2000DS-195 (4CPU) 37.6
Origin2000DS-195 (8CPU) 52
Origin2000RK-195 (16CPU) 62.5
AlphaServer 4100 5/600 (1CPU) 29.2
AlphaServer 4100 5/600 (2CPU) 38.9
AlphaServer 4100 5/600 (4CPU) 51.4
AlphaServer 8200 5/625 (4CPU) 44
AlphaServer 8400 5/625 (4CPU 45
AlphaServer 8400 5/625 (8CPU) 56.7
============================= ========
I think you'll find that the price of the 4-cpu 4100 compares very
favourably with that of the 8-cpu Origin2000......
Stephen.
--
_______________________________________________________________
// \\
// Stephen Carpenter "One inode short of a file system" \\
// \\
\\ UNIX Ambassador s...@uvo.dec.com //
\\ Digital Equipment Co. Ltd //
\\_______________________________________________________________//
Aaron Spink
Paul DeMone <PaulD...@EasyInternet.net> writes:
> > course, I work for Intel and I am in exactly the business
> > of implementing a fairly horrible instruction set to have
> > decent performance, so I may be biased. :-)
>
> I sure hope Mike isn't on the Merced team :-O
Well, you never know. I sure hope they have someway of dealing with
the code bloat though. I would make the world of uP so much simpler if
some of the ideas in OS/400 had made it into the mainstream. :)
Aaron Spink
zal...@netcom.com (Zalman Stern) writes:
> In your opinion, where does the 21264 fall?
>
I would still say that the 21264 is a short tick design. A lot of the
public micro-architecture represents trade-offs that are designed to
go for high clock speed over super agressive IPC. Also, if you look
at the boundries of where the trade-offs were made in things such as
full in hardware IEEE FP vs. special traps to do less frequently used
operations and sub-sets of operations in software, it becomes apparent
that the target is much more towards keeping the overall speed of the
processor high. The clustered integer units is another example,
adding implicit hardware delays for the cases that you don't think
will happen that often.
> Does the instruction set architecture influence this decision? Or is it
> just that certain mindsets pervade certain camps so the point of view that
> went into the architecture tends to go into the implementation too. (Which
> isn't necessarily a bad thing. Sometimes having "good sacred cows" keeps
> you from arguing about the same damn things over and over again.)
>
To some degree within a particular company this is true, but for an
architecture that is being used to design multible processors by
multible different companies this can vary. A good example is the IDT
C6 which to me seems like it took a somewhat short tick methodology
versus what intel and the others in the x86 camp have done.
> For the real highend, why would one ever choose long tick? (Perhaps
> commercial highend is different than scientific highend...)
Well, look at the AS/400 line. Its aimed at the commercial high-end
and to that end having an extremely high clock rate doesn't make as
much sense since(weird) you are more dependant on memory bandwidth and
latency. Anything that you can do in that situation to improve the
overall memory subsystem is helpfull. In the Scientific highend, its
really a toss up. It depends on the operations that you are doing.
Tera is a pretty good example. The architecture was designed around a
certain set of problems and for the most part so was the
micro-architecture. Their main concern was not single thread
performance but more of total machine utilization.
In general, I haven't really fleshed this theory out, but I am working
on it. I think it does have a lot to do with a balanced
micro-architecture vs. an unbalacned one.
Paul A. Jacobi
Zalman Stern wrote:
> If you are responding to me, then you are sadly mistaken. I believe RISC is
> only meaningful as a term applied to user visible instruction set
> architectures as opposed to "artifacts of particular implementations."
Yale Pratt, who is well known for his work in computer architecture at the
university level and at Digital, defines the following two terms:
Architecture:
- Instruction set visible
- Address Space, addressability
- Opcodes, data types, address modes
- Support for MP and multiprogramming
- Software visible
Microarchitecture:
- Not instruction set visible
- caches
- branch prediction
- Instruction issue logic (scoreboarding)
- pipeling
From these definitions, both the VAX and x86 are clearly CICS
Architectures. However, some VAX and x86 implementation have used
RISC-like techniques in the Microarchitecture.
+---------------------------------------------------------------------------+
| Paul A. Jacobi Phone: (603) 881-1948 |
| Digital Equipment Corporation FAX : (603) 881-0189 |
| OpenVMS Systems Group, ZKO3-4/U14 Email: jac...@star.enet.dec.com |
| 110 Spitbrook Road |
| Nashua, NH 03062-2698 |
| |
| Anti-spam enabled! To reply, remove "nospam-" from the return address. |
+---------------------------------------------------------------------------+
Michael Williams
In article <sfqd8k4...@kraftwerk.pa.dec.com>,
Aaron Spink <sp...@kraftwerk.pa.dec.com> wrote:
>RISC and CISC have meaning only to describe instruction set and have
>nothing to do with the actual implementation of a machine. A machine
>is either RISC or it isn't, the same goes for CISC. If we are going
>to talk about the micro-architecture of machines then we need to come
>up with something else besides CISC and RISC. I personally think that
>we need two seperate classes of terms: Braniac and Speed Demon, as
>well as, Short-Tick and Long-Tick. These terms more acurately
>describe the actual micro-architecture of a machine than RISC and CISC
>with only really relate to the instructions sets, look at the
>micro-architectural differences between early Power and MIPS
>processors.
Maybe we can come up with a three (or more) letter code here, then.
- First letter - C or R - CISC or RISC instruction set.
- Second - S or L - "short-tick" or "long-tick"
- Third - B or D - "brainiac" or "speed-demon"
So. Alpha would be RSD, P6 CSD, HP-PA RLS (?), ARM RLD (perhaps).
That gives us 8 different architecture classifications, instead of 2.
Mike.
Michael Williams
In article <64fdqa$m...@usenet.pa.dec.com>,
Burkhard Neidecker-Lutz <nei...@kar.dec.com> wrote:
>used with similar results to the "heroic" stuff. Witness the SPEC
>results for the Digital Personal Workstation series under NT, done
>with straight Microsoft Visual C++ and Visual Fortran Compiler (and,
>admittedly, SPIKE, but using that is as simple as a "lint" run would
>be on Unix).
Um. Doesn't VC++ for Alpha/NT use Digital's compiler repackaged by
Microsoft? That's what I seem to remember, at least.
Mike.
Glenn C. Everhart
As I recall, one of the major problems in heat dissipation was the need
for an insulating layer between the heat sink and the chip. Epoxy is
not good at conducting heat, but was used. Diamond film would have worked
far better. Anyone know if the art in making diamond films has advanced
enough to be useful in solving such heat conduction problems?
Or is anyone even working with it?
Tim Olson
You mean an "electrically insulating, thermally conducting" layer, right?
Why not use good old heatsink grease (silicone compound)?
--
-- Tim Olson
John S. Yates, Jr
On 14 Nov 1997 11:01:22 GMT, michael....@arm-sponge.com (Michael Williams)
wrote:
>Um. Doesn't VC++ for Alpha/NT use Digital's compiler repackaged by
>Microsoft? That's what I seem to remember, at least.
Indeed! And if the DEC/Intel deal passes muster at the FTC it is a
good bet that same compiler technology will be revamped and pressed
into service in support of Merced. One reason that you can bet on
it is that DEC's Unix group needs 64 bit compilers with exactly the
right set of semantics, extensions, pragmas, etc to port to Merced.
/john
Michael Meissner
Well, the major piece of Digital compiler technology that would be useful
in the IA-64 context is the x86 translator (depending on the speed of the x86
translation that will be bolted on front of IA-64).
--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meis...@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)
Larry Kilgallen
> Well, the major piece of Digital compiler technology that would be useful
> in the IA-64 context is the x86 translator (depending on the speed of the
> x86 translation that will be bolted on front of IA-64).
I would think FX!32 is something DEC would want to keep as Alpha-only.
If those who need translation must go to Alpha, that is to DEC's benefit.
My view of the major useful piece of DEC compiler technology on Merced
would be their compilers for Ada, Fortran, Pascal, etc. Intel has a
C compiler, but probably not much else. Note that DEC's Ada, Fortran
and Pascal (and C) compilers on Alpha all use a common back-end. Of
course they might decide that those also should be part of the Alpha
Advantage.
Larry Kilgallen
Guy Harris
Aaron Spink <sp...@kraftwerk.pa.dec.com> wrote:
>Well, you never know. I sure hope they have someway of dealing with
>the code bloat though. I would make the world of uP so much simpler if
>some of the ideas in OS/400 had made it into the mainstream. :)
I don't know to which ideas you're referring, but if you mean the notion
of (as I understand it) having the compilers generate some high-level
"virtual" machine code and having the OS translate that into actual
machine code:
1) Smalltalks that do that might not be mainstream, but
some implementations of the (arguably) Most Hyped Language Of
The End Of This Decade are using a technique similar to that;
2) how would that affect the code bloat? It's the native code
that gets run....
--
Reply, or follow up, but don't do both, please.
postmaster@localhost
postmaster@[127.0.0.1]
Guy Harris
Larry Kilgallen <Kilg...@eisner.decus.org.nospam> wrote:
>(Corrections to add other current FABfull system vendors are welcome.)
Isn't HP currently fabfull (but probably going fabless for IA-64)?
Of the current general-purpose RISC architectures:
Alpha
SPARC
PowerPC
PA-RISC
MIPS
the ones where a system vendor has a fab are Alpha, PA-RISC, and
PowerPC; IBM isn't the only one left with a fab yet, but Digital is
going fabless and HP may do so as well.
I don't know if you can buy a system with Intel Outside, even though
they design motherboards; at one point, I think they were an OEM for
PC's sold under other names, but I don't know if they're still doing
that.
Aaron Spink
"Paul A. Jacobi" <jac...@star.enet.dec.nospam.com> writes:
>
> Zalman Stern wrote:
>
> > If you are responding to me, then you are sadly mistaken. I believe RISC is
> > only meaningful as a term applied to user visible instruction set
> > architectures as opposed to "artifacts of particular implementations."
>
> Yale Pratt, who is well known for his work in computer architecture at the
> university level and at Digital, defines the following two terms:
>
I think your talking about Yale Patt.
> From these definitions, both the VAX and x86 are clearly CICS
> Architectures. However, some VAX and x86 implementation have used
> RISC-like techniques in the Microarchitecture.
>
RISC and CISC have meaning only to describe instruction set and have
nothing to do with the actual implementation of a machine. A machine
is either RISC or it isn't, the same goes for CISC. If we are going
to talk about the micro-architecture of machines then we need to come
up with something else besides CISC and RISC. I personally think that
we need two seperate classes of terms: Braniac and Speed Demon, as
well as, Short-Tick and Long-Tick. These terms more acurately
describe the actual micro-architecture of a machine than RISC and CISC
with only really relate to the instructions sets, look at the
micro-architectural differences between early Power and MIPS
processors.
Carlie Coats
In article <346e5e7...@news.ne.mediaone.net>,
John S. Yates, Jr <ya...@mediaone.net> wrote:
> On 14 Nov 1997 11:01:22 GMT, michael....@arm-sponge.com (Michael Williams)
> wrote:
>
> >Um. Doesn't VC++ for Alpha/NT use Digital's compiler repackaged by
> >Microsoft? That's what I seem to remember, at least.
>
> Indeed! And if the DEC/Intel deal passes muster at the FTC it is a
> good bet that same compiler technology will be revamped and pressed
> into service in support of Merced. One reason that you can bet on
> it is that DEC's Unix group needs 64 bit compilers with exactly the
> right set of semantics, extensions, pragmas, etc to port to Merced.
And Digital's compiler already has to deal with one architecture
with some predicated operations -- recall that the Alphas have
conditional-move instructions (although not the conditional-execute
that Merced has; still, they have had to deal with block-
unification issues that no one else has faced.)
Carlie J. Coats, Jr. co...@mcnc.org
MCNC Environmental Programs phone: (919)248-9241
North Carolina Supercomputing Center fax: (919)248-9245
3021 Cornwallis Road P. O. Box 12889
Research Triangle Park, N. C. 27709-2889 USA
"My opinions are my own, and I've got *lots* of them!"
Matthias Dolder
John McCalpin wrote:
...snip...
> I`Sure -- if you limit your sample space to codes where the Alpha is
> faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
> "discover" that the Alpha is faster.
Of course and if you limit your sample to codes where MIPS is faster thenyou
discover that MIPS is faster, so what ?
>
>
> However, it is important for comp.arch members to recognize that
> this not true for large areas of application space, especially for
> number-crunching sorts of jobs.
>
> Every time I review the available applications performance data,
> I see that we have a fairly tight race at the top. Normalizing
> to the performance of an Origin2000 uniprocessor (195 MHz R10000,
> 130 MHz/4 MB L2 cache), the eyeballed averaged of engineering
> application performance is something like:
So what is exactly the base of applications performance data you are usingto
come up with below table. Maybe other people would base it on other
application data and then it suddenly would look completely different...
>
>
> vendor performance cpu system clock cache
> --------------------------------------------------------------
> DEC ~1.05 21164 4100 500 4 MB
> SGI 1.0 R10000 Origin 195 4 MB
> HP ~0.8 PA-8000 K-460 180 1+1 MB
> Sun ~0.7 Ultra2 UE5002 250 2(?) MB
> IBM ~0.7 P2SC SP 120 ???
> Intel ~0.3 P6 various 200 512 kB ?
> --------------------------------------------------------------
>
There is no AlphaServer 4100 5/500 which above table implies. It's either5/466
or 5/533. SPEC95 values for 5/600 are posted on www.specbench.org
as well.
...snip...
> Since this is comp.arch, we should all recite together:
>
> "Computer performance is more than the cpu clock frequency"
> "Computer performance is more than the cpu clock frequency"
> "Computer performance is more than the cpu clock frequency"
> "Computer performance is more than the cpu clock frequency"
> "Computer performance is more than the cpu clock frequency"
> "Computer performance is more than the cpu clock frequency"
sure, especially if you have difficulties to get to higher frequency (thoughyou
are of course right)
...snip...
The 64-bit marketplace has two players today -- SGI and DEC.
> SGI has much larger market share in UNIX workstations (2x and
> growing), mid-range servers (>3x) and HPC (>3.5x).
Oops, where did you get those data from ? IDC Baseline (5/97) onthe UNIX server
market 1996 sees SGI with a 5% total market share,
DIGITAL with 6%. What is mid-range ? Assuming a price range 50-75k$
then the same IDC report gives SGI approx.1.5% and DIGITAL approx.9%
(don't have it more percise since i only have the graphs)
Looking at the 75-100k$ range results give SGI approx. 3.5% and
DIGITAL 5%. At the high end (250-500k$) SGI gets approx. 11%
whereas DIGITAL is around approx. 6%. Don't have workstation numbers
but would tend to believe that SGI has a larger market share. However,
the workstation market is eaten more and more by NT which seems to worry
SGI enough to announce that they also want to enter the Wintel market. Also
your last quarterly report where slow server sales are blamed for disappointing
results do not exactly support your statement.
(I think that the Cray T3x is not accounted for in the IDC numbers)
>
>
> Of course Cray Research (a Silicon Graphics company) has been
> shipping 64-bit hardware and software for over 20 years, though
> few of us make enough money to own one of these personally.
>
Yes, looking at the TOP500 Supercomputer list (www.netlib.org) indeedshows a
large number of SGI/Cray systems, including 6 entries in
the TOP 10 (including 2nd and 3rd rank). You seem to be selling
quite a lot of those T3x systems. And now the real interesting question:
Which processor powers the SGI/Cray T3x series ???
Yes, ALPHA. And i'm pretty sure that none of your T3x
customers would mind getting a 21264 (aka EV6) upgrade...
rgds
MatthiasD.
--------------------------------------------
Digital Equipment Corporation, Switzerland
Matthias Dolder
dol...@digital.com
...speaking for myself...
a...@muc.de
Aaron Spink <sp...@kraftwerk.pa.dec.com> writes:
> RISC and CISC have meaning only to describe instruction set and have
> nothing to do with the actual implementation of a machine. A machine
My personal understanding was that the existence of microcode vs
real hardware coding of instructions defines RISC vs CISC too. But
I might be wrong here of course..
-A.
Tim Shoppa
What about the Data General Nova instruction set, which (depending
on the implementation) was done in either "real hardware" or in
microcode?
Tim. (sho...@triumf.ca)
Robert Harley
matthias*****zuo.dec.com writes:
>You seem to be selling
>quite a lot of those T3x systems. And now the real interesting question:
>Which processor powers the SGI/Cray T3x series ???
No no no, didn't you read the SGI P.R. blurb?
"... bla bla bla ... 1328 processing elements ... bla ... teraflop ... "
The Crays have "processing elements" you see, and any ressemblance
with 450MHz Alphas is very carefully not mentioned at all.
=:-)
Rob
Victor Yodaiken
On 14 Nov 1997 16:56:57 -0800, Guy Harris <g...@netapp.com> wrote:
>I don't know if you can buy a system with Intel Outside, even though
Does Intel now also own Drawbridge and Tulip etc?
--
---------------------------------
Victor Yodaiken
Department of Computer Science
New Mexico Institute of Mining and Technology
Socorro NM 87801
Homepage http://www.cs.nmt.edu/~yodaiken
PowerPC Linux page http://www.cs.nmt.edu/~linuxppc
Real-Time Page http://luz.cs.nmt.edu/~rtlinux
a...@muc.de
kilg...@eisner.decus.org (Larry Kilgallen) writes:
> My view of the major useful piece of DEC compiler technology on Merced
> would be their compilers for Ada, Fortran, Pascal, etc. Intel has a
> C compiler, but probably not much else. Note that DEC's Ada, Fortran
> and Pascal (and C) compilers on Alpha all use a common back-end. Of
> course they might decide that those also should be part of the Alpha
> Advantage.
Intel has C,C++ and Fortran (77 probably, not sure about 90) compilers.
-A.
John McCalpin
In article <346C94FE...@zuo.dec.com>,
Matthias Dolder <matthias*****zuo.dec.com> wrote:
>
>John McCalpin wrote:
>
>...snip...
>
>> I`Sure -- if you limit your sample space to codes where the Alpha is
>> faster than MIPS/PA-RISC/P2SC/whatever, then lo and behold -- you
>> "discover" that the Alpha is faster.
>
>Of course and if you limit your sample to codes where MIPS is faster thenyou
>discover that MIPS is faster, so what ?
Yes, it is possible to do this, but that is not what I did.
If you had looked at the followups, after I got soundly flamed, I
clarified that I "limited" the data to all the data that I had
available. It is certainly possible that there is systematic error,
but it is difficult to imagine a more honest approach to the issue.
>So what is exactly the base of applications performance data you are usingto
>come up with below table. Maybe other people would base it on other
>application data and then it suddenly would look completely different...
Possible. To repeat my earlier clarifications, the data set used
was all the publicly available benchmark data for:
ABAQUS Explicit
ABAQUS Standard
a benchmark problem for ANSYS
a set of benchmarks for MSC/NASTRAN
a small set of benchmarks for FIDAP
the NCAR CCM2 climate model.
If you know of other publicly released data comparing current
processors for important third-party applications, I would
certainly include it in my comparisons.
>> vendor performance cpu system clock cache
>> --------------------------------------------------------------
>> DEC ~1.05 21164 4100 500 4 MB
>> SGI 1.0 R10000 Origin 195 4 MB
>> HP ~0.8 PA-8000 K-460 180 1+1 MB
>> Sun ~0.7 Ultra2 UE5002 250 2(?) MB
>> IBM ~0.7 P2SC SP 120 ???
>> Intel ~0.3 P6 various 200 512 kB ?
>> --------------------------------------------------------------
>>
>
>There is no AlphaServer 4100 5/500 which above table implies. It's either5/466
>or 5/533. SPEC95 values for 5/600 are posted on www.specbench.org
>as well.
My apologies for the lack of detail. The "500 MHz" listing for
DEC included some results for the AlphaStation 400/500, and some
some scaled numbers for the AlphaServer 4100-5/466 (timing scaled
by 466/500, which may be slightly generous but is likely quite close).
There are, of course, faster processors available from several vendors
now, but I have seen no performance results from third-party
applications codes, so I had no way of including them.
>> SGI has much larger market share in UNIX workstations (2x and
>> growing), mid-range servers (>3x) and HPC (>3.5x).
>
>Oops, where did you get those data from ? IDC Baseline (5/97) on
>the UNIX server market 1996 sees SGI with a 5% total market share,
>DIGITAL with 6%. What is mid-range?
I am also limited to graphs on this. The IDC data I have shows SGI at
10% and DEC at 3% for this category as of 12/96. It is possible that
the categories were chosen perversely in order to skew the results
(e.g., it clearly ignores DEC's VMS and NT server sales). I should
probably be more careful in the future to look at the detailed IDC data
personally before quoting from the graphs.
>(I think that the Cray T3x is not accounted for in the IDC numbers)
The T3E would definitely be in the HPC category, rather than one
of the server categories.
--
--
John D. McCalpin, Ph.D. Supercomputing Performance Analyst
Technical Computing Group http://reality.sgi.com/mccalpin/
Silicon Graphics, Inc. mcca...@sgi.com 650-933-7407