McKinley tops SpecFP AND SpecInt charts
Rob Young
That's right. Time to eat crow all around. Perhaps there
may not be enough platters, but who cares, eh?
According to the PPTs and HTMLs found at www.openvms.org one
can find (in the notes field) the Spec numbers embargoed until today.
Following are base numbers. So maybe their is a tiny bit of
glory left for Power4 in SpecInt2000 peak?
Itanium 2 Power4 at 1.3 GHz
SpecInt2000 810 804
SpecFp 1356 1202
Rob
Rob Young
That's right. Time to eat crow all around. Perhaps there
may not be enough platters, but who cares, eh?
According to the PPTs and HTMLs found at www.openvms.org one
can find (in the notes field) the Spec numbers embargoed until today.
Bob Ceculski
save the biggest pieces for Andrew and Bill ...
Bill Todd
"Rob Young" <you...@encompasserve.org> wrote in message
news:XSeIOD...@eisner.encompasserve.org...
>
> That's right. Time to eat crow all around.
Nope. The only crow I'm about to eat is my guess at McKinley's SPECint2K
performance - *assuming* that the numbers reported by HP are actually
accepted by SPEC.
BTW, until that happens, your subject line above is incorrect: the only
official such charts don't yet include McKinley numbers, and by the time
they do both official SPEC chart bars *may* have been raised higher by
someone else such that your assertion will not be correct then either (e.g.,
given that submissions can be made up to 3 months before ship date the new
1.25 GHz EV68C numbers may yet appear before McKinley's do, as may new
POWER4 numbers depending on the details of that processor's schedule).
That said, if HP's numbers are even close to correct McKinley has come in
considerably better than I expected it to, and there may be some reason to
believe it's at least in large part due to HP's new chipset surrounding it
(we'll see if and when other configurations release the same benchmarks).
Over 20% better SPECint2K performance (if you average base and peak) *per
clock* than Alpha (and roughly the same per-clock performance as PA-RISC
8700 and MIPS R14K, both of which have lower max clock rates than McKinley)
is nothing to be sneezed at, though much of what isn't attributable to HP's
chip set can likely be laid at the door of McKinley's exceptionally large
and fast on-chip caches (no, I still don't have much use for EPIC itself).
There's still just a bit of doubt in my mind because of some of the other
benchmark figures HP released that just don't seem to make sense. For
example, its 4-processor TPC-C performance came in about 55% higher than the
ES45's despite no better (perhaps considerably lower) system bandwidth (if
HP's Itanic configuration uses the shared 6.4 GB/sec bus rather than
something more like the ES45's onboard switch) and only 20% better SPECint2K
numbers. MS SQL Server has some reputation for being a better TPC-C
performer than Oracle, though, so that could account for the difference (it
would be interesting to see results for HP-UX running Oracle...), as could
details of the test configuration (which we won't know until TPC accepts and
posts the results). It's unfortunate that Alpha is (still) owned by a
company with little apparent interest in competing with Itanic in the
benchmark area, but IBM and AMD may be able to keep them at least somewhat
honest.
And, BTW, I haven't heard a peep about McKinley's performance running IA32
code - which will become increasingly important as Hammer becomes an issue.
In a somewhat related vein, Hammer should be both performance-competitive
and *extremely* price/performance-competitive with Itanic on things like
TPC-C, bringing to mind a possibly-prophetic echo from the past
http://news.com.com/2100-1001-228204.html?legacy=cnet ):
"At this point, most people understand that Merced itself is not going to be
a very compelling product for Intel," he said. "If you look at the
performance of Merced, it's really not going to be meaningfully different
from what you get at the high end of the 32-bit architecture."
Indeed, even given McKinley's "surprisingly good" (Terry's phrase)
performance, it's still not 'meaningfully different' from that available
from existing IA32 hardware (let alone Hammer) except in the very high-end
niche areas which IA32 can't (and Hammer *may* not be able to) reach.
None of which makes any substantive difference to my primary, original, and
consistent claim that Itanic's performance would never have done in Alpha
(though Alpha, with any reasonable support, would have stood a decent chance
of doing in Itanic - especially if it ran IA32 binaries faster under FX!32
as well as its native code). The fact that McKinley seems to be coming in
above expectations is more than balanced by the increasing evidence that
Intel had no clue whatsoever where to go after the McKinley core (nor any
obvious reason to expect that it would have developed much of a clue, let
alone the ability to bring it to fruition, without the influx of Alpha
talent and intellectual property such as EV7's on-chip routing facilities).
Itanic will have to live with whatever performance McKinley offers today
through both Madison and Montecito, modulo process shrinks that seem
unlikely to more than double its current performance when Montecito comes
along in 2004 (assuming that heat dissipation problems don't limit
performance to an even lower value) - and likely through 2005 as well,
though it may get better on-chip support in 2005 similar to what POWER4 and
USIII got last year and EV7 and Hammer will get this year. Next month
McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed by
EV7 in virtually all respects (SPECint, memory latency and bandwidth,
scalability, ...), and then would have been dealt an even heavier blow by
EV8's advantages of a process-shrink plus a completely new core and SMT
support (with interesting things in EV9 yet to come). These few months
right now are as close as Itanic would ever have come to catching Alpha:
when EV8 rolled around, Montecito would have offered *at most* half the
per-processor performance in server-style activity, despite being a full
process generation ahead.
- bill
John Smith
"Bill Todd" <bill...@metrocast.net> wrote in message
news:dWpW8.35549$Im2.1...@bin2.nnrp.aus1.giganews.com...
My bet is that HP will NOT publish any SPEC performance numbers for EV68 or
EV7.
Why, you ask? Because they have no need to. And why would they want to make
their multi-billion dollar investment in Itanic look bad?
Anyone who needs EV68 or EV7 is a 'current ' customer and has no where else
to go for processors/systems, so no matter if EV68 or EV7 numbers are
slightly under, equal to, slightly over, or wildly over Itanic 2, those
customers will buy EV68/EV7 if they need the horsepower for their apps.
Since HP is not in the business of selling Tru64 or OpenVMS to *new*
customers (their stated business model, not mine), they don't have to
impress anyone with great SPEC numbers for EV68/EV7, nor incur the expense
of running the tests.
By not publishing numbers, they can further distance customer mind-sets from
Alpha, and the performance they will have lost vs. Alpha when VMS arrives on
Itanic III or IV. Larry Ellison should be paying Capellas a huge royalty for
every customer that migrates from Alpha to n-Itanic processors to get the
same workload processed.
Rob Young
>
> "Rob Young" <you...@encompasserve.org> wrote in message
> news:XSeIOD...@eisner.encompasserve.org...
>>
>> That's right. Time to eat crow all around.
>
> Nope. The only crow I'm about to eat is my guess at McKinley's SPECint2K
> performance - *assuming* that the numbers reported by HP are actually
> accepted by SPEC.
>
That would be a hold out hope.
>
> That said, if HP's numbers are even close to correct McKinley has come in
> considerably better than I expected it to, and there may be some reason to
> believe it's at least in large part due to HP's new chipset surrounding it
> (we'll see if and when other configurations release the same benchmarks).
> Over 20% better SPECint2K performance (if you average base and peak) *per
> clock* than Alpha (and roughly the same per-clock performance as PA-RISC
> 8700 and MIPS R14K, both of which have lower max clock rates than McKinley)
> is nothing to be sneezed at, though much of what isn't attributable to HP's
> chip set can likely be laid at the door of McKinley's exceptionally large
> and fast on-chip caches (no, I still don't have much use for EPIC itself).
>
You don't have much use for EPIC? Why? Performs much better
than expected? Is there a lurking contradiction I am not quite
highlighting?
> There's still just a bit of doubt in my mind because of some of the other
> benchmark figures HP released that just don't seem to make sense.
They make a lot of sense.
For
> example, its 4-processor TPC-C performance came in about 55% higher than the
> ES45's despite no better (perhaps considerably lower) system bandwidth
That isn't the key to high tpmC.
>
> Indeed, even given McKinley's "surprisingly good" (Terry's phrase)
> performance, it's still not 'meaningfully different' from that available
> from existing IA32 hardware (let alone Hammer) except in the very high-end
> niche areas which IA32 can't (and Hammer *may* not be able to) reach.
>
Ummm... for meaningfully different, how about a metric everyone loves?
$/tpmC.
>
> Itanic will have to live with whatever performance McKinley offers today
> through both Madison and Montecito, modulo process shrinks that seem
> unlikely to more than double its current performance when Montecito comes
> along in 2004 (assuming that heat dissipation problems don't limit
> performance to an even lower value) - and likely through 2005 as well,
That's a bold prediction. Here is another one:
From: "Bill Todd" <bill...@metrocast.net>
Newsgroups: comp.os.vms
Subject: Predictions - just for the hell of it
Date: Fri, 22 Mar 2002 21:59:14 GMT
"McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especially
given that this is the core users will have to live with (with only a
process shrink/cache bump) until at least 2005: 700 max, possibly as low as
600, probably around 650."
---
Now maybe there are some pretty substantial compiler optimizations
left on the table. Especially with that 6MB L3. After all, if
guesses are consistent, we can expect at least a 40% SpecInt performance
improvement McKinley to Madison, would be a reasonable guess.
You agree?
> though it may get better on-chip support in 2005 similar to what POWER4 and
> USIII got last year and EV7 and Hammer will get this year. Next month
> McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed by
> EV7 in virtually all respects (SPECint, memory latency and bandwidth,
> scalability, ...), and then would have been dealt an even heavier blow by
> EV8's advantages of a process-shrink plus a completely new core and SMT
> support (with interesting things in EV9 yet to come). These few months
> right now are as close as Itanic would ever have come to catching Alpha:
> when EV8 rolled around, Montecito would have offered *at most* half the
> per-processor performance in server-style activity, despite being a full
> process generation ahead.
Yeah but... at $5 per tpmC for McKinley, no one is going to touch
that until Madison and Madison for sure. Also, don't overlook
$/Specfp that will help a great deal for folks looking at a number
cruncher on a tight budget.
Rob
JF Mezei
IA64 is "EPIC" where it expects the compiler to do all the work to make best
use of the chip's architecture.
In the Intel released results for IA64, was it done with normal commercial
applications compiled using whatever commercially available compilers exist
for IA64, was was it done with specially tweaked applications designed
carefully to generate the best possible speed results ?
If the Intel released specs don't reflect what commercial applicatiosn will
deliver, then the question is how big a gap there will be between Intel's
"dream" specs, and what real world performance will be delivered.
Will Intel's commercial compilers really be able to take code not specifiaclly
designed for IA64 and generate assembler that makes best use of IA64's
potential ?
Bill Todd
> In article <dWpW8.35549$Im2.1...@bin2.nnrp.aus1.giganews.com>, "Bill
Todd" <bill...@metrocast.net> writes:
...
> You don't have much use for EPIC? Why?
Because I strongly suspect that an Alpha with anywhere nearly as much (and
as fast) on-chip cache would blow it completely out of the water. Even EV7,
with only a bit over half as much (and likely noticeably slower) on-chip
cache seems likely to offer significantly better performance: some of that
will be due to the improved main-memory access times, but I suspect that the
other boost McKinley got was from improvements in that area due to the HP
chip set, so it still looks like a four-year-old OoO core can whup a brand
new 2002 EPIC core in the same process (too bad we'll never see what EV8
could have done).
...
> > There's still just a bit of doubt in my mind because of some of the
other
> > benchmark figures HP released that just don't seem to make sense.
>
> They make a lot of sense.
>
> For
> > example, its 4-processor TPC-C performance came in about 55% higher than
the
> > ES45's despite no better (perhaps considerably lower) system bandwidth
>
> That isn't the key to high tpmC.
I didn't say it was, but included it for completeness. You snipped the
other possible reasons that I included, two of which - SQL Server vs. Oracle
performance and test configuration - have nothing to do with Itanic's
relative performance to (in this case) Alpha. Having gobs of fast on-chip
cache certainly doesn't hurt, but is hardly an advertisement for EPIC per
se.
My point was that it was not at all clear that the 55% better (than ES45)
TPC-C result actually reflected Itanic architecture or chip-set superiority
simply because it did not appear to correlate with the 20% better SPECint or
any other (e.g., bandwidth) processor/chip-set characteristics (save
possibly the cache). Given the degree to which TPC-C is sensitive to the
storage setup, my inclination is to suspect that the result may say more
about that than anything related to the new box.
>
> >
> > Indeed, even given McKinley's "surprisingly good" (Terry's phrase)
> > performance, it's still not 'meaningfully different' from that available
> > from existing IA32 hardware (let alone Hammer) except in the very
high-end
> > niche areas which IA32 can't (and Hammer *may* not be able to) reach.
> >
>
> Ummm... for meaningfully different, how about a metric everyone loves?
> $/tpmC.
If you'll go to www.tpc.org, you'll find that several IA32 systems (the
systems being referred to in the discussion you snipped part of above) have
$/tpmC figures lower than those HP reported for McKinley. Hammer is likely
to be even lower.
>
> >
> > Itanic will have to live with whatever performance McKinley offers today
> > through both Madison and Montecito, modulo process shrinks that seem
> > unlikely to more than double its current performance when Montecito
comes
> > along in 2004 (assuming that heat dissipation problems don't limit
> > performance to an even lower value) - and likely through 2005 as well,
>
> That's a bold prediction.
Not at all: the technical information and dates (through 2004, and even the
mention of a Montecito 'bump' in 2005 which I suspect may refer to some
added on-chip memory and/or MP support) come straight from Intel's public
statements, and the relative performance improvements due to shrinks and
added cache track existing experience.
For example, the consensus expectation for Madison clock speed is 1.2 - 1.6
GHz (presumably lower at introduction and gradually rising via tweaks later,
so at introduction nothing more than 1.4 GHz seems likely, especially given
the unrealisticly high clock-speed predictions both Merced and McKinley
had). Since IIRC Madison is when the process moves to Cu, the subsequent
percentage clock boost with Montecito may be a bit less, making 2 GHz seem
about the limit of what one can expect for Montecito at introduction in
2004. Yes, cache will be boosted too, but it *has* to be for SPECint
performance to increase linearly with clock rate (which I've assumed,
perhaps a bit generously).
Here is another one:
>
>
http://groups.google.com/groups?selm=SONm8.117351%241g.9103926%40bin3.nnrp.a
us1.giganews.com&output=gplain
>
> From: "Bill Todd" <bill...@metrocast.net>
> Newsgroups: comp.os.vms
> Subject: Predictions - just for the hell of it
> Date: Fri, 22 Mar 2002 21:59:14 GMT
>
> "McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especially
> given that this is the core users will have to live with (with only a
> process shrink/cache bump) until at least 2005: 700 max, possibly as low
as
> 600, probably around 650."
Yup. If HP's claimed numbers actually materialize at spec.org, they'll be
about 25% higher than what Intel's statements (upon which I based the above
estimates, together with ancillary material from Paul DeMone's realworldtech
articles) suggested - so I'll be quite curious to see whether Intel can post
comparable numbers using its own chip sets.
However, the future *beyond* McKinley is far less subject to surprises than
the Merced/McKinley transition was, since no further architectural changes
are publicly planned through at least 2004 (and no *core* architectural
changes likely before 2006 - 7); the fact that no noticeable Alpha influence
will appear before at least 2005 was confirmed privately as well.
>
> ---
>
> Now maybe there are some pretty substantial compiler optimizations
> left on the table.
My guess is that at least part of the delay in releasing McKinley was caused
by waiting for compiler tweaks to raise its performance to respectable
levels. If that's so, the low-hanging fruit has likely already been picked
pretty well clean (and about time, given that they've had the better part of
a decade to grab it).
Especially with that 6MB L3. After all, if
> guesses are consistent, we can expect at least a 40% SpecInt performance
> improvement McKinley to Madison, would be a reasonable guess.
> You agree?
Change 'at least' to 'about' and it sounds reasonable.
>
> > though it may get better on-chip support in 2005 similar to what POWER4
and
> > USIII got last year and EV7 and Hammer will get this year. Next month
> > McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed
by
> > EV7 in virtually all respects (SPECint, memory latency and bandwidth,
> > scalability, ...), and then would have been dealt an even heavier blow
by
> > EV8's advantages of a process-shrink plus a completely new core and SMT
> > support (with interesting things in EV9 yet to come). These few months
> > right now are as close as Itanic would ever have come to catching Alpha:
> > when EV8 rolled around, Montecito would have offered *at most* half the
> > per-processor performance in server-style activity, despite being a full
> > process generation ahead.
>
>
> Yeah but... at $5 per tpmC for McKinley, no one is going to touch
> that until Madison and Madison for sure.
As I said, check out tpc.org: they've already got results under $5/tpmC for
IA32 systems, and I suspect that Hammer will drive them even lower. If one
is cost-driven and has no real need for a 64-bit address space (or is
willing to wait and see how Hammer develops), Itanic isn't going to look
very attractive any time soon.
How Itanic will compete with the existing RISC architectures is more
problematic. Sun's 4-processor box pricing is comparable to Intel's
reported price structure for Itanics (and IIRC somewhat lower than HP's), so
they'll have to slug it out in performance and other areas. IBM and for
that matter HP itself aren't as used to aggressive RISC pricing as Sun seems
to be, so they may have to make some adjustments. But the current absence
of Dell in the fray may make *everyone* a bit slow to lower prices
drastically.
Also, don't overlook
> $/Specfp that will help a great deal for folks looking at a number
> cruncher on a tight budget.
Only those who miss the fact that Pentium 4 is even more cost-effective in
that respect.
- bill
Nick Maclaren
Rob Young <you...@encompasserve.org> wrote:
>In article <dWpW8.35549$Im2.1...@bin2.nnrp.aus1.giganews.com>, "Bill Todd" <bill...@metrocast.net> writes:
>> "Rob Young" <you...@encompasserve.org> wrote in message
>> news:XSeIOD...@eisner.encompasserve.org...
>>>
>>> That's right. Time to eat crow all around.
>>
>> Nope. The only crow I'm about to eat is my guess at McKinley's SPECint2K
>> performance - *assuming* that the numbers reported by HP are actually
>> accepted by SPEC.
>
> That would be a hold out hope.
Less than you appear to think. Intel's record here is ghastly; for
20 years, Intel has had a reputation for quoting figures that nobody
else can reach, or that use unreasonable (and often unsold) features.
In academia, journals stop publishing authors who do that ....
The question is whether HP have descended to that level. I doubt it,
but it isn't implausible. A more serious point is that we have VERY
good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
are worth 10-20% on SpecInt. That would make a best guess at the
McKinley's SpecInt performance using Intel's compiler on Bandera
600-650. And, lastly, ask your HP salesman about the availability
of the HP compiler on other than HP-UX.
>> That said, if HP's numbers are even close to correct McKinley has come in
>> considerably better than I expected it to, and there may be some reason to
> You don't have much use for EPIC? Why? Performs much better
> than expected? Is there a lurking contradiction I am not quite
> highlighting?
I don't, and have posted my reservations for 8 years. I shall not
repeat them here, except one I refer to below, but please note that
they will be proved only when real IA-64 systems are used with real
loads by real users. Benchmarks are notorious for not showing up
performance and reliability problems.
> Ummm... for meaningfully different, how about a metric everyone loves?
> $/tpmC.
Yes. WHEN IA-64 systems are in full production. At present, they
are in introduction, and the prices are more than usually artificial.
> That's a bold prediction. Here is another one:
>From: "Bill Todd" <bill...@metrocast.net>
>
>"McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especially
>given that this is the core users will have to live with (with only a
>process shrink/cache bump) until at least 2005: 700 max, possibly as low as
>600, probably around 650."
That is what almost everyone thought then, and may still be true for
Intel's compiler on Bandera. My guess still is that it will be.
> Now maybe there are some pretty substantial compiler optimizations
> left on the table. Especially with that 6MB L3. After all, if
> guesses are consistent, we can expect at least a 40% SpecInt performance
> improvement McKinley to Madison, would be a reasonable guess.
> You agree?
I should be flabberghasted. The IA-64 software project as a whole
was the largest one since the Sytem/360, and the compiler work was
probably 2/3 of that. 8 years of well-funded work following on
from 25 years of ubiquitous research doesn't leave many cherries
to pick, and you can't produce breakthroughs to order.
Remember that the problem is primarily in program analysis, and not
in code generation. Now, one aspect that could have MASSIVE effects
on SpecInt is with the adoption of C99 (mainly if it used restrict,
but there is also type-controlled aliasing). However, any compiler
that uses the latter will cause HUGE numbers of widespread programs
to break, so it isn't a 'fair' optimisation. But was it used? We
don't know yet.
> Yeah but... at $5 per tpmC for McKinley, no one is going to touch
> that until Madison and Madison for sure. Also, don't overlook
> $/Specfp that will help a great deal for folks looking at a number
> cruncher on a tight budget.
Maybe. Those of us who are deeply into number-crunching are less
convinced by the IA-64 line than we were 5+ years ago, as the
interesting little "gotchas" emerge. When and if McKinley systems
become available to independent HPC people, evidence of their
desirability (or the converse) will start to emerge.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Fred Kleinsorge
Bill Todd wrote in message ...
> ...
You want some cheese with your whine?
Oh my, Itanium-2 doesn't suck. Let me see if I can throw in a bunch of
other unsupported speculation to show why I wasn't wrong, or maybe someone's
lying, or maybe the Intel reference platform won't be as fast as HP's
system, or anyway - it will still suck later. And if that isn't enough, I
can always complain that the mythical EV8 would still have kicked it's ass.
Fred Kleinsorge
Nick Maclaren wrote in message ...
>
>Less than you appear to think. Intel's record here is ghastly; for
>20 years, Intel has had a reputation for quoting figures that nobody
>else can reach, or that use unreasonable (and often unsold) features.
>In academia, journals stop publishing authors who do that ....
>
>The question is whether HP have descended to that level. I doubt it,
>but it isn't implausible. A more serious point is that we have VERY
>good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
>are worth 10-20% on SpecInt. That would make a best guess at the
>McKinley's SpecInt performance using Intel's compiler on Bandera
>600-650. And, lastly, ask your HP salesman about the availability
>of the HP compiler on other than HP-UX.
>
You know, this is a bit less than fair. You make a statement designed to
imply you think HP may be lying about the performance.
Then you complain that Itanium-2 still may suck in some other
implementation. Hey, guess what - Spec results vary from platform to
platform. Other than the whine about IBM's turning off a CPU core on their
Power-4 results, you seldom see people all up in arms that 2 platforms with
the same CPU chip have different Spec results.
Well, what it shows is that the Itanium-2 chip *is* capable high
performance. The fact that the Intel reference platform "might" have lower
performance numbers doesn't mean the CPU sucks. It means that HP is serious
about getting the best out of it.
And hey, the GNU people walk on water right? So have them make GCC better.
Was/is there some obligation on HP's part to make Linux on somebody elses
box run faster?
>>> That said, if HP's numbers are even close to correct McKinley has come
in
>>> considerably better than I expected it to, and there may be some reason
to
>> You don't have much use for EPIC? Why? Performs much better
>> than expected? Is there a lurking contradiction I am not quite
>> highlighting?
>
>I don't, and have posted my reservations for 8 years. I shall not
>repeat them here, except one I refer to below, but please note that
>they will be proved only when real IA-64 systems are used with real
>loads by real users. Benchmarks are notorious for not showing up
>performance and reliability problems.
>
Ah yes. We will. And if "real life" performance backs up the claims, I
assume that you will acknowledge that you were wrong? Just a few weeks ago,
some people here were claiming that the customer testimonial of better
performance than Sun was something being used to cover up bad Spec scores.
>> Ummm... for meaningfully different, how about a metric everyone loves?
>> $/tpmC.
>
>Yes. WHEN IA-64 systems are in full production. At present, they
>are in introduction, and the prices are more than usually artificial.
>
What makes the prices artificial? You think when it is in "full production"
the prices will rise? I can understand your frustration that the systems
appear not to be available in the normal time (it took about a week to get
Itanium-1's when we ordered them - pre-merger). Which, frankly isn't
anything new. Look at Alpha's - we announced them and make them orderable,
but generally speaking they are initially backordered while production ramps
up.
>> That's a bold prediction. Here is another one:
>>From: "Bill Todd" <bill...@metrocast.net>
>>
>>"McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especially
>>given that this is the core users will have to live with (with only a
>>process shrink/cache bump) until at least 2005: 700 max, possibly as low
as
>>600, probably around 650."
>
>That is what almost everyone thought then, and may still be true for
>Intel's compiler on Bandera. My guess still is that it will be.
>
Who cares? Except as a way of mitigating Bill's lowball guess. Fine.
Let's assume he is right on some other platform box, heck I can make an
Alpha EV6 score a 153 if I build a bad system around it. It would not
suprise me if the Intel reference parts were not as fast. The fact is that
you can buy a HP system with that CPU with a SpecInt of 810. Admit that it
is pretty good score, and that the CPU - even with the despised EPIC -
apparently doesn't suck as bad as some had hoped.
>> Now maybe there are some pretty substantial compiler optimizations
>> left on the table. Especially with that 6MB L3. After all, if
>> guesses are consistent, we can expect at least a 40% SpecInt performance
>> improvement McKinley to Madison, would be a reasonable guess.
>> You agree?
>
>I should be flabberghasted. The IA-64 software project as a whole
>was the largest one since the Sytem/360, and the compiler work was
>probably 2/3 of that. 8 years of well-funded work following on
>from 25 years of ubiquitous research doesn't leave many cherries
>to pick, and you can't produce breakthroughs to order.
>
I'm not in a position to even guess. But I love it when people say things
like this, because inevitably the breakthrough does come. How many "hard
barriers" in many fields that people believed would never be broken have
fallen.
>Remember that the problem is primarily in program analysis, and not
>in code generation. Now, one aspect that could have MASSIVE effects
>on SpecInt is with the adoption of C99 (mainly if it used restrict,
>but there is also type-controlled aliasing). However, any compiler
>that uses the latter will cause HUGE numbers of widespread programs
>to break, so it isn't a 'fair' optimisation. But was it used? We
>don't know yet.
>
Frankly, I expect when/if some breakthrough does occur, Spec will be
obsolele - and some other measurement will be needed.
>> Yeah but... at $5 per tpmC for McKinley, no one is going to touch
>> that until Madison and Madison for sure. Also, don't overlook
>> $/Specfp that will help a great deal for folks looking at a number
>> cruncher on a tight budget.
>
>Maybe. Those of us who are deeply into number-crunching are less
>convinced by the IA-64 line than we were 5+ years ago, as the
>interesting little "gotchas" emerge. When and if McKinley systems
>become available to independent HPC people, evidence of their
>desirability (or the converse) will start to emerge.
>
Well, it's orderable. So order one. Or wait until you can get a delivery
date on your order. If the Spec figures hold up, and the prices are not
"articifical" - it looks like you would get a respectable UNIX (HP-UX) and a
fast box, for a good price.
JF Mezei
> but it isn't implausible. A more serious point is that we have VERY
> good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
> are worth 10-20% on SpecInt.
Who does what compiler for IA64 ? Does HP have its own compilers or does it
rely on the Intel compilers ?
Have the ex-Digital compiler folks who were donated to Intel begun to make
significant changes to Intel's compilers or are they still just settling into
their new job ? is there a feeling that Intel's compilers are poised for
significant improvements or have they pretty well reached "maturity" in terms
of generating code that makes best possible use of EPIC ?
Terry C. Shannon
"Fred Kleinsorge" <klein...@star.zko.dec.com> wrote in message
news:GHCW8.27$FZ5.4...@news.cpqcorp.net...
>
> Nick Maclaren wrote in message ...
> >
> >Less than you appear to think. Intel's record here is ghastly; for
> >20 years, Intel has had a reputation for quoting figures that nobody
> >else can reach, or that use unreasonable (and often unsold) features.
> >In academia, journals stop publishing authors who do that ....
> >
> >The question is whether HP have descended to that level. I doubt it,
> >but it isn't implausible. A more serious point is that we have VERY
> >good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
> >are worth 10-20% on SpecInt. That would make a best guess at the
> >McKinley's SpecInt performance using Intel's compiler on Bandera
> >600-650. And, lastly, ask your HP salesman about the availability
> >of the HP compiler on other than HP-UX.
> >
>
> You know, this is a bit less than fair. You make a statement designed to
> imply you think HP may be lying about the performance.
Well, I wouldn't go that far. I read the statement as an allusion to some of
the obscure and irreproducible metrics INTC has used in the past.
And yep, the zx1 chipset and HPQ compilers are responsible for some of the
performance. To me this is not a Bad Thing... on the contrary, it sheds
light on one of the ways in which HPQ hopes to differentiate itself in the
"industry standard" space. Note that CPQ did the same thing with the 8-way
ProLiant and its ProFusion chipset.
IBM of course has a chipset of its own; have to see how things pan out with
our friends in Armonk.
Whether you like INTC or not, you have to admit, the initial HPQ numbers for
McKinley are a helluva lot better than the numbers for Itanic 1. And it
appears that there's more ISV buy-in to McKinley than there was to the
first-generation chip. I wouldn't rush out and buy a McKinley platform today
(assuming that such was available today) but it seems awfully early in the
cycle to doom the chip to failure.
Nick Maclaren
In article <GHCW8.27$FZ5.4...@news.cpqcorp.net>,
"Fred Kleinsorge" <klein...@star.zko.dec.com> writes:
|> Nick Maclaren wrote in message ...
|> >
|> >Less than you appear to think. Intel's record here is ghastly; for
|> >20 years, Intel has had a reputation for quoting figures that nobody
|> >else can reach, or that use unreasonable (and often unsold) features.
|> >In academia, journals stop publishing authors who do that ....
|> >
|> >The question is whether HP have descended to that level. I doubt it,
|> >but it isn't implausible. A more serious point is that we have VERY
|> >good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
|> >are worth 10-20% on SpecInt. That would make a best guess at the
|> >McKinley's SpecInt performance using Intel's compiler on Bandera
|> >600-650. And, lastly, ask your HP salesman about the availability
|> >of the HP compiler on other than HP-UX.
|>
|> You know, this is a bit less than fair. You make a statement designed to
|> imply you think HP may be lying about the performance.
I said explicitly that I think that they AREN'T lying, but that it
cannot yet be ruled out. Please reread the above.
|> Then you complain that Itanium-2 still may suck in some other
|> implementation. Hey, guess what - Spec results vary from platform to
|> platform. Other than the whine about IBM's turning off a CPU core on their
|> Power-4 results, you seldom see people all up in arms that 2 platforms with
|> the same CPU chip have different Spec results.
Few architectures have such dependence on the chipset and compiler
as the IA-64 does. Furthermore, HP themselves have made claims
that much of their performance advantages are PRECISELY because
of their chipset and compiler! See, for example:
http://www.theregister.co.uk/content/3/26097.html
I cannot offhand remember the similar compiler reference, but it
is around somewhere, and its truth is immediately apparent by
looking at the published results on www.spec.org CAREFULLY.
I suggest that you do so.
|> Well, what it shows is that the Itanium-2 chip *is* capable high
|> performance. The fact that the Intel reference platform "might" have lower
|> performance numbers doesn't mean the CPU sucks. It means that HP is serious
|> about getting the best out of it.
All of that is true. But it is also true that it is much harder to
get performance out of it than out of many other chips. And that
is a relevant point to those of us who have to work with limited
effort, horrible applications and source not under our control.
|> Ah yes. We will. And if "real life" performance backs up the claims, I
|> assume that you will acknowledge that you were wrong? Just a few weeks ago,
|> some people here were claiming that the customer testimonial of better
|> performance than Sun was something being used to cover up bad Spec scores.
I will. And you are misremembering. It isn't hard to select a good
testimonial if you are prepared to choose the best out of hundreds.
|> What makes the prices artificial? You think when it is in "full production"
|> the prices will rise? I can understand your frustration that the systems
|> appear not to be available in the normal time (it took about a week to get
|> Itanium-1's when we ordered them - pre-merger). Which, frankly isn't
|> anything new. Look at Alpha's - we announced them and make them orderable,
|> but generally speaking they are initially backordered while production ramps
|> up.
Every heard of selling below a viable price to get a product line
introduced? No? Most vendors of most things do it.
|> I'm not in a position to even guess. But I love it when people say things
|> like this, because inevitably the breakthrough does come. How many "hard
|> barriers" in many fields that people believed would never be broken have
|> fallen.
Well, I am. "Inevitably the breakthrough does come"? Oh, yeah?
Remember the repeated claims that new designed would mean that
memory latencies would start to fall as fast as cache ones?
Software has similar problems, and this is one of them.
|> Well, it's orderable. So order one. Or wait until you can get a delivery
|> date on your order. If the Spec figures hold up, and the prices are not
|> "articifical" - it looks like you would get a respectable UNIX (HP-UX) and a
|> fast box, for a good price.
Oh, is it? I tried to get a quote, just this morning. Nope. Not
on our list. And got the same response from HP's "buy online".
Greg Cagle
HP has its own set of compilers on HP-UX for Itanium 2. Intel has a set as
well for Windows and Linux.
--
Greg Cagle
gregc at gregcagle dot com
Nick Maclaren
In article <RoDW8.291766$R61.1...@rwcrnsc52.ops.asp.att.net>,
"Terry C. Shannon" <terrys...@attbi.com> writes:
|>
|> Whether you like INTC or not, you have to admit, the initial HPQ numbers for
|> McKinley are a helluva lot better than the numbers for Itanic 1. And it
|> appears that there's more ISV buy-in to McKinley than there was to the
|> first-generation chip. I wouldn't rush out and buy a McKinley platform today
|> (assuming that such was available today) but it seems awfully early in the
|> cycle to doom the chip to failure.
Definitely. The signs are very mixed. Yes, HP has got the chip
to perform, if not up to the wildest claims, enough to say that
it is a (or even the) leader. Hence my interest in getting one.
But the support from other OEMs is minimal (so far, at least),
there are no McKinley servers, we don't know if HP will be
licensing its chipset and compiler, and so on. Especially if
HP's systems outperform others by 25%, this is not a minor
matter.
Most of all, we don't yet know how well such systems will both
perform and work in the field. There are some very disquieting
rumours, as well as my doubts due to analysis of the design.
For example, most HPC people are at least as interested in MPI
or OpenMP latency as we are in scalar performance.
How well will it work, when typically revolting programs
are compiled and tuned by people who are NOT IA-64 experts?
And will it mean an increase in the number of 'insoluble' bugs,
such as those that bedevil us in HPC already?
And so on.
Paul Winalski
a top-end IA-32 system ruling the roost on SpecINT. McK was tops
on SpecFP, though.
What is clear is that McKinley isn't the performance disaster that
Merced was. McK's integer numbers are comparable to the
current competition and the FP numbers look quite good indeed.
McK has done a lot better than I, for one, expected it to do.
Whether this is good enough to sustain the IPF architecture in the
face of the competition is still an open question.
On 8 Jul 2002 13:30:01 -0600, you...@encompasserve.org (Rob Young)
wrote:
----------
Remove 'Z' to reply by email.
Paul Winalski
<klein...@star.zko.dec.com> wrote:
>Well, what it shows is that the Itanium-2 chip *is* capable high
>performance.
With a good tail wind behind it, anyway (i.e., extensive profile
feedback to a compiler designed specifically to win spec and
other benchmarks).
But that's the way everyone does Spec and other benchmarks.
It's like qualifying for the Indy 500. You tune the car and engine
for top speed, you put in only as much fuel as you need to do the
6 laps in the qualifying run, and sometimes you even go to lengths
such as taking all the gears out of the gearbox except top gear.
Nobody would ever set up their car that way for the real race,
but they all do it for qualifying. Benchmark runs are a similarly
artificial situation.
>The fact that the Intel reference platform "might" have lower
>performance numbers doesn't mean the CPU sucks. It means that HP is serious
>about getting the best out of it.
The benchmark that I'll be interested to see is McK's web server
performance.
Paul Winalski
<jfmezei...@videotron.ca> wrote:
>Who does what compiler for IA64 ? Does HP have its own compilers or does it
>rely on the Intel compilers ?
IIRC, Intel's compiler was used, but the benchmark runs were on HP/UX.
>Have the ex-Digital compiler folks who were donated to Intel begun to make
>significant changes to Intel's compilers or are they still just settling into
>their new job ? is there a feeling that Intel's compilers are poised for
>significant improvements or have they pretty well reached "maturity" in terms
>of generating code that makes best possible use of EPIC ?
Generating the best possible code for EPIC is still very much
unexplored territory for compiler technology.
Paul Winalski
>My bet is that HP will NOT publish any SPEC performance numbers for EV68 or
>EV7.
>
>Why, you ask? Because they have no need to. And why would they want to make
>their multi-billion dollar investment in Itanic look bad?
I think you're right about this. Alpha is conspicuously absent from
the performance charts published at the HP website.
From a marketing standpoint, it makes no sense for HP to be
showcasing Alpha performance. Why promote a CPU architecture
that you're trying to shut down? Especially when it would steal
the limelight from the architecture you're touting as its replacement.
From HP's perspective, there is no reason to promote Alpha. Those
who are stuck with the Alpha platform will buy it because they have
no choice. By throwing all its promotional effort behind Itanium, HP
hopes to lure those who do have a choice to Itanium.
I therefore fully expect to see Alpha studiously ignored from now on.
Terry C. Shannon
"Paul Winalski" <pr...@ZAnkh-Morpork.mv.com> wrote in message
news:3d2b0c4c....@proxy.news.easynews.com...
Umm, when the ES80 and GS1280 come out, do you think they will be devoid of
performance metrics? And what of the 1.25GHz ES45 and GS320 due out in a
month or so?
Paul Winalski
<jfmezei...@videotron.ca> wrote:
>Question:
>
>IA64 is "EPIC" where it expects the compiler to do all the work to make best
>use of the chip's architecture.
>
>In the Intel released results for IA64, was it done with normal commercial
>applications compiled using whatever commercially available compilers exist
>for IA64, was was it done with specially tweaked applications designed
>carefully to generate the best possible speed results ?
The benchmarks in question are industry-standard benchmarks,
using code approved by an industry-wide committee in which all
the vendors and other interested parties participate. The code that
is compiled is exactly the same for all the systems that are tested
and for which results are published. The benchmark applications
are not allowed to be tweaked.
The vendor or other party that runs the benchmarks does have some
latitude in choice of compiler, compilation options, and hardware and
OS platform. For the "base" Spec numbers, there are limits on the
number of special options that one can use in the compilations.
Furthermore, all components of the platform (hardware, OS, compiler)
must be available to the public within 6 months of the publication of
the benchmark numbers.
So there is some tweaking, in that the numbers don't have to come
from using the compiler's default options, but everything used to
create the benchmark numbers has to be off-the-shelf hardware
and software, such that anyone in the general public could build
the benchmark configuration and reproduce the same results.
>If the Intel released specs don't reflect what commercial applicatiosn will
>deliver, then the question is how big a gap there will be between Intel's
>"dream" specs, and what real world performance will be delivered.
That's always the big question. It's kind of like the EPA MPG numbers
for automobiles--the numbers are useful for comparing different models
of car, but whether you'd ever achieve that performance in actual
driving is often doubtful.
>Will Intel's commercial compilers really be able to take code not specifiaclly
>designed for IA64 and generate assembler that makes best use of IA64's
>potential ?
Again, the benchmarks aren't specifically designed for IA64, or for
any other architecture, for that matter. The Spec test suite is a set
of moderately-sized real world applications specifically chosen to
test the integer (in the case of SpecINT) or floating point (in the
case of SpecFP) performance of a computer system.
Whether IA64 can deliver as good performance as its rivals in the
absence of profile-directed feedback and other such advanced
optimization techniques is an interesting question. An awful lot of
application developers just build their apps with the default compiler
options, or compile with optimization turned off (a habit acquired
due to the buggy nature of the optimizers in early UNIX compilers).
JF Mezei
> Few architectures have such dependence on the chipset and compiler
> as the IA-64 does. Furthermore, HP themselves have made claims
> that much of their performance advantages are PRECISELY because
> of their chipset and compiler! See, for example:
I am perplexed as to why HP still has its own IA64 compiler(s) ? On what
platform does HP's compiler(s) run ? Just HP-UX or also on Windows ?
When the time comes to have VMS, NSK HP-UX and Widnows on IA64, which OS will
get whose compilers ?
I was under the impression that VMS would inherit the Intel compilers. If the
HP compilers are superior, doesn't this mean that VMS would be at a
disadvantage versus the HP products thathave HP compilers ?
JF Mezei
> Whether this is good enough to sustain the IPF architecture in the
> face of the competition is still an open question.
Also, McKinley is brand spanking new, and currently being compared agaist
older existing chips. When those chips get their upgrades, how will McKinley
fare ?
Is everyone just planning speed bumps for the next few years, or is a
competitor to IA64 planning a more significant improvement to their chip which
would widen the gap ?
Speed bumb may make a chip faster, but it won't really change its
competitiveness since everyone will get the same speed bumps roughly at the
same time.
Nick Maclaren
In article <3D2B15D1...@videotron.ca>,
JF Mezei <jfmezei...@videotron.ca> writes:
|> Nick Maclaren wrote:
|>
|> > Few architectures have such dependence on the chipset and compiler
|> > as the IA-64 does. Furthermore, HP themselves have made claims
|> > that much of their performance advantages are PRECISELY because
|> > of their chipset and compiler! See, for example:
|>
|> I am perplexed as to why HP still has its own IA64 compiler(s) ? On what
|> platform does HP's compiler(s) run ? Just HP-UX or also on Windows ?
|>
|> When the time comes to have VMS, NSK HP-UX and Widnows on IA64, which OS will
|> get whose compilers ?
You would have to ask HP. Don't forget there is also Linux :-)
Now the relevant products are announced, it is a fair question
to ask an HP salesman.
|> I was under the impression that VMS would inherit the Intel compilers. If the
|> HP compilers are superior, doesn't this mean that VMS would be at a
|> disadvantage versus the HP products thathave HP compilers ?
At the OpenVMS meeting, the strategic C compiler was said to be
Intel's, but most of the others were Compaq's (ported). The
Fortran was under consideration for being changed to use Intel's
Electron back end.
I was extremely surprised that there was no reference to using
HP's compilers under VMS, though it was and is not directly
relevant to us.
Rob Young
> Hmm. Doesn't match the numbers at the HP website, which showed
> a top-end IA-32 system ruling the roost on SpecINT. McK was tops
> on SpecFP, though.
>
An oversight on your part. All about sourcing and I get
mine turned around too often also.
http://www.hp.com/hpinfo/newsroom/press/08jul02b.htm
Commercial compute core: Itanium 2-based systems from HP with the HP Chipset
zx1 outperformed the best from IBM and Sun. HP achieved a SPECintbase_2000
score of 810 and 807 on an HP Server rx2600 and HP Workstation zx6000,
respectively.(5)
> What is clear is that McKinley isn't the performance disaster that
> Merced was.
Right. Leading in many metrics as far as I can tell and substantially
in several (TPC-C 4 processor boxes for instance.)
McK's integer numbers are comparable to the
> current competition and the FP numbers look quite good indeed.
> McK has done a lot better than I, for one, expected it to do.
>
> Whether this is good enough to sustain the IPF architecture in the
> face of the competition is still an open question.
>
I think very good pricing is the angle. Expensive and fast
isn't the way to overtake a segment. Fast and cheaper
is probably the only way.
Rob
Fred Kleinsorge
Nick Maclaren wrote in message ...
>
>
>cannot yet be ruled out. Please reread the above.
>
I did. Your statements were designed to imply that HP might be lying, in an
effort to discount the credibility of the numbers. What would you say if I
wrote: "There is this fellow "XX" in the UK who writes in newsgroups, and
who is a lying bag of wind. It remains to be seen if his fellow contryman
"NM" who recently wrote in the same newsgroup also stoops to his level."
See. I didn't call you anything. But I implyed that by association, you
would certainly be capable of something.
>
>All of that is true. But it is also true that it is much harder to
>get performance out of it than out of many other chips. And that
>is a relevant point to those of us who have to work with limited
>effort, horrible applications and source not under our control.
>
Is it? Perhaps the guys at HP are just better at designing for performance.
It also sounds to me that if the compiler is really a large part of the
issue (and I tend to doubt it, knowing some of the compiler people that we
sent to Intel) then I guess the companies who are supplying SW
binaries/objects should get themselves HP systems to do the compiles on.
>
>I will. And you are misremembering. It isn't hard to select a good
>testimonial if you are prepared to choose the best out of hundreds.
>
Sure. Nonetheless, my point is that "some" people want to create a moving
bar, so that as each possible complaint/suspicion is answered, they can
continually not be satisfied. At least put a stake in the ground as to
exactly what it will take... and perhaps that is even having the system in
your hands running your code. I believe that if you had the system in your
hands, and it did perform flawlessly - you would concede that despite it's
potential faults, it was a good system. There are others in here who will
probably stop writing in these groups before they make such a concession.
>
>Every heard of selling below a viable price to get a product line
>introduced? No? Most vendors of most things do it.
>
It's an interesting concept, but it doesn't match up with anything I have
heard since becoming part of HP. These guys (the guys building the systems
in the UNIX market) don't build a system unless they can make a profit on
it. They don't lose money to buy market share from what I can tell.
>
>Well, I am. "Inevitably the breakthrough does come"? Oh, yeah?
>Remember the repeated claims that new designed would mean that
>memory latencies would start to fall as fast as cache ones?
>Software has similar problems, and this is one of them.
>
We'll see. In your case above, I think that looking out for profits is what
is driving things, not technology. Look at the EV7 RAMBUS design. There
isn't much out there that can touch it's performance. But I don't think
you'll see a stampede to follow the technology.
>|> Well, it's orderable. So order one. Or wait until you can get a
delivery
>|> date on your order. If the Spec figures hold up, and the prices are not
>|> "articifical" - it looks like you would get a respectable UNIX (HP-UX)
and a
>|> fast box, for a good price.
>
>Oh, is it? I tried to get a quote, just this morning. Nope. Not
>on our list. And got the same response from HP's "buy online".
>
Hmm. That is suprising. I didn't follow the links all the way to making
the purchase, but it all seemed to be on the web site. I assume/hope that
it's just a screw up someplace. I know that we are now working on our plan
to start buying them and dumping the Itanium-1's we were using for
development.
Terry C. Shannon
<snip>
> I think very good pricing is the angle. Expensive and fast
> isn't the way to overtake a segment. Fast and cheaper
> is probably the only way.
>
> Rob
A damned shame the Alpha advocates at DECpaq never came to this conclusion.
Fred Kleinsorge
was under the impression that the Intel compiler and the MS compiler were
the ones everyone used.
In the VMS case, we have a number of compilers required for the OS. The
initial ones are based on the DEC developed GEM back end, and the DEC/Compaq
compiler front ends. Why? Well, for compatability for the most part. So
right now it doesn't matter even if HP had their own.
Long term, the C/C++ compiler would be the one from Intel, and Intel is
making changes in it needed for VMS as well. Long term, I expect that the
Intel compiler will be the best compiler - especially knowing some of the
people that we sent them (and at least one was almost immediately made an
Intel Fellow).
Nick Maclaren wrote in message ...
>
Andrew Harrison SUNUK Consultancy
JF Mezei wrote:
> Nick Maclaren wrote:
>
>>but it isn't implausible. A more serious point is that we have VERY
>>good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler
>>are worth 10-20% on SpecInt.
>>
>
> Who does what compiler for IA64 ? Does HP have its own compilers or does it
> rely on the Intel compilers ?
>
HP do their own compiler, Intel do one as well. Unless
you have the HP compiler you cannot get the SPECint/fp
results being posted for the platform. Estimates for
the Intel compilers performance vary but are all lower
than the numbers being delivered by the current boxes.
More confusion for ISV's.
Regards
Andrew Harrison
Fred Kleinsorge
spokesperson.
So, SAndy - exactly what *is* the Sun response? How about "perhaps some
other compiler will make it as slow as a Sun"? Or maybe "well, to actually
get that performance you can't run Solaris". Or "well, they haven't run the
benchmark that our internal committee decided yesterday was the best way to
compare systems".
Yeah. That''ll do.
Keep up the good work, and pray for Hammer to deliver Solaris from defeat.
_Fred
Andrew Harrison SUNUK Consultancy wrote in message ...
Rob Young
That was left unsaid but my exact thoughts. All about scale, really.
Instead of giving NT away (via MS sweetheart deal), they might have
gone to Intel early on and literally given Alpha away. I do know
talks took place but the talk should have been: "Here, take it.
The only way this will take off is if you take it." That would
have been a career killer for several so of course it didn't happen.
Instead, Intel bided their time and waited for the second go round
of knocks on the door where what they got that time was some
interesting technology to stuff into EPIC instead of owning and
growing a tremendous architecture with EV6/EV7/EV8/EV9 futures.
Rob
Greg Cagle
"More confusion?" No more than normal 8^). Use the compiler for the
platform/OS combination that is the target:
Itanium 2 running HP-UX - use HP compiler.
Itanium 2 running Linux - use Intel.
Itanium 2 running Windows - use Intel.
Are you implying that Sun has the *same compiler* for Sparc *and* x86 targets?
Nick Maclaren
Fred Kleinsorge <klein...@star.zko.dec.com> wrote:
>Frankly, I couldn't tell you if there is a HP-UX-specific C/C++ compiler. I
>was under the impression that the Intel compiler and the MS compiler were
>the ones everyone used.
Then I suggest that you quote performance figures based on them,
and do not flame me when I point out that the figures quoted by
HP on Monday are not what most McKinley customers will get.
>In the VMS case, we have a number of compilers required for the OS. The
>initial ones are based on the DEC developed GEM back end, and the DEC/Compaq
>compiler front ends. Why? Well, for compatability for the most part. So
>right now it doesn't matter even if HP had their own.
That is precisely what you said at the OpenVMS forum and, yes, right
now it doesn't matter. What surprised me was that the strategic
direction seemed to be out-of-house, lower performance compilers
based on Intel's technology rather than HP's. You may well have
good reasons, but they didn't emerge.
>Long term, the C/C++ compiler would be the one from Intel, and Intel is
>making changes in it needed for VMS as well. Long term, I expect that the
>Intel compiler will be the best compiler - especially knowing some of the
>people that we sent them (and at least one was almost immediately made an
>Intel Fellow).
Hmm. There is an old joke about a Scotsman who emigrated to England,
raising the average intelligence of both countries.
Nick Maclaren
Fred Kleinsorge <klein...@star.zko.dec.com> wrote:
>Not confusion for ISV's, just more FUD from SAndy our proud Sun
>spokesperson.
Well, speaking as a consultant for ISV's, he is right.
Fred Kleinsorge
Nick Maclaren wrote in message ...
>Fred Kleinsorge <klein...@star.zko.dec.com> wrote:
>>Frankly, I couldn't tell you if there is a HP-UX-specific C/C++ compiler.
I
>>was under the impression that the Intel compiler and the MS compiler were
>>the ones everyone used.
>
>Then I suggest that you quote performance figures based on them,
>and do not flame me when I point out that the figures quoted by
>HP on Monday are not what most McKinley customers will get.
>
They'll be the ones that buy the system from HP. I'm kind-of hoping most of
them *are* HP customers.
Nick Maclaren
Fred Kleinsorge <klein...@star.zko.dec.com> wrote:
>Nick Maclaren wrote in message ...
>>
>>I said explicitly that I think that they AREN'T lying, but that it
>>cannot yet be ruled out. Please reread the above.
>
>I did. Your statements were designed to imply that HP might be lying, in an
>effort to discount the credibility of the numbers. What would you say if I
>wrote: "There is this fellow "XX" in the UK who writes in newsgroups, and
>who is a lying bag of wind. It remains to be seen if his fellow contryman
>"NM" who recently wrote in the same newsgroup also stoops to his level."
>
>See. I didn't call you anything. But I implyed that by association, you
>would certainly be capable of something.
Sigh. If I had got together with (say) Jeffery Archer and posted
a claim about a matter which we were jointly engaged in, you
would be perfectly justified in being suspicious that I was lying.
My previous reputation would be sullied by association.
>>All of that is true. But it is also true that it is much harder to
>>get performance out of it than out of many other chips. And that
>>is a relevant point to those of us who have to work with limited
>>effort, horrible applications and source not under our control.
>
>Is it? Perhaps the guys at HP are just better at designing for performance.
>It also sounds to me that if the compiler is really a large part of the
>issue (and I tend to doubt it, knowing some of the compiler people that we
>sent to Intel) then I guess the companies who are supplying SW
>binaries/objects should get themselves HP systems to do the compiles on.
I have news for you. It isn't possible to run the HP-UX compiler
under Linux or even compile binaries under HP-UX for use under Linux,
at least not using a normal HP licence and if you want support.
And that applies even to HP supplied and supported Linux systems,
which have several (unrelated) performance advantages over HP-UX
ones.
>>I will. And you are misremembering. It isn't hard to select a good
>>testimonial if you are prepared to choose the best out of hundreds.
>
>Sure. Nonetheless, my point is that "some" people want to create a moving
>bar, so that as each possible complaint/suspicion is answered, they can
>continually not be satisfied. At least put a stake in the ground as to
>exactly what it will take... and perhaps that is even having the system in
>your hands running your code. I believe that if you had the system in your
>hands, and it did perform flawlessly - you would concede that despite it's
>potential faults, it was a good system. There are others in here who will
>probably stop writing in these groups before they make such a concession.
That is true. But, as a statistician, I am very dubious about all
figures that are selected by someone who has a mahor financial
interest in biassing them.
>>|> Well, it's orderable. So order one. Or wait until you can get a
>delivery
>>|> date on your order. If the Spec figures hold up, and the prices are not
>>|> "articifical" - it looks like you would get a respectable UNIX (HP-UX)
>and a
>>|> fast box, for a good price.
>>
>>Oh, is it? I tried to get a quote, just this morning. Nope. Not
>>on our list. And got the same response from HP's "buy online".
>
>Hmm. That is suprising. I didn't follow the links all the way to making
>the purchase, but it all seemed to be on the web site. I assume/hope that
>it's just a screw up someplace. I know that we are now working on our plan
>to start buying them and dumping the Itanium-1's we were using for
>development.
It does seem that is likely. I shall check a bit further and see.
JF Mezei
> In the VMS case, we have a number of compilers required for the OS. The
> initial ones are based on the DEC developed GEM back end, and the DEC/Compaq
> compiler front ends. Why? Well, for compatability for the most part. So
> right now it doesn't matter even if HP had their own.
Did I hear this right ? The "real" DEC compilers have been ported to IA64 to
allow you to compile VMS ?
I am totally confused. One hears news of Compaq having donated all its
compiler and compiler people to Intel and that from now On, compilers on Alpha
would only get minimal maintenance and that VMS would rely on Intel compilers
for IA64. Then we hear news that some of the Digital compiler people are still
with Compaq (now HP). Now you tell me that some of the Digital compilers were
ported to IA64 and that this is what you're using to port VMS initially.
Is there some document that CLEARLY explains exeactly what the compiler story
REALLY is ?
JF Mezei
> Then I suggest that you quote performance figures based on them,
> and do not flame me when I point out that the figures quoted by
> HP on Monday are not what most McKinley customers will get.
Since IA64 is currently still poised to be mostly HP's chip, much like Alpha
was Digital's stating that most IA64 customers would be running HP's compiler
might not be wrong.
JF Mezei
> They'll be the ones that buy the system from HP. I'm kind-of hoping most of
> them *are* HP customers.
While I understand what you may have meant, that same statement can also be
interpreted that you hope IA64 is a failure and remains HP's proprietary chip
that isn't used much outside of HP.
Bill Todd
"Fred Kleinsorge" <klein...@star.zko.dec.com> wrote in message
news:SeCW8.25$8Y5.3...@news.cpqcorp.net...
>
> Bill Todd wrote in message ...
>
> > ...
>
> You want some cheese with your whine?
>
> Oh my, Itanium-2 doesn't suck. Let me see if I can throw in a bunch of
> other unsupported speculation to show why I wasn't wrong, or maybe
someone's
> lying, or maybe the Intel reference platform won't be as fast as HP's
> system, or anyway - it will still suck later. And if that isn't enough, I
> can always complain that the mythical EV8 would still have kicked it's
ass.
You're starting to sound like a confirmed shit-head, Fred. If you don't
care to respond to specifics, just fuck off.
- bill
John Smith
"Terry C. Shannon" <terrys...@attbi.com> wrote in message
news:W8EW8.339218$6m5.3...@rwcrnsc51.ops.asp.att.net...
IMHO, HP will show some 'non-published' numbers to those *existing*
customers who are likely candidates to need more Alpha horsepower.
Since HP does *NOT* sell to *new* non-VMS customers any longer (a paraphrase
of their words), why should they go to the effort of pointing out that they
bought a superior (albeit, dead) technology that obviates the need for
Itanic. Mustn't forget that they've "burned their bridges behind them".
I can see the ads now:
"Our dead processor family beats the pants off the new crap we're trying to
stuff down your throats."
or
"You'll just love spending money porting your applications, data, and
3rd-party software licenses to our new underperforming processor line."
and
"Larry Ellison will charge you twice as much to do the
same amount of work on Itanic vs. Alpha EV7.
HP - always thinking about the bottom line. Ours."
Nick Maclaren
HP's IA-64 announcement referred to 3 operating systems: HP-UX,
Linux and some sort of Microsoft product. It has at least two
others under development: VMS and NSK. Microsoft has said that
it is developing .NET. As far as I know, HP's compilers are
available only for HP-UX, and that is not going to change.
In particular, this is comp.os.vms, and VMS has been stated to
be planned NOT to use HP's compiler. I think that I am being
fairly reasonable in pointing out that performance figures
obtainable only with HP's compilers aren't what customers will
get.
Nick Maclaren
John Smith <a...@nonymous.com> wrote:
>
>IMHO, HP will show some 'non-published' numbers to those *existing*
>customers who are likely candidates to need more Alpha horsepower.
>
>Since HP does *NOT* sell to *new* non-VMS customers any longer (a paraphrase
>of their words), why should they go to the effort of pointing out that they
>bought a superior (albeit, dead) technology that obviates the need for
>Itanic. Mustn't forget that they've "burned their bridges behind them".
Is that so, indeed? That could explain a great deal. Do you have
a reference to those words?
Bill Todd
Can't have it both ways, Fred.
If most McKinley customers are HP customers, then any claim to being an
'industry standard' will be pure myth and, just as Dell did, the other
vendors currently pledging to support the platform will withdraw that
support: not only will supporting it not be worth their while, but
withdrawing support will help to damage their HP competition (by making the
platform's 'proprietary' nature clear).
OTOH, if most McKinley customers *aren't* HP customers, then unless HP makes
its compilers and chip sets available to other vendors and OSs McKinley and
its descendants won't be as attractive to most of the world as the HP SPEC
results would suggest.
So if HP indeed enjoys a significant (proprietary) advantage due to its
compilers and chip set, it will have to decide whether to exploit it (and
likely in the process limit acceptance of the underlying processor by the
rest of the industry) or make those components available to the world
(boosting Intel's fortunes and - perhaps - its own as well: kind of reminds
me of supply-side economics...).
- bill
John Smith
"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:agfg2e$72h$1...@pegasus.csx.cam.ac.uk...
> In article <FeHW8.3647$UHe1...@news01.bloor.is.net.cable.rogers.com>,
> John Smith <a...@nonymous.com> wrote:
> >
> >IMHO, HP will show some 'non-published' numbers to those *existing*
> >customers who are likely candidates to need more Alpha horsepower.
> >
> >Since HP does *NOT* sell to *new* non-VMS customers any longer (a
paraphrase
> >of their words), why should they go to the effort of pointing out that
they
> >bought a superior (albeit, dead) technology that obviates the need for
> >Itanic. Mustn't forget that they've "burned their bridges behind them".
>
> Is that so, indeed? That could explain a great deal. Do you have
> a reference to those words?
It was in a bunch of stuff that came out in early May...said something to
the effect of 'OpenVMS will be continued to be sold to existing customers
and *selected* new accounts'. I will attempt to find the reference for you.
Terry C. Shannon
"John Smith" <a...@nonymous.com> wrote in message
news:FeHW8.3647$UHe1...@news01.bloor.is.net.cable.rogers.com...
Well, they seem to be spending a lot of time and effort on EV7/Marvel
performance characterization these days.
>
> Since HP does *NOT* sell to *new* non-VMS customers any longer (a
paraphrase
> of their words), why should they go to the effort of pointing out that
they
> bought a superior (albeit, dead) technology that obviates the need for
> Itanic. Mustn't forget that they've "burned their bridges behind them".
>
>
> I can see the ads now:
> "Our dead processor family beats the pants off the new crap we're trying
to
> stuff down your throats."
Apropos to HPQ ads, I saw one on Fox News (during the O'Reilly Factor, IIRC)
yesterday evening. T'was an ad for HP ProLiant servers. Whilst not an ad for
VMS or Alpha, it was nice to see a non-PC ad from the vendor in question.
Terry C. Shannon
> John Smith <a...@nonymous.com> wrote:
> >
> >IMHO, HP will show some 'non-published' numbers to those *existing*
> >customers who are likely candidates to need more Alpha horsepower.
> >
> >Since HP does *NOT* sell to *new* non-VMS customers any longer (a
paraphrase
> >of their words), why should they go to the effort of pointing out that
they
> >bought a superior (albeit, dead) technology that obviates the need for
> >Itanic. Mustn't forget that they've "burned their bridges behind them".
>
> Is that so, indeed? That could explain a great deal. Do you have
> a reference to those words?
All I can do is paraphrase, but Ms. Fiorina uttered a close facsimile to
those words when queried about what HP would do if the merger failed. The
statement was made (IIRC) last September or so.
Bill Todd
> Hmm. Doesn't match the numbers at the HP website, which showed
> a top-end IA-32 system ruling the roost on SpecINT. McK was tops
> on SpecFP, though.
Despite Rob's attempt to equivocate in his response, you're absolutely
right: Rob in no way qualified his statement to exclude IA32 platforms
(though I gave him the benefit of the doubt in that respect when I responded
that we'd have to wait for spec.org to publish the claims - and see them
appear before any others such as the 1.25 GHz Alpha's - before his statement
could be considered accurate).
>
> What is clear is that McKinley isn't the performance disaster that
> Merced was. McK's integer numbers are comparable to the
> current competition and the FP numbers look quite good indeed.
> McK has done a lot better than I, for one, expected it to do.
Agreed, and I said as much myself. I guess Fred was frothing too much at
the mouth to notice.
>
> Whether this is good enough to sustain the IPF architecture in the
> face of the competition is still an open question.
Exactly. Perhaps my similar attempt to inject a bit of reality was what set
Fred off.
- bill
>
> On 8 Jul 2002 13:30:01 -0600, you...@encompasserve.org (Rob Young)
> wrote:
>
> >
> > That's right. Time to eat crow all around. Perhaps there
> > may not be enough platters, but who cares, eh?
> >
> > According to the PPTs and HTMLs found at www.openvms.org one
> > can find (in the notes field) the Spec numbers embargoed until today.
> >
> > Following are base numbers. So maybe their is a tiny bit of
> > glory left for Power4 in SpecInt2000 peak?
> >
> > Itanium 2 Power4 at 1.3 GHz
> >
> >SpecInt2000 810 804
> >SpecFp 1356 1202
> >
> >
> > Rob
> >
>
> ----------
> Remove 'Z' to reply by email.
Kenneth H. Fairfield
Gee, Bill, getting a little testy there, eh? Didn't someone
once say, "If you don't like rotten tomatoes being thrown at you,
don't stand in the limelight", or something to that effect?
Perhaps it was "heat" and "kitchens", whatever... :-) :-)
I haven't done the statistics, but I wouldn't be the least bit
surprised if you alone accounted for over 25% of the post to c.o.v
since June a year ago (and probably before that). That, if nothing
else, makes you a large target. Seems to me Fred was being ever so
slightly sarcastic, and you couldn't handle it? Had to resort to
name-calling with 4 letter words? How professional. The last thing
we need in this group is another self-styled Carl Lydick, may he
rest in peace...
MHO. -Ken
--
I don't speak for Intel, Intel doesn't speak for me...
Ken Fairfield
F20 Automation VMS System Support
kenneth.h.fairfield#intel.com
John Smith
> John Smith <a...@nonymous.com> wrote:
> >
> >IMHO, HP will show some 'non-published' numbers to those *existing*
> >customers who are likely candidates to need more Alpha horsepower.
> >
> >Since HP does *NOT* sell to *new* non-VMS customers any longer (a
paraphrase
> >of their words), why should they go to the effort of pointing out that
they
> >bought a superior (albeit, dead) technology that obviates the need for
> >Itanic. Mustn't forget that they've "burned their bridges behind them".
>
> Is that so, indeed? That could explain a great deal. Do you have
> a reference to those words?
See http://www.hp.com/hpinfo/newsroom/press/07may02b.htm
(full text below)
in the section 'RISC-based Servers',
"Decision: HP will continue with the previously published roadmaps for both
PA-RISC and AlphaServer systems. HP will continue development of the
PA-8800 and PA-8900 processors, as well as the EV7 and EV79 Alpha
processors. The roles of these two families will be quite different. The
PA-RISC servers will be targeted at the PA-RISC installed base and
***all new business opportunities***. AlphaServer systems ***will be focused
on the Alpha installed base***." (emphasis added)
Seems pretty clear. If you are new to HP, you will be sold HP-UX on PA-RISC,
or now on Itanic.
Since new-to-HP customers will not be sold VMS unless they put a .44 Magnum
to Carly's head and say "Go ahead, make my day.", where will HP find all the
OpenVMS customers to buy all those shiny new Itanics? A good percentage of
the existing OpenVMS customer base will have left for flavors of *ix long
before any viable Itanic-family system is available for VMS production use.
A rational person might think that it would be a good thing to attempt to
market VMS to new customers, especially those you are trying to steal from
Sun, IBM, SGI, Windows, etc...as that would lead to an immediate sale of
Alphaservers and later Itanics. But I guess it probably boils down to a
simple reality - Alpha is dead, and who at a corporation is going to put
his/her head on a chopping block by even suggesting, "Let's buy a bunch of
Alpha's today so we can spend more money in a couple years to buy slower
Itanics, and spend a bunch more money porting our apps and data!!"?
So if you were an ISV, and HP isn't selling OpenVMS to new customers, where
do you think your efforts should be spent? Developing new products or lots
of enhancements for the OpenVMS market? And what do you think that will do
the the rate of change in the VMS customer base?
-----------------------------------------
hp white paper
HP Product Roadmaps
One of our most important objectives in planning the merger of HP and Compaq
was to develop clear product roadmaps that take advantage of the significant
and complementary strengths of both companies. Customers need to know which
offerings we will have in which markets. And we wanted to be able to tell
them on Day One of the new HP.
We began work on the roadmaps shortly after the merger was announced. We had
to make some difficult decisions about which products to keep and which to
retire, but the result is the best portfolio of products and solutions in
the industry. At the same time, we recognize that customers around the world
have made significant investments in HP and Compaq technology. We intend to
protect those investments with detailed transition and migration plans.
The purpose of this white paper is to provide a high-level view of the
merged company's product roadmaps. Additional detail will be available from
each of the business groups. The impact of roadmap decisions for employees
and particular sites is still uncertain and will be subject to full
consultation with works councils and other employee representatives, where
required by local law.
SERVERS
HP will become the master brand for all server products, but we will keep
product families representing both companies.
IA-32 Servers: Before the merger, HP and Compaq both had IA-32 server
offerings: the Compaq ProLiantT and the HP Netserver (and more recently
under the new name of HP Server).
Decision: Moving forward, the ProLiant servers will be HP's IA-32 server
offering. They will be named HP ProLiant servers. In the transition to the
ProLiant name, we will also transition to the server-attached storage (Smart
Array), rack, rack option and power infrastructure, and systems management
families used today with ProLiant platforms. The ProLiant Essentials
software offerings will also move forward. In addition, the low-end HP
Servers tc2210 and tc2100 will continue to be offered but will not be
re-branded as HP ProLiant servers. For the growing market for blade servers,
we will continue to offer the ProLiant blade server architecture for the
data center. We also will offer HP's blade server optimized for the
telecommunications market.
As customers transition to ProLiant servers, Netserver customers can
continue to use their Toptools console, migrate to Insight Manager 7 or use
a combination. More detailed benefits for customers and how-to information
on transitioning to the Insight Management Suite will be made available on
the HP Web site.
Rationale: Compaq products hold the No. 1 market position in
industry-standard servers worldwide, according to the latest IDC market
data, and have done so since 1992. The combination of broad customer
acceptance, outstanding performance, ease of management and favorable total
cost of ownership made the ProLiant name the clear choice as HP's IA-32
server.
Itanium Servers: HP and Compaq are both selling Intel® ItaniumT Processor
Family servers today, primarily to meet the needs of early adopter customers
and developers. Our commitment to the Itanium Processor Family remains very
strong, and we continue to see Itanium as the future 64-bit microprocessor.
Decision: The next-generation Itanium Processor Family servers
(McKinley-based) will be the previously published HP Server roadmap,
augmented by features from the ProLiant IA-64 roadmap. By the release of the
third generation Itanium processor (Madison), HP will offer Itanium-based
servers from the low end to the high end of our product line, including HP
NonStopT Itanium servers.
Our Industry Standard Server and Business Critical System business units
will jointly deliver the Itanium-based server family roadmap supporting
multiple operating environments in all relevant markets. In addition, HP
will, over time, enhance its original plans by including the ProLiant
management capabilities into Itanium servers.
Rationale: This decision was based on the expected customer adoption of the
Itanium servers. The customers who will initially purchase Itanium servers
are the ones who require 64-bit computing. Today, these customers use
RISC-based servers. The HP roadmap gives HP a broad range of Itanium-based
servers supporting multiple operating systems. It also gives HP PA-RISC
customers outstanding investment protection with in-the-box upgrades for
4-way servers and above.
RISC-based Servers: The combination of the HP PA-RISC and the Compaq
AlphaServerT families gives HP a strong position in the RISC and UNIX®
marketplace. Moving forward, our focus on the Itanium architecture will be
balanced with the need to meet our customers' requirements today for high
performance, scalability and availability.
Decision: HP will continue with the previously published roadmaps for both
PA-RISC and AlphaServer systems. HP will continue development of the PA-8800
and PA-8900 processors, as well as the EV7 and EV79 Alpha processors. The
roles of these two families will be quite different. The PA-RISC servers
will be targeted at the PA-RISC installed base and all new business
opportunities. AlphaServer systems will be focused on the Alpha installed
base.
Rationale: We want to reinforce our commitment to our customers by following
the roadmaps we had already established. We're leading with PA-RISC for new
business opportunities for two reasons: First, the PA-RISC systems will, in
most cases, be upgradeable in the box to future Itanium microprocessors.
Second, HP-UX is the long-term UNIX for HP.
Fault Tolerant Servers: One of the exciting additions to the HP offering is
the fault-tolerant NonStop server family from Compaq, which will now be
known as the HP NonStop Server. Since HP did not have a similar offering,
the roadmaps decisions are very simple.
Decision: There are no changes to the previous NonStop server roadmap. This
includes the two planned MIPS processor upgrades and the transition to
Itanium.
Rationale: Customer availability requirements continue to increase. Having a
fault-tolerant offering will help HP continue to be the high-availability
leader. As a result, continuing with the NonStop server roadmap positions HP
to meet the needs of our customers.
UNIX: HP and Compaq both offered UNIX operating systems: HP-UX and Compaq
Tru64T UNIX.
Decision: HP-UX will be the long-term UNIX for the new HP. Tru64 UNIX has
some very advanced features - including clustering and file systems - and
some of those will be integrated into HP-UX over time.
Rationale: HP-UX has a much larger market share and installed base of
customers. It also has much broader ISV support than Tru64 UNIX.
Linux: HP and Compaq both supported the major Linux distributions across
platforms to provide customers with the solutions they demand.
Decision: HP will continue to provide customers with Linux solutions on the
major distributions and will adopt new distributions based on specific
regional customer needs and solution applications.
Rationale: Customers operate in heterogeneous environments and HP needs to
provide Linux solutions across platforms and regions on the Linux
distribution of choice. Linux, with its distinct features and benefits, is
the right choice in particular application environments - especially web and
infrastructure services, as well as e-commerce application development,
digital content creation and high performance computing.
HP is driving Linux adoption in enterprise and ISP software development
environments by creating the tools and technologies that will facilitate
development on Linux for easy deployment on Linux or HP-UX systems.
HP is providing manageability, high availability, rapid deployment, and
security solutions that customers require in their IT environments running
Linux.
HP continues to offer the highest level of services for Linux including
migrations services, porting services, consulting, mission critical support,
on-site consulting and support, education and training.
HP continues its strong support of the Open Source community.
Linux migration tools for Tru64 customers: HP provides support to customers
as they migrate from Tru64 to HP-UX.
In addition to providing a migration path to HP-UX, HP continues to work
with the Linux community and partners to make Linux an acceptable option for
Tru64 UNIX customers when it becomes enterprise ready.
HP continues to enhance the Affinity Program that focuses on support for
heterogeneous environments where Tru64 Unix and Linux systems interoperate
and are managed seamlessly. The Affinity Toolkit provides the ability to
develop applications on Tru64 Unix and move them to Linux and vice versa.
Application mobility across platforms is provided in the Affinity program.
One can develop on Tru64 UNIX and move to Linux for low cost deployment. The
Affinity program is all about running the same tools and applications on
both Linux and Tru 64UNIX.
HP's goal is to enable end-user customers, developers and vendors to
integrate Linux and Tru64 UNIX and the power of HP into their development
and deployment environments.
OpenVMS: HP also will deliver on the previously announced Compaq OpenVMST
roadmap, including the port to Itanium.
STORAGE
Both Compaq and HP have very robust storage portfolios, so we are in the
enviable position of being able to develop a roadmap based on the best of
the best.
Key Overall Decisions: While we are making many individual product decisions
encompassing products and strategies from both organizations, we will adopt
the Compaq StorageWorksT name (re-named HP StorageWorks) for storage and
storage solutions, HP OpenView as the name for storage software, and ENSA
(Enterprise Network Storage Architecture) as the name for our architecture
going forward.
Online Storage: HP remains committed to offering multiple choices for disk
array and storage area network products. We will consolidate and rationalize
our array portfolio and focus on creating NAS/SAN convergence.
Key Decisions: At the high end, we will continue to offer both HP-XP and
Compaq StorageWorks Enterprise Virtual Array (EVA). HP-XP enables storage
consolidation via a single, monolithic scalable and highly available storage
system. StorageWorks EVA will provide modular scaling and high-end
functionality by exploiting the storage network and virtualization
capabilities for maximum storage efficiency, high availability and lower
TCO. In the mid-range, we will offer the StorageWorks EVA architecture, but
we will continue to offer HP VA solutions for HP-UX centric and
heterogeneous environments and StorageWorks EMA modular arrays for ProLiant,
AlphaServer systems running Tru64 UNIX and OpenVMS, and heterogeneous
environments - until our EVA architecture-based products fulfill our
customer requirements, expected to be by the middle of 2003.
In the area of storage networking, we will consolidate both Compaq and HP's
storage networking offerings into one product line with common firmware and
integration. In terms of NAS, we will offer the StorageWorks appliance for
the entry level, the HP appliance for the midrange and enterprise level and
continue to work toward NAS/SAN convergence.
Nearline: By combining and consolidating both companies' offerings, the new
HP will continue to provide customers a choice. We will continue to offer
the tape drive technologies that our customers deploy, including DLT, SDLT,
AIT and Ultrium.
Key Decisions: We evaluated each of the products on features, price and
market share. Where there was overlap, we chose the one that would best meet
our customers' needs. In the high-end tape drive segment, we will offer both
Ultrium and SDLT.
Storage Management Software: Storage management software is an essential
component in simplifying storage by providing a single window that enables
customers to visualize and manage their entire heterogeneous storage
environment.
Key Decisions: Our enterprise storage management strategy is to evolve the
best storage management intellectual property from Compaq and integrate it
with the HP OpenView Storage Area Manager suite. Our existing HP OpenView
Omniback solutions will evolve from delivering backup and recovery to
delivering on the promise of life cycle data management. To maximize our
business continuity offerings, we will continue to invest in and integrate
our host- and array-based HA/replication software solutions.
Virtualization: The combination of the two companies results in the broadest
virtualization capabilities in the industry. A key focus area for the new
storage organization is to consolidate and merge these technologies into
even more useful solutions that provide virtualization capabilities in
multiple areas.
Key Decisions: We will offer a multi-level virtualization strategy and
phased implementation plans, including the integration of HP and Compaq
virtualization IP into a common, multi-tier virtualization strategy. We will
continue to ship SANlink and VersaStor technology, eventually merging
SANlink IP with VersaStor.
SOFTWARE
HP will continue to invest in OpenView management solutions, Utility Data
Center (UDC), Opencall telco solutions and J2EE and Microsoft .NET
middleware stacks.
OpenView. Key Decisions: HP will adopt the OpenView name for all appropriate
management software and will integrate TeMIP into the OpenView family. The
OpenView product line will focus on integrated management solutions, on
extended management reach for both network and IP devices and web services
management.
And, HP will continue to take a leadership role in defining Web services
management interoperability standards and products - a key element for
successfully managing across companies, technologies and platforms.
Utility Data Center. Key Decisions: HP will continue to invest in the
Utility Data Center software by leveraging the Compaq Insight Manager and
Adaptive Infrastructure offerings as well as Toptools to offer the most
scaleable and comprehensive management solutions in the industry.
Telco Solutions. Key Decisions: For telco software, the new HP will
consolidate both Compaq and HP's telecom software into the Opencall product
family that will be used to develop, integrate and deliver voice, data and
converged services.
Middleware. Key Decisions: The new HP will be equally strong on UNIX,
Windows® and Linux-based servers, requiring middleware solutions to support
all platforms. HP will leverage key relationships that enhance the
middleware stacks around both J2EE and .NET to deliver a comprehensive
ecosystem for HP and partners' application infrastructure components. In
addition to building out value chains and ecosystems for the .NET and J2EE
stacks separately, we will help customers manage the heterogeneous stack
environments by providing key interoperability though our services and
solutions organizations.
Developers. Key Decisions: HP is deepening its commitment to developers and
is the right partner to work with for J2EE and .NET tools, for management,
UDC and IPF development. HP is taking a leadership role to integrate
development and management through standards initiatives, developer tools,
community/content and developer support products to simplify for developers
this transition to a new way of thinking and working.
PERSONAL SYSTEMS
The new HP will provide the leading-edge personal systems technology that
customers have come to expect from both HP and Compaq. We will leverage the
complementary brand and product strengths of the two companies to deliver an
even better portfolio of end-to-end products, global solutions and
integrated services to meet the needs of our customers. Our branding
strategy builds on the strong equity in the HP brand across a broad range of
technology and the strong equity in the Compaq brand for PCs worldwide.
Business PCs and Notebooks. Decision: Business desktop PCs and notebooks
will migrate to the Compaq platform over the next 9-12 months. Both will
carry the Compaq name. This will enable HP to leverage Compaq's strong
market share and brand recognition in the commercial PC market. The HP
Vectra products will be phased out in line with current published roadmaps,
but we will continue to offer HP's highly successful e-pc line under the HP
brand. The HP Omnibook products will continue to be offered through 2002.
Consumer PCs and Notebooks. Decision: We will continue to offer both the
Compaq PresarioT and HP Pavilion lines of consumer desktop PCs and notebooks
through all existing channels in regions where both brands are strong. In
some countries, only one brand will be offered, depending on that country's
specific requirements. Our goal is to minimize confusion and maximize choice
for our customers.
The two brands will compete, and we will market the unique value proposition
for each. Today, for example, Compaq has compelling offerings for
home/wireless networking and HP has strength in digital imaging solutions.
Maintaining both brands will enable HP to leverage existing brand awareness
and preferences and give customers the opportunity to continue to buy the
brand and products that best meet their needs. The decision to maintain two
consumer brands of desktop PCs and notebooks is driven in part by feedback
from our retail partners.
Workstations. Decision: We will incorporate the strength of Compaq's Windows
NT workstations to form the industry's broadest, most comprehensive product
line. HP will continue to drive 64-bit platform leadership for the most
demanding applications with today's PA-RISC and upcoming workstations based
on the Intel Itanium Processor Family. HP workstations will provide great
value across the industry-leading 32- and 64-bit operations system
environments: Windows, Linux and HP-UX.
Smart Handhelds. Decision: The Compaq iPAQT Pocket PC, re-named the HP iPAQ
Pocket PC, will be our smart handheld platform. The best of the current HP
Jornada technology will be engineered into the platform. Jornada products
will be phased out of the market in 2002. HP will continue to innovate in
wireless, mobility and voice technology. HP also will offer the iPAQ
Blackberry device for end-to-end wireless e-mail solutions, under the HP
brand.
Home and Wireless Networking. Decision: These solutions will be based on
current Compaq products and re-branded HP. Our corporate networking
solutions will range from wireless mobility solutions and industry-standard
wireless LAN to Bluetooth solutions. For home networking, we will offer
several choices, from Ethernet to wireless to phone line.
Thin Clients: Decision: HP will continue the Compaq line of thin clients,
which will be re-branded HP. This line offers customers lower cost of
ownership, improved end-user productivity and unparalleled security.
BUSINESS NETWORKING
Decision: HP will continue to deliver the most cost effective networking
solutions with the HP Procurve product line of industry-standard Ethernet
LAN products.
Rationale: The HP Procurve networking products deliver industry leading
value as they meet business customers needs in building interoperable
networks that are highly available, secure, easy to manage and affordable. A
highly performing network is no longer optional and is a core requirement of
an always-on business infrastructure connecting servers, storage and clients
in an increasingly connected world.
IMAGING AND PRINTING
HP develops and markets products in a broad range of printing and imaging
categories. We lead the market in inkjet printers, all-in-one devices, laser
printers, wide-format plotters, scanners, print servers and ink.
For consumers, we offer products from capture devices like digital cameras
and scanners to sharing products like photo printers. The Imaging and
Printing Group provides the solutions that get people from capture to share
in the easiest ways with the highest quality results. For businesses, we
make the products that make a difference - networkable printers, large
format printers and digital presses. We are helping businesses work faster
and more efficiently with high-quality results.
HP's imaging and printing business is at a pivotal point in its history. We
are defining and building the next chapter of imaging and printing for
business customers. During chapter 1, we heard from our customers that HP
makes great printers. During the next chapter, we will continue to provide
high-quality, highly reliable products, but we will also provide solutions
and services that enhance business processes and streamline workflows.
For example, as part of this next chapter of imaging and printing, we will
serve the needs of an increasingly mobile workforce. Mobile professionals
need fast, easy access to information while away from their desks. Through
intelligent appliances, enhanced infrastructure, wireless and "smart space"
solutions, HP and its partners can bring information access to mobile
professionals.
We are also pushing the boundaries of our business beyond the general office
as we introduce powerful digital publishing solutions that link to customer
relationship management and other enterprise database systems. In addition,
we are introducing new classes of digital multi-function devices and new
services and pricing/leasing options to meet customers' business challenges
as the worlds of copiers, printers and fax machines collide.
All imaging and printing categories and product lines remain as is, with the
following exceptions:
Personal inkjet printers, all-in-ones and scanners. The HP product lineup
continues. We will phase out the Compaq-branded products.
Digital projectors: We will combine the HP and Compaq product line. Some
specific products will be phased out, but final decisions have not been
made. All digital projectors will be branded HP - a transition that will
occur during the next 12 months.
The organizational impact of all of the above roadmap decisions for
employees and sites in particular countries is not yet known or decided. Any
such impact will be subject to local legal requirements, including in
particular required consultation with works councils and other employee
representatives.
John Smith
"Bill Todd" <bill...@metrocast.net> wrote in message
news:45HW8.646871$%y.398...@bin4.nnrp.aus1.giganews.com...
Bill,
I just don't know what to say to you. This type of vulgar outburst is
certainly not appreciated by anyone.
If you want to make a biting comment about somebody, take a cue from Winston
Churchill and at least learn to do it with some élan and wit.
I suggest that you take a deep breath, calm your self down, and issue Fred
an apology.
John
Main, Kerry
>>> Since IA64 is currently still poised to be mostly HP's chip, much
like Alpha was Digital's stating that most IA64 customers would be
running HP's compiler might not be wrong.<<<
Well, my apologies if this has been already posted, but here is an
extract from the Intel press release:
http://www.intel.com/pressroom/archive/releases/20020708comp.htm
"The world's leading enterprise software makers are building commercial
applications for Itanium 2-based systems, including BEA Weblogic*, i2
Supply Chain* and Factory Planner*, IBM DB2* and Websphere*, Microsoft
SQL Server 2000*, Oracle9i* Database and Oracle9i Application Server ,
Reuters financial services platforms, SAP R/3* and APO with LiveCache*,
and SAS v9.0*.
The Itanium processor family is supported by more operating systems than
any other high-end enterprise platform. Operating systems that currently
work with the Itanium 2 processor include Microsoft's Windows* Advanced
Server, Limited Edition, and Windows XP 64-Bit Edition;
Hewlett-Packard's HP-UX*; and Linux from Caldera, MSC.Software, Red Hat,
SuSE and TurboLinux. In addition, Microsoft plans to introduce versions
of Windows.NET* Datacenter and Enterprise Server for the Itanium 2
processor, and HP is porting its OpenVMS* and Non Stop Kernel* operating
systems to the Itanium processor family for future introduction."
So, while it still has a ways to go to prove itself, as others have
stated here - the IPF-2 is off to a much better start than its
predecessor.
Regards
Kerry Main
Senior Consultant
Hewlett-Packard Canada
Consulting & Integration Services
Voice: 613-592-4660
Fax : 613-591-4477
Email: Kerry...@hp.com
-----Original Message-----
From: JF Mezei [mailto:jfmezei...@videotron.ca]
Sent: July 9, 2002 3:40 PM
To: Info...@Mvb.Saic.Com
Subject: Re: McKinley tops SpecFP AND SpecInt charts
Nick Maclaren wrote:
> Then I suggest that you quote performance figures based on them, and
> do not flame me when I point out that the figures quoted by HP on
> Monday are not what most McKinley customers will get.
Since IA64 is currently still poised to be mostly HP's chip, much like
John Smith
>
>
> Apropos to HPQ ads, I saw one on Fox News (during the O'Reilly Factor,
IIRC)
> yesterday evening. T'was an ad for HP ProLiant servers. Whilst not an ad
for
> VMS or Alpha, it was nice to see a non-PC ad from the vendor in question.
Xeon-based machines are PC enough in my books.
JF Mezei
> It was in a bunch of stuff that came out in early May...said something to
> the effect of 'OpenVMS will be continued to be sold to existing customers
> and *selected* new accounts'. I will attempt to find the reference for you.
There was also a clear and unequivocal statement to the effect that new
customers would be steared to HP-UX.
JF Mezei
> Apropos to HPQ ads, I saw one on Fox News (during the O'Reilly Factor, IIRC)
> yesterday evening. T'was an ad for HP ProLiant servers. Whilst not an ad for
> VMS or Alpha, it was nice to see a non-PC ad from the vendor in question.
Saw that ad today on CNN I think. I noticed the HP branding to Proliant. But
to me, Proliant = PC. Wintel is Wintel is Wintel. Whether in a 19" rack with
the monitor in a drawer, or on a destop, it is still all wintel to me.
Terry C. Shannon
I see your point, my friend, but at least they were pitching quadprocessor
boxes, not Presarios.
Nick Maclaren
John Smith <a...@nonymous.com> wrote:
>
>See http://www.hp.com/hpinfo/newsroom/press/07may02b.htm
>(full text below)
>
>in the section 'RISC-based Servers',
>
>"Decision: HP will continue with the previously published roadmaps for both
>PA-RISC and AlphaServer systems. HP will continue development of the
>PA-8800 and PA-8900 processors, as well as the EV7 and EV79 Alpha
>processors. The roles of these two families will be quite different. The
>PA-RISC servers will be targeted at the PA-RISC installed base and
>***all new business opportunities***. AlphaServer systems ***will be focused
>on the Alpha installed base***." (emphasis added)
>
>Seems pretty clear. If you are new to HP, you will be sold HP-UX on PA-RISC,
>or now on Itanic.
Thanks very much. I am not sure that it answers my question, but
I can't go into more detail because of confidentiality. It does
clarify some of the odd behaviour I have observed, though.
JF Mezei
> Seems pretty clear. If you are new to HP, you will be sold HP-UX on PA-RISC,
> or now on Itanic.
And Scott Stallards now erased message was also very clear: We'll help you
migrate from VMS to HP-UX (which replaced the "we expect you to migrate to HP-UX").
> OpenVMS customers to buy all those shiny new Itanics? A good percentage of
> the existing OpenVMS customer base will have left for flavors of *ix long
> before any viable Itanic-family system is available for VMS production use.
I am not so sure about that. What remains of the VMS installed base are the
largest customers with a big investment in Alpha. My guess is that they will
stay on Alpha well beyond the introduction of VMS on IA64. Wouldn't be
surprised if VMS-ALPHA actually outlived VMS-IA64.
On the other hand, once VMS run on Intel, *IF* Intel subsidizes advertising
the same way it does for wintel crap (put the awful Intel logo and tune and we
pay 75% of your ads), then it will be most interesting to see how HP decided
to market its non-core products such as VMS.
Right now, if HP markets a wintel box, I'd say that the vast majority of the
costs are bourne by Intel and Microsoft. After all, they are the ones who make
a profit from the sale of a wintel box, not HP.
Marketing VMS right now means you go against 2 partners: microsoft and intel.
Once VMS is on intel, it leaves only microsoft as the one you make made
because you advertise a competing product.
Bill Todd
You are free to suggest what you please, but don't hold your breath waiting
for one.
I respond to people as they deserve, without sugar-coating the material.
What I said was *exactly* what I meant to say, and while I regret the fact
that it appears to have offended your sensibilities I'm afraid that's a
price I'm willing to pay for being unambiguous in my statements.
Of course, should the material to which I respond elevate itself to
something worthy of more respect, then I'll happily accord it some.
- bill
JF Mezei
> http://www.intel.com/pressroom/archive/releases/20020708comp.htm
> "The world's leading enterprise software makers are building commercial
> applications for Itanium 2-based systems, including BEA Weblogic*,
When one has to list individual companies or even products with a version
number, it means that the momentum isn't exactly there. It is similar to when
Sue jumps up and down, waiving her hands with joy whenever she finds some ISV
that is making a VMS product :-)
> The Itanium processor family is supported by more operating systems than
> any other high-end enterprise platform.
Humm, I counted HP-UX, Windows (special edition), and various Linux flavours.
That makes it 3.
Microsoft hasn't yet made a real/full version of Windows available.
Alpha had Windows, VMS, Tru-64 and Linux. That makes it 4. Alpha had more OSs
than IA64 has now.
Yeah, IA64 will come up to 5 when VMS and NSK arrive and alpha is down to 3.
Still not a radical difference, certaintly not worthy of bragging.
> So, while it still has a ways to go to prove itself, as others have
> stated here - the IPF-2 is off to a much better start than its
> predecessor.
How many operating systems have run on the 8086 ? Seems that its predecessor
has had much wider selection of software and operating systems than IA64 has.
Bill Todd
"JF Mezei" <jfmezei...@videotron.ca> wrote in message
news:3D2B1708...@videotron.ca...
...
> McKinley is brand spanking new, and currently being compared agaist
> older existing chips. When those chips get their upgrades, how will
McKinley
> fare ?
In some ways this could be to McKinley's advantage, since all of its
potential tweaks lie ahead of it (well, perhaps not all: it's so late that
the first round of tweaking may already have occurred...). OTOH, the
projected Madison and Montecito release schedule may be so tight that tweaks
don't get applied to McKinley or Madison but instead the effort is just put
into the next generation (i.e., Madison is born with the tweaks McKinley
would otherwise have received, and Montecito is born with the tweaks Madison
would otherwise have received).
>
> Is everyone just planning speed bumps for the next few years, or is a
> competitor to IA64 planning a more significant improvement to their chip
which
> would widen the gap ?
That's where McKinley/Madison/Montecito don't look so good.
The EV68c speed-bump should put Alpha on a par with McKinley in a month or
so (in fact, since McKinley systems don't yet appear to be generally
available, the two releases may be just about simultaneous), and then before
the end of the year the EV7 release should make McKinley start to look
second-rate. Since Alpha's adoption of 130 nm process technology is planned
to be, shall we say, leisurely, Madison will close the gap again next year,
leaving EV79 about neck-and-neck with Montecito (at least in SPEC figures:
Alpha will still have significant memory bandwidth and MP advantages) when
both appear in 2004 (when EV8 was scheduled, which would have bumped the
Alpha advantage up to at least 2:1 in server use).
Hammer, if it comes in anywhere near expectations, should make McKinley look
pretty lame. At best Madison will close the performance gap (though only in
SPEC results since, as with Alpha, Hammer has MP advantages that Itanic
won't get until 2005), but only briefly (Hammer is scheduled for its shrink
to 90 nm late next year, and also may get a dual-core chip in the process -
an event of major significance if it occurs).
POWER4 is scheduled for a speed-bump in October to 1.5 - 1.6 GHz (and, as
with the new Alpha, if SPEC accepts its performance numbers before
McKinley's the latter won't be at the top of the charts when it appears
there); it reportedly gets shrunk to 130 nm next year, which should thus
keep each of its dual cores somewhat ahead of Madison as the October
speed-bump will bump each of its dual cores ahead of McKinley. POWER5 is
scheduled to arrive in 2004 with both SMT and on-chip support for several
ancillary tasks (TCP/IP and MPI communication enhancements and
virtual-memory management among them; should encryption also be included it
would likely significantly diminish Itanic's bragging rights on SSL
performance); however, as it's scheduled to debut in 130 nm, each of its
dual cores may not have too much of an advantage over Montecito in 90 nm
(unless its SMT implementation really does double the per-core performance
as IBM claims it will: the number of execution units per core isn't
increasing, but they claim to be using them 'differently'...).
As emphasized above, POWERx's dual-core configuration is its real advantage
(at least in any multi-threaded environment, such as typical server use):
while each single POWER core should be able to run even with or somewhat
ahead of its Itanic competition in the SPEC races, the fact that there are
two of them on each chip (together using about the same power as a single
Itanic) gives each POWERx chip about twice the (multi-thread) performance of
an Itanic (same goes for Hammer if/when it moves to dual cores).
USIV is scheduled to appear in 130 nm about the same time Madison is - but
with dual cores on the chip. While USIII is already at 150 nm (so the
shrink won't help is as much as shrinking McKinley will help Madison), in
server use the two cores together should about equal Madison's performance.
PA-RISC gets both a shrink and dual cores next year, which should put it
noticeably ahead of Madison in server use.
And of course IA32 will keep chugging along its performance curve as well:
it's already a bit faster than McKinley (except in SPECfp) and should have
no difficulty remaining so.
All the above ignores pricing issues (which work to Itanic's advantage
against the usual RISC suspects, with the possible exception of SPARC, but
work against Itanic in comparisons with IA32 and Hammer). It also assumes
that McKinley really does perform as well for the rest of the industry as
HP's benchmarks say it will for HP; if not, that will affect adoption.
- bill
JF Mezei
> All the above ignores pricing issues (which work to Itanic's advantage
> against the usual RISC suspects, with the possible exception of SPARC, but
> work against Itanic in comparisons with IA32 and Hammer).
Does the $4000 Itanic outperform its peers ?
If Intel publicly says the 3meg chip sells for $4000, what would be the
ballpark prince that HP would actually pay for it ? (considering all the deals
it and Compaq did with Intel)
If volumes do not pick up for that enterprise-only chip, isn't it fair to
think that the prices for the chip aren't going to drop ?
At that cost, is IA64 really that competitive ? Seems to me that there is no
way it could compete against the 8086.
John Smith
> >The roles of these two families will be quite different. The
> >PA-RISC servers will be targeted at the PA-RISC installed base and
> >***all new business opportunities***. AlphaServer systems ***will be
focused
> >on the Alpha installed base***." (emphasis added)
> >
> >Seems pretty clear. If you are new to HP, you will be sold HP-UX on
PA-RISC,
> >or now on Itanic.
>
> Thanks very much. I am not sure that it answers my question, but
> I can't go into more detail because of confidentiality. It does
> clarify some of the odd behaviour I have observed, though.
I'll bet that it isn't so odd in light of the direct quote from the HP
document reproduced above. It's probably quite consistent behaviour.
Burn your bridge behind you and march according to orders, or lose your
job. - Anon.
John Smith
> John Smith wrote:
> > Seems pretty clear. If you are new to HP, you will be sold HP-UX on
PA-RISC,
> > or now on Itanic.
>
> And Scott Stallards now erased message was also very clear: We'll help you
> migrate from VMS to HP-UX (which replaced the "we expect you to migrate to
HP-UX").
Sure. HP listens and changes anything that sounds offensive. But let's be
fair....HP has been doing some positive things too.....let's see......there
was the let's spout some platitudes swing through Europe, the not found on
the HP web site and you only find out about it 3rd hand training in New
Hampshire for 20 people out of 411,000 systems in production deal, and the
summer USA 8 city while everyone important at customer's are on holidays
tour.
> > OpenVMS customers to buy all those shiny new Itanics? A good percentage
of
> > the existing OpenVMS customer base will have left for flavors of *ix
long
> > before any viable Itanic-family system is available for VMS production
use.
>
> I am not so sure about that. What remains of the VMS installed base are
the
> largest customers with a big investment in Alpha. My guess is that they
will
> stay on Alpha well beyond the introduction of VMS on IA64. Wouldn't be
> surprised if VMS-ALPHA actually outlived VMS-IA64.
Sure...and I personally know of several constuction companies that still use
1931 Ford trucks for their entire fleet. Don't kid yourself...lots of
decisions at companies are made on the basis of "XYZ Corp. really (Germanic
expression)'ed us over by killing our system growth startegy. No new
development on their hardware or software from now on. As it is feasible
let's move our applications over to IBM gear."
> On the other hand, once VMS run on Intel, *IF* Intel subsidizes
advertising
> the same way it does for wintel crap (put the awful Intel logo and tune
and we
> pay 75% of your ads), then it will be most interesting to see how HP
decided
> to market its non-core products such as VMS.
When Itanic is just as low-volume a cpu as Alpha was, Intel won't be
subsidizing any of it...in fact they may just charge HP more mony per cpu to
amortize the R&D costs faster...After all, what could HP do? - - Resurrect
Alpha if they didn't like the price increase? ha.
> Right now, if HP markets a wintel box, I'd say that the vast majority of
the
> costs are bourne by Intel and Microsoft. After all, they are the ones who
make
> a profit from the sale of a wintel box, not HP.
>
> Marketing VMS right now means you go against 2 partners: microsoft and
intel.
> Once VMS is on intel, it leaves only microsoft as the one you make made
> because you advertise a competing product.
If Itanic craps out, Intel and Microsoft will both be enemies of HP rather
than partners. Microsoft, because they are everybody's enemy (more so
towards Sun), and Intel becasue they bet the franchise on an HP pipedream.
John Smith
When they shoudda be pitching the fast ball - Alpha's.
Alan Greig
>In article <FeHW8.3647$UHe1...@news01.bloor.is.net.cable.rogers.com>,
>John Smith <a...@nonymous.com> wrote:
>>
>>IMHO, HP will show some 'non-published' numbers to those *existing*
>>customers who are likely candidates to need more Alpha horsepower.
>>
>>Since HP does *NOT* sell to *new* non-VMS customers any longer (a paraphrase
>>of their words), why should they go to the effort of pointing out that they
>>bought a superior (albeit, dead) technology that obviates the need for
>>Itanic. Mustn't forget that they've "burned their bridges behind them".
>
>Is that so, indeed? That could explain a great deal. Do you have
>a reference to those words?
Here it is:
Message 1 in thread
From: Alan Greig (a.g...@virgin.net)
Subject: We've burned our boats say Compaq and HP
Newsgroups: comp.os.vms, comp.sys.dec, comp.unix.tru64
View this article only
Date: 2001-10-11 03:38:14 PST
The Inquirer has a report of Carly and Curly's 'Houston love-in'
conference for staff. Here's a few selected quotes from
http://www.theinquirer.net/10100114.htm
Carly:
"There is no backup plan. We've burned the boats, we've landed in the
brave new world, and we are going to go forward. And I, for one, who
have developed a core competence in ignoring bad press can tell you
that, put all the headlines aside, put the short-term stock price
reaction aside, and as Michael said to me at the end of the first day,
you know what, we're just going to go prove them wrong, and that's
exactly right. And that to me is the most fun of all, setting your
sights high, having everyone in the world underestimate you, and then
blowing their socks off."
Wonder just when Carly first blew Curly's r^hsocks off :)
---
>
>Regards,
>Nick Maclaren,
>University of Cambridge Computing Service,
>New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
>Email: nm...@cam.ac.uk
>Tel.: +44 1223 334761 Fax: +44 1223 334679
--
Alan
Alan Greig
<jfmezei...@videotron.ca> wrote:
>On the other hand, once VMS run on Intel, *IF* Intel subsidizes advertising
>the same way it does for wintel crap (put the awful Intel logo and tune and we
>pay 75% of your ads), then it will be most interesting to see how HP decided
>to market its non-core products such as VMS.
It may be telling that the current Intel "Itanium-2" ads running in
the UK trade press list the "enterprise solutions" operating systems
being ported as:
Windows Advanced Server
Windows Datacenter Server
Windows Enterprise Server
Caldera
HP-UX
Miracle (what's that?)
Redhat
SuSE
TurboLinux
No mention of VMS (or NSK for that matter). Given that Intel want to
show as much support for the chip as possible it seems strange they
don't list either.
>Right now, if HP markets a wintel box, I'd say that the vast majority of the
>costs are bourne by Intel and Microsoft. After all, they are the ones who make
>a profit from the sale of a wintel box, not HP.
>
>Marketing VMS right now means you go against 2 partners: microsoft and intel.
>Once VMS is on intel, it leaves only microsoft as the one you make made
>because you advertise a competing product.
--
Alan
Alan Greig
wrote:
>of Windows.NET* Datacenter and Enterprise Server for the Itanium 2
>processor, and HP is porting its OpenVMS* and Non Stop Kernel* operating
>systems to the Itanium processor family for future introduction."
That's a good sign but I still wonder why VMS and NSK are not listed
in the UK trade press ads paralleling this press release. Of course
the ads would have been placed weeks ago so maybe someone took
positive action to correct the later press release.
>
>So, while it still has a ways to go to prove itself, as others have
>stated here - the IPF-2 is off to a much better start than its
>predecessor.
>
>Regards
>
>Kerry Main
>Senior Consultant
>Hewlett-Packard Canada
>Consulting & Integration Services
>Voice: 613-592-4660
>Fax : 613-591-4477
>Email: Kerry...@hp.com
>
>
>-----Original Message-----
>From: JF Mezei [mailto:jfmezei...@videotron.ca]
>Sent: July 9, 2002 3:40 PM
>To: Info...@Mvb.Saic.Com
>Subject: Re: McKinley tops SpecFP AND SpecInt charts
>
>
>Nick Maclaren wrote:
>> Then I suggest that you quote performance figures based on them, and
>> do not flame me when I point out that the figures quoted by HP on
>> Monday are not what most McKinley customers will get.
>
>Since IA64 is currently still poised to be mostly HP's chip, much like
>Alpha was Digital's stating that most IA64 customers would be running
>HP's compiler might not be wrong.
--
Alan
Terry C. Shannon
>
> "JF Mezei" <jfmezei...@videotron.ca> wrote in message
> news:3D2B6397...@videotron.ca...
> > John Smith wrote:
> > > Seems pretty clear. If you are new to HP, you will be sold HP-UX on
> PA-RISC,
> > > or now on Itanic.
> >
> > And Scott Stallards now erased message was also very clear: We'll help
you
> > migrate from VMS to HP-UX (which replaced the "we expect you to migrate
to
> HP-UX").
>
>
> Sure. HP listens and changes anything that sounds offensive. But let's be
> fair....HP has been doing some positive things too.....let's
see......there
> was the let's spout some platitudes swing through Europe, the not found on
> the HP web site and you only find out about it 3rd hand training in New
> Hampshire for 20 people out of 411,000 systems in production deal, and the
> summer USA 8 city while everyone important at customer's are on holidays
> tour.
Now that's a really great whine. Company puts together a training session
(pilot program) and people bitch.
Company puts together a roadshow and people bitch.
Go figure.
Bob Koehler
> Nick Maclaren wrote:
>> Then I suggest that you quote performance figures based on them,
>> and do not flame me when I point out that the figures quoted by
>> HP on Monday are not what most McKinley customers will get.
>
> Since IA64 is currently still poised to be mostly HP's chip, much like Alpha
> was Digital's stating that most IA64 customers would be running HP's compiler
> might not be wrong.
I can tell you from painfull experience, you do not want HP-heritage
compilers. If HP's compilers for VMS opn IA-64 are really of DEC
heritage we're all must better off.
And yes, I've told Mark Gorham who seemed to think it was usefull
input.
Bob Koehler
>
> Saw that ad today on CNN I think. I noticed the HP branding to Proliant. But
> to me, Proliant = PC. Wintel is Wintel is Wintel. Whether in a 19" rack with
> the monitor in a drawer, or on a destop, it is still all wintel to me.
Many others don't think so. We've got PC folks who find a clear
preference for Compaq's name on Wintel servers, and for not Compaq's
name (nor Gateway) on Wintel desktops.
I ask them to respect my expertise (no, rebooting VMS will not
fix the network problem), and I respect theirs.
Bill Gunshannon
JF Mezei <jfmezei...@videotron.ca> writes:
|>
|> Humm, I counted HP-UX, Windows (special edition), and various Linux flavours.
|> That makes it 3.
|>
|> Microsoft hasn't yet made a real/full version of Windows available.
|>
|> Alpha had Windows, VMS, Tru-64 and Linux. That makes it 4. Alpha had more OSs
|> than IA64 has now.
And FreeBSD, that makes it 5.
And if you include {Net|Open}BSD which are somewhat different from
FreeBSD, your up to 6.
I note there is currently no BSD/IA64 porting activity to be found.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Nick Maclaren
I have always found them quite usable. But that is not the point.
Fred Kleinsorge
your speculations, bad mouthing, and rabble rousing is a waste of time - and
so far you haven't become the moderator of the group. It is however fun to
watch you squirm as you turn out not to have a working crystal ball.
Bill Todd wrote in message
<45HW8.646871$%y.398...@bin4.nnrp.aus1.giganews.com>...
>
>"Fred Kleinsorge" <klein...@star.zko.dec.com> wrote in message
>news:SeCW8.25$8Y5.3...@news.cpqcorp.net...
>>
>> Bill Todd wrote in message ...
>>
>> > ...
>>
>> You want some cheese with your whine?
>>
>> Oh my, Itanium-2 doesn't suck. Let me see if I can throw in a bunch of
>> other unsupported speculation to show why I wasn't wrong, or maybe
>someone's
>> lying, or maybe the Intel reference platform won't be as fast as HP's
>> system, or anyway - it will still suck later. And if that isn't enough,
I
>> can always complain that the mythical EV8 would still have kicked it's
>ass.
>
>You're starting to sound like a confirmed shit-head, Fred. If you don't
>care to respond to specifics, just fuck off.
>
>- bill
>
>
>
>
Paul Winalski
<terrys...@attbi.com> wrote:
>Umm, when the ES80 and GS1280 come out, do you think they will be devoid of
>performance metrics? And what of the 1.25GHz ES45 and GS320 due out in a
>month or so?
I expect to see performance metrics releaed for future Alpha systems.
But I won't be surprised if there aren't any side-by-side comparisons
between Alpha and Itanium. I noticed that the performance graphs
released yesterday by HP showed comparisons to IA-32, IBM, SUN,
etc., but I only saw one Alpha systemon any of the graphs.
----------
Remove 'Z' to reply by email.
John Smith
"Terry C. Shannon" <terrys...@attbi.com> wrote in message
news:C9VW8.139285$Uu2.31416@sccrnsc03...
I'm merely damning them with faint praise.
They aren't serious about VMS. If they were, they'd be growing the market
rather than preaching to the converted.
Bet you'd feel a lot more comfortable financially if you had more "SK*'
newsletter customers. Most VMS customers would feel more secure in their VMS
investments if HP were serious about growing the VMS market.
John Reagan
> Did I hear this right ? The "real" DEC compilers have been ported to IA64 to
> allow you to compile VMS ?
>
> I am totally confused. One hears news of Compaq having donated all its
> compiler and compiler people to Intel and that from now On, compilers on Alpha
> would only get minimal maintenance and that VMS would rely on Intel compilers
> for IA64. Then we hear news that some of the Digital compiler people are still
> with Compaq (now HP). Now you tell me that some of the Digital compilers were
> ported to IA64 and that this is what you're using to port VMS initially.
>
> Is there some document that CLEARLY explains exeactly what the compiler story
> REALLY is ?
I think I've tried before. I'll try again.
1) Most of the GEM developers were sold to Intel. A few GEM developers
remain for ongoing support for existing Alpha customers and for future
Itanium support. Some C and C++ front-end folks were also sold to
Intel. Front-end folks (like me) for other compilers (Pascal, COBOL,
BASIC, etc.) all remained at Compaq/HP.
2) There is an Itanium target for GEM. It was started several years ago
with the original goal of having Visual Fortran on Itanium targets.
3) Given that Intel doesn't have a BLISS compiler :-), it made sense to
enhance GEM to support an OpenVMS Itanium target (the GEM developers did
this work before departing to Intel). With this GEM in place, we have
the ability to take the existing front-ends and have the "real"
compilers for OpenVMS Itanium. For various languages (BLISS, Pascal,
COBOL, Basic), we think this is adequate for the long-term. For C, in
the short-term (to aid porting of OpenVMS and to provide the ultimate in
source compatibility for the customers), we have a Compaq C front-end
hooked to the OpenVMS Itanium GEM. In the longer term, we are moving
towards using Intel (at least that is the last thing I heard) compilers
as those compilers are enhanced to provide sufficient source level
compatibility.
--
John Reagan
Compaq Pascal/{A|I}MACRO Project Leader
Hewlett-Packard Company
Terry C. Shannon
"Paul Winalski" <pr...@ZAnkh-Morpork.mv.com> wrote in message
news:3d2c4982....@proxy.news.easynews.com...
Good point. I sorta noticed that myself when I talked with the HPQ folks
last week. The response was evasive and inconclusive, but hey, HPQ is not
positioning IA64 as an Alpha competitor. When the new Alpha stuff comes out,
it's likely that there will be IA64 comparisons... but comparisons with a
system or systems from rival vendors.
Paul Winalski
release you quote doesn't mention the numbers from Intel Pentium 4.
Check out the SPEC_int_base2000 graph at this URL:
http://www.hp.com/products1/itanium/performance/architecture/speccpu.html
You'll see that an Intel Pentium 4 2.53 GHz/533 MHz system bus box
got 893 SPECint_base2000, vs. 810 for the Itanium 2 box.
On 9 Jul 2002 12:05:51 -0600, you...@encompasserve.org (Rob Young)
wrote:
>In article <3d2b0843....@proxy.news.easynews.com>, pr...@ZAnkh-Morpork.mv.com (Paul Winalski) writes:
>> Hmm. Doesn't match the numbers at the HP website, which showed
>> a top-end IA-32 system ruling the roost on SpecINT. McK was tops
>> on SpecFP, though.
>>
>
> An oversight on your part. All about sourcing and I get
> mine turned around too often also.
>
>http://www.hp.com/hpinfo/newsroom/press/08jul02b.htm
>
>Commercial compute core: Itanium 2-based systems from HP with the HP Chipset
>zx1 outperformed the best from IBM and Sun. HP achieved a SPECintbase_2000
>score of 810 and 807 on an HP Server rx2600 and HP Workstation zx6000,
>respectively.(5)
WILLIAM WEBB
Did it occur to anyone that, when small steps are
taken in a positive direction, complaining about
the size of the steps doesn't improve the chances
for additional movement in that direction?
WWWebb
Terry C. Shannon
> >
> > Company puts together a roadshow and people bitch.
> >
> > Go figure.
>
>
> I'm merely damning them with faint praise.
At the very least things are less stealthy in VMSland today than they were
three months ago.
>
> They aren't serious about VMS. If they were, they'd be growing the market
> rather than preaching to the converted.
I think it depends on who the "they" are. Certainly Mark Gorham and his
understudies are serious. As for the folks higher up in the food chain, I
can't help but wonder why NSK is viewed as a growth opportunity and VMS is
not. I can understand why HPQ would want to stress HP-UX, but methinks there
are prospects who have no interest in HP-UX. VMS might be the Better Answer
for them. In competitive situations when going against IBM and MVS, VMS
might be the Better Answer. Etc.
HPQ has yet to adequately articulate a rationale for its VMS strategy.
>
> Bet you'd feel a lot more comfortable financially if you had more "SK*'
> newsletter customers. Most VMS customers would feel more secure in their
VMS
> investments if HP were serious about growing the VMS market.
>
Can't argue that point, either.
Alan Greig
<terrys...@attbi.com> wrote:
>
>"John Smith" <a...@nonymous.com> wrote in message
>news:rUXW8.2244$wLk...@news01.bloor.is.net.cable.rogers.com...
>>
>> "Terry C. Shannon" <terrys...@attbi.com> wrote in message
><snip>
>> >
>> > Company puts together a roadshow and people bitch.
>> >
>> > Go figure.
>>
>>
>> I'm merely damning them with faint praise.
>
>At the very least things are less stealthy in VMSland today than they were
>three months ago.
I'm intentionally not saying much on this subject but I have had a
long chat with a senior HP European marketing manager, who called me
over at the bar at a conference recently. HP have really *felt* the
customer feedback from VMS sites regarding HP's plans for VMS.
And that;'s one thing I always wanted to achieve with what some regard
as pointless stirring.
I'm watching...
>>
>> They aren't serious about VMS. If they were, they'd be growing the market
>> rather than preaching to the converted.
>
>I think it depends on who the "they" are. Certainly Mark Gorham and his
>understudies are serious. As for the folks higher up in the food chain, I
>can't help but wonder why NSK is viewed as a growth opportunity and VMS is
>not. I can understand why HPQ would want to stress HP-UX, but methinks there
>are prospects who have no interest in HP-UX. VMS might be the Better Answer
>for them. In competitive situations when going against IBM and MVS, VMS
>might be the Better Answer. Etc.
>
>HPQ has yet to adequately articulate a rationale for its VMS strategy.
>
>>
>> Bet you'd feel a lot more comfortable financially if you had more "SK*'
>> newsletter customers. Most VMS customers would feel more secure in their
>VMS
>> investments if HP were serious about growing the VMS market.
>>
>
>Can't argue that point, either.
>
--
Alan
Bill Todd
> Oooh. Boy am I offended comming from you. Responding to "specifics" of
> your speculations, bad mouthing, and rabble rousing is a waste of time
The typical response of one who has nothing substantive to offer in return.
Fuck off, Fred.
- bill
Bill Todd
"WILLIAM WEBB" <WWE...@email.usps.gov> wrote in message
news:0033000071918656000002L062*@MHS...
Did it occur to anyone that, when small steps are
taken in a positive direction, complaining about
the size of the steps doesn't improve the chances
for additional movement in that direction?
Yes. And it probably also occurred to most of those same people that
expressing unqualified enthusiasm rather than saying "That's a good start -
now here's what you *really* need to do" might be a good way to ensure that
those small steps were the last ones taken.
- bill
Rob Young
> (ahem) Actually, I think it's an oversight on YOUR part. The press
> release you quote doesn't mention the numbers from Intel Pentium 4.
> Check out the SPEC_int_base2000 graph at this URL:
>
> http://www.hp.com/products1/itanium/performance/architecture/speccpu.html
>
> You'll see that an Intel Pentium 4 2.53 GHz/533 MHz system bus box
> got 893 SPECint_base2000, vs. 810 for the Itanium 2 box.
>
>
Right. Scratch that subject line.
Rob
JF Mezei
> It may be telling that the current Intel "Itanium-2" ads running in
> the UK trade press list the "enterprise solutions" operating systems
> being ported as:
>
> Windows Advanced Server
> Windows Datacenter Server
> Windows Enterprise Server
I thought that only Advanced Server special edition 1.2 would be available
shortly. Are the other ones coming "soon" or are they available already ? (or
are the the same ?)
If The list you provided mentioned some systems that are not yet available,
then VMS and NSK should have been listed too.
JF Mezei
> Now that's a really great whine. Company puts together a training session
> (pilot program) and people bitch.
>
> Company puts together a roadshow and people bitch.
Please define "company". I see a big difference between "Company" and
"Department".
Folks are very aware that the VMS department is working wonders to do their
best to promote VMS *despite* the "Company" (Digital, Compaq, HP or whatever
is next).
I have absolutely no expectation that HP will promote VMS. I have expectations
that HP will prevent the VMS department from promoting itself too much. As a
result, I have no expectations of seing easy access to VMS information from
the Corporate HP web site.
Fred Kleinsorge
all *I* still have something to do with VMS, and you are just some
disgruntled hack. Your response is typical of an egomaniacal gas bag
leaking. You want to go and try and impress people in comp.arch - have at
it - not that I know what your involvement in computer architecture is.
Nothing, and I mean *nothing* you have posted in a very long time has had
anything of substantive value to offer. Just negative opinions and
rantings. Shouting down and insulting anyone who might disagree. Here we
have some evidence that at least some of your authoratative claptrap is just
that.
Bill Todd wrote in message ...
>
Bill Todd
> Bill Todd wrote:
> > All the above ignores pricing issues (which work to Itanic's advantage
> > against the usual RISC suspects, with the possible exception of SPARC,
but
> > work against Itanic in comparisons with IA32 and Hammer).
>
> Does the $4000 Itanic outperform its peers ?
That's not as simple a question as it might seem.
First of all, the context of the post to which you responded was not just
this instant in time but the near- and not-so-near-term future. McKinley is
about to appear (despite its launch, general availability does not seem to
exist yet), 1.25 GHz Alphas are about to appear, enhanced-performance
low-cost USIIIis are about to appear
http://www.aceshardware.com/read.jsp?id=50000244 ), faster POWER4s are
about to appear, faster IA32 platforms are *constantly* popping up, EV7 and
Hammer will appear before year's end, ... And that's just for *this* year.
Second, despite their efforts to be consistent, benchmarks sometimes aren't.
For example, the good $/tpmC figures HP posted for McKinley come from
unspecified specially-discounted system prices
http://www.theregus.com/content/3/25530.html ) that may not reflect
configurations customers will be likely to want.
Third, Itanic performance may depend more heavily than usual on the system
it's embedded in - e.g., HP is claiming its chip sets will offer a 15% - 20%
advantage over competing configurations
http://www.theregus.com/content/3/25532.html ).
Fourth, what's a 'peer' to Itanic? It might not be too unreasonable to
exclude IA32 platforms (though they will be vigorous competitors in the
low-end 'standard' server space that was originally supposed to create the
volume for Itanic that would move it toward 'commodity'-level pricing), but
Hammer definitely will qualify.
All that's really clear is that McKinley is *very* performance-competitive
(unlike its predecessor) but already trails Pentium 4 in SPECint and as of
October should slightly trail both Alpha and POWER4 in SPECint (since they
both are scheduled for speed-bumps shortly) and likely POWER4 in SPECfp
(with Alpha coming in a not-too-distant 3rd). POWER4 retains its
significant dual-core advantage in server use (i.e., in a chip-to-chip
server comparison it remains clearly ahead). If EV7 appears before year's
end, it should regain the lead fairly decisively in both SPEC benchmarks
unless Hammer bests it in SPECint (but the dual-core POWER4 will remain
ahead in a chip-to-chip server-performance comparison). If USIIIi appears
soon as scheduled, it should narrow the gap with McKinley but still trail
it, as should the recently-released 875 MHz PA-RISC 8700.
Beyond this year, most of the other architectures (with the conspicuous
exception of Alpha) have additional enhancements (beyond simple
process-shrinks) planned whereas Itanic does not. This seems unlikely to
improve Itanic's relative position.
>
> If Intel publicly says the 3meg chip sells for $4000, what would be the
> ballpark prince that HP would actually pay for it ? (considering all the
deals
> it and Compaq did with Intel)
>
> If volumes do not pick up for that enterprise-only chip, isn't it fair to
> think that the prices for the chip aren't going to drop ?
>
> At that cost, is IA64 really that competitive ?
HP has little incentive to make Alphas or PAs competitive cost-wise with
Itanic, so in those two cases the answer may be 'yes'. IBM might act
similarly except that they seem to be going after Sun, and Sun's pricing is
very competitive indeed, so we'll just to keep an eye on POWER4. I really
don't know what SGI is doing with MIPS these days.
Seems to me that there is no
> way it could compete against the 8086.
Or Hammer. Or, possibly, USIIIi if Sun is really serious about playing down
there.
- bill
JF Mezei
> Itanium support. Some C and C++ front-end folks were also sold to
> Intel. Front-end folks (like me) for other compilers (Pascal, COBOL,
> BASIC, etc.) all remained at Compaq/HP.
What was the rationale behind donating only "some" of the C and C++ to Intel ?
How much is left at "Digital" for C and C++ ? Just maintenance or still enough
to develop the compilers a bit more ?
> 3) Given that Intel doesn't have a BLISS compiler :-), it made sense to
> enhance GEM to support an OpenVMS Itanium target (the GEM developers did
> this work before departing to Intel).
Now that they were shipped to Intel, is the GEM support for VMS IA64 "mature"
with no more development, or will Intel continue to develop it for VMS ?
Just how different is GEM for VMS versus GEM for another OS on the same
architecture ?
> COBOL, Basic), we think this is adequate for the long-term. For C, in
> the short-term (to aid porting of OpenVMS and to provide the ultimate in
> source compatibility for the customers), we have a Compaq C front-end
> hooked to the OpenVMS Itanium GEM. In the longer term, we are moving
> towards using Intel
Once you have DEC-C ported to IA64, using the GEM-VMS that was also ported,
and if you retain some of the DEC-C engineers at the "Digital" portion of the
company, what would really be the advantages of dumping DEC-C and going for
Intel-C ?
Will Intel-C use the same GEM on VMS as DEC-C will/is using ? If that GEM is
"mature" for VMS, doesn't it mean that Intel-C will be as stagnant as DEC-C on
IA64 in terms of fancy machine code generation to make best use of the EPIC
thing ?
Thanks for the explanations.
JF Mezei
>
> Did it occur to anyone that, when small steps are
> taken in a positive direction, complaining about
> the size of the steps doesn't improve the chances
> for additional movement in that direction?
Foole me one, shame on you. Fool me twice, shame on me.
After a decade of similar techniques used to shut up the naysayers only to
revert back to the "Digital is killing VMS" philosophy a little while later,
nobody should be saying "HP has finally changed its philosophy" just because
the word "OpenVMS" was seen in a couple of press releases.
6 months from now, if there has been a consistent mention of VMS in HP press
releases and if during that time, the exposure of VMS has increased
consistently, then yeah, kudos will be in order.
But HP must understand that VMS customers have been lied to so many times that
it takes time to rebuild trust and during that time, it is HP's responsability
to be patient before customers come to believe this is a sincere and permanent improvement.
WILLIAM WEBB
I can get sarcastic with the best of them, bill--
seppuku and france.
If my statements sound like unqualified enthusiasm,
perhaps it's what happens when they are compared to
the Eeyore-like pronouncements of others.
My objective in this forum has been to publicly laud
positive actions taken by HP since the acquisition.
God knows we've had enough "Imminent Death of VMS- Film at 11"
threads to last a whole lot of microfortnights.
My objective in email to folks at HP has been to
highlight past bad decisions and suggest remediation--
not to call individuals idiots or worse.
It has been my experience that you get taken more
seriously when you discuss both the positive and
negatives of a given issue.
I won't publish what anyone at HP has said to me in
reply emails-- except to say that I've not been given
the secret game plans.
I felt that HP was completely baffled by the uproar that
resulted from their initial pronouncements about VMS and
the fact that folks were doing everything but diagramming
sentences and reading chicken entrails every time anything
got said about VMS--
so I sat down and wrote a brief history of actions wrt VMS
from the GQBob era forward, and discussed how many of these
were perceived in a less-than-favorable light by a goodly
portion of the user community.
Among the things I've discussed at one time or another are:
the (mis)use of VMS/NSK profits to prop up marginally profitable
WIntel sales; the perception that VMS was in maintenance mode
and the urgent necessity of taking major steps to overcome that
perception; the ever-present application availablity problem; and
the ever-present .edu problem.
Nothing we haven't discussed here in great detail; I just wrote
a condensed version.
I've also suggested that they mine the archives for all the
excellent suggestions that have been posted here by so many good
folks.
And, again I say, they *are* listening.
Large ships change course slowly.
Am I the only one who senses a sea change here?
A change that might just be a willingness to loosen the constraints
under which VMS has been placed in the past?
This is just opinion-- I think that they've decided to
change course, but they haven't decided how far to turn yet.
And, as I've said more than once, polite and reasoned feedback will
be listened to and, in my experience, will receive a reply.
WWWebb
-----Original Message-----
From: Info-VAX...@Mvb.Saic.Com at INTERNET
Sent: Wednesday, July 10, 2002 1:31 PM
To: Webb, William W Raleigh, NC; Info...@Mvb.Saic.Com at INTERNET
Subject: RE: McKinley tops SpecFP AND SpecInt charts
"WILLIAM WEBB" <WWE...@email.usps.gov> wrote in message
news:0033000071918656000002L062*@MHS...
Did it occur to anyone that, when small steps are
taken in a positive direction, complaining about
the size of the steps doesn't improve the chances
for additional movement in that direction?
John Reagan
> John Reagan wrote:
>
>>Itanium support. Some C and C++ front-end folks were also sold to
>>Intel. Front-end folks (like me) for other compilers (Pascal, COBOL,
>>BASIC, etc.) all remained at Compaq/HP.
>
>
> What was the rationale behind donating only "some" of the C and C++ to Intel ?
> How much is left at "Digital" for C and C++ ? Just maintenance or still enough
> to develop the compilers a bit more ?
>
I wasn't involved in the decision making. I can't speak to any
rationale. :-) As to "how much" is left, I really can't say (and don't
really want to say). We will do whatever is needed to get quality
compilers in place with the features needed by the customers.
>
>>3) Given that Intel doesn't have a BLISS compiler :-), it made sense to
>>enhance GEM to support an OpenVMS Itanium target (the GEM developers did
>>this work before departing to Intel).
>
>
> Now that they were shipped to Intel, is the GEM support for VMS IA64 "mature"
> with no more development, or will Intel continue to develop it for VMS ?
>
We didn't sell GEM to Intel. GEM is still a Compaq/HP piece of
software. Intel doesn't have any vested interest in developing GEM. As
for "mature" or not, the remaining GEM developers are committed to doing
whatever is needed to GEM to make sure it is adaquate for new chips like
Itanium 2 and beyond.
> Just how different is GEM for VMS versus GEM for another OS on the same
> architecture ?
Some pieces identical. Some pieces very different. To give specifics,
lets compare GEM for OpenVMS Alpha and GEM for Tru64 Alpha... Certainly
the instruction set is the same as well as most of the optimizations.
However, calling sequences, object file format, debug info format, OS
support for exceptions and speculation, etc. all add up to significant
differences between 2 Alpha platforms.
>
>
>>COBOL, Basic), we think this is adequate for the long-term. For C, in
>>the short-term (to aid porting of OpenVMS and to provide the ultimate in
>>source compatibility for the customers), we have a Compaq C front-end
>>hooked to the OpenVMS Itanium GEM. In the longer term, we are moving
>>towards using Intel
>
>
>
> Once you have DEC-C ported to IA64, using the GEM-VMS that was also ported,
> and if you retain some of the DEC-C engineers at the "Digital" portion of the
> company, what would really be the advantages of dumping DEC-C and going for
> Intel-C ?
One possible advantage is that while the Itanium target for GEM will
generate adequate code, the Intel Itanium code generator may out perform
it in several areas. Moving towards the Intel compiler would provide C
and C++ users with better code quality. This area is still under
investigation.
>
> Will Intel-C use the same GEM on VMS as DEC-C will/is using ?
Goodness no. The Intel C/C++ compiler uses Intel's code generator. See
above.
Bill Todd
I can get sarcastic with the best of them, bill--
seppuku and france.
If my statements sound like unqualified enthusiasm,
perhaps it's what happens when they are compared to
the Eeyore-like pronouncements of others.
***
What your statement that I responded to sounded like was a suggestion that
the insignificant (though unexpected) recognition HP has accorded VMS
recently should be sufficient to silence criticism. If you meant otherwise,
you failed make it at all clear.
***
My objective in this forum has been to publicly laud
positive actions taken by HP since the acquisition.
***
And my objective since last June has been to highlight the continuing loads
of manure Compaq and its cronies insist on spreading here. Both are
reasonable and useful endeavors.
***
God knows we've had enough "Imminent Death of VMS- Film at 11"
threads to last a whole lot of microfortnights.
***
Gee, I wonder why? Such things usually have *some* reason for occurring -
and given that you've chosen to grossly exaggerate their nature, I'd say the
discussion that has actually occurred (concern that VMS development would
languish, customers get increasingly milked, and use dwindle over time,
rather than the instantaneous demise your comment suggests) was more than
justified.
***
My objective in email to folks at HP has been to
highlight past bad decisions and suggest remediation--
not to call individuals idiots or worse.
***
That's nice, but the subject here is not email to HP but conversations in
c.o.v. - and both what's appropriate to discuss and how to discuss it differ
radically between the two media.
***
It has been my experience that you get taken more
seriously when you discuss both the positive and
negatives of a given issue.
***
Unfortunately, that generally hasn't happened - and those on the 'positive'
side are not one whit less responsible for this situation than those on the
'negative' side. It's called polarization, and once it's occurred it tends
to be self-perpetuating.
Since the instigating force behind this has been the long history of neglect
of VMS (and of course Alpha) that culminated in the Alphacide, and since
*no* moves have yet been made to compensate in any measurable way for the
damage this has done, and since VMS's owners have yet to deviate from
treating VMS's customers like mushrooms (kept in the dark and fed shit -
*especially* in the garbage promulgated by Compaq and its minions after last
June), I'd say it was up to the 'positive' side to move to the center if
they want to break this deadlock: if they do so, I and I suspect many
others will be more than happy to meet them there and discuss the situation
on its merits - though until those merits themselves change the conversation
remains likely to be uncomfortable for those who would prefer that everyone
just forget about the past and be optimistic about the future.
***
I won't publish what anyone at HP has said to me in
reply emails-- except to say that I've not been given
the secret game plans.
I felt that HP was completely baffled by the uproar that
resulted from their initial pronouncements about VMS and
the fact that folks were doing everything but diagramming
sentences and reading chicken entrails every time anything
got said about VMS--
so I sat down and wrote a brief history of actions wrt VMS
from the GQBob era forward, and discussed how many of these
were perceived in a less-than-favorable light by a goodly
portion of the user community.
Among the things I've discussed at one time or another are:
the (mis)use of VMS/NSK profits to prop up marginally profitable
WIntel sales; the perception that VMS was in maintenance mode
and the urgent necessity of taking major steps to overcome that
perception; the ever-present application availablity problem; and
the ever-present .edu problem.
Nothing we haven't discussed here in great detail; I just wrote
a condensed version.
I've also suggested that they mine the archives for all the
excellent suggestions that have been posted here by so many good
folks.
***
And all those things are great. I wouldn't have had the optimism to expect
such efforts to be worth making (since everyone at Marcello's level and
below should already be well-acquainted with reality), and quite possibly
neither the patience to state them unconfrontationally in any event, but if
you did then that justifies your efforts - and more power to them.
***
And, again I say, they *are* listening.
Large ships change course slowly.
Am I the only one who senses a sea change here?
A change that might just be a willingness to loosen the constraints
under which VMS has been placed in the past?
***
Am I the only one who senses something very much like the purported 'sea
change' that was called the 'VMS renaissance' two years ago?
***
This is just opinion-- I think that they've decided to
change course, but they haven't decided how far to turn yet.
***
And some people thought exactly the same thing two years ago. Which is one
reason many people (including some of that former group of optimists) won't
be convinced this time until they *see* change, and substantive change at
that.
***
And, as I've said more than once, polite and reasoned feedback will
be listened to and, in my experience, will receive a reply.
***
That wasn't *ever* a problem at Marcello's level and below, and never made a
bit of difference before.
While it certainly won't hurt (and might help) for anyone so inclined to
provide such feedback, I suspect what most people here want is not a reply
but action. Meanwhile, until such definitive action occurs, expect the lack
of it to be highlighted here.
- bill
Mark Berryman
> >Nick Maclaren wrote:
> >> Then I suggest that you quote performance figures based on them,
> >> and do not flame me when I point out that the figures quoted by
> >> HP on Monday are not what most McKinley customers will get.
> >
> >Since IA64 is currently still poised to be mostly HP's chip, much like Alpha
> >was Digital's stating that most IA64 customers would be running HP's compiler
> >might not be wrong.
>
> Linux and some sort of Microsoft product. It has at least two
> others under development: VMS and NSK. Microsoft has said that
> it is developing .NET. As far as I know, HP's compilers are
> available only for HP-UX, and that is not going to change.
>
> In particular, this is comp.os.vms, and VMS has been stated to
> be planned NOT to use HP's compiler. I think that I am being
> fairly reasonable in pointing out that performance figures
> obtainable only with HP's compilers aren't what customers will
> get.
>
Well, let's see. Of the benchmarks done: (data taken from Intel's web
page)
Transaction Processing: work done at Intel, O.S. not specified.
SAP 2-tier SD: Windows Advanced Server LE
Security Performance:
Coradiant Secure Transactions: Linux
SPECweb99_SSL: HP-UX
Linpack: HP-UX
System Memory Bandwidth: not specified
Mechanical Computer Aided Engineering (Nastran): Windows .NET
SPECint_base2000: HP-UX
SPECfp_base2000: Linux
It certainly doesn't look to me like only HP compilers were used. In
fact, I haven't found anything yet that says what compilers were used.
So what is the basis for your claim that these performance figures are
only avaiable with HP compilers (and, by extension, only on HP-UX)?
Mark Berryman
Mark.B...@Mvb.Saic.Com
Nick Maclaren
Mark Berryman <Mark.B...@Mvb.Saic.Com> wrote:
>Nick Maclaren wrote:
>>
>> HP's IA-64 announcement referred to 3 operating systems: HP-UX,
>> Linux and some sort of Microsoft product. It has at least two
>> others under development: VMS and NSK. Microsoft has said that
>> it is developing .NET. As far as I know, HP's compilers are
>> available only for HP-UX, and that is not going to change.
>>
>> In particular, this is comp.os.vms, and VMS has been stated to
>> be planned NOT to use HP's compiler. I think that I am being
>> fairly reasonable in pointing out that performance figures
>> obtainable only with HP's compilers aren't what customers will
>> get.
>
>Well, let's see. Of the benchmarks done: (data taken from Intel's web
>page)
>
>
>SPECfp_base2000: Linux
>
>It certainly doesn't look to me like only HP compilers were used. In
>fact, I haven't found anything yet that says what compilers were used.
>So what is the basis for your claim that these performance figures are
>only avaiable with HP compilers (and, by extension, only on HP-UX)?
We were talking about the Spec figures. I have so far failed to
find this page referred to, but two of you have said that SpecFP
was produced on Linux. However, the figure that is most indicative
of CPU performance of general applications is SpecInt, and that is
the one that is believed to be 20% lower with Intel's compilers.
Bill Todd
"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:agib0n$k4f$1...@pegasus.csx.cam.ac.uk...
...
> We were talking about the Spec figures. I have so far failed to
> find this page referred to, but two of you have said that SpecFP
> was produced on Linux. However, the figure that is most indicative
> of CPU performance of general applications is SpecInt, and that is
> the one that is believed to be 20% lower with Intel's compilers.
AFAIK HP's is the only SPECint figure yet made public (though an Intel
figure of '760+' was leaked a few days ago) - and while there has been some
speculation about the relative merit of HP's compilers vs. others I have not
seen anything quantitative (if you have a source I'd be interested).
But HP themselves have asserted (last paragraph of
http://www.theregus.com/content/3/25532.html ) that they believe their chip
sets give them a 15% - 20% performance advantage - so (among other things)
knowing whose chip sets were used for the many other performance figures I
clipped above might be interesting.
- bill
Bill Todd
> No why don't *you* leave comp.os.vms to those of us who still care, after
> all *I* still have something to do with VMS, and you are just some
> disgruntled hack. Your response is typical of an egomaniacal gas bag
> leaking. You want to go and try and impress people in comp.arch - have at
> it - not that I know what your involvement in computer architecture is.
That appears to be consistent with your general level of knowledge, Fred.
If I didn't care, I wouldn't be here. And if I didn't say things worth
listening to, no one would.
>
> Nothing, and I mean *nothing* you have posted in a very long time has had
> anything of substantive value to offer.
How would you know? You aren't willing to engage in the discussion it would
take to determine it (assuming it's not clear to you at first reading).
We have different viewpoints, and are both angry (though for different
reasons). The other difference between us is that I substantiate my views,
but you just disparage them while refusing to present anything substantive
in the way of rebuttal. In other words, while you probably have areas in
which you're technically competent, in these particular waters you've
presented nothing to suggest any competence whatsoever (rather the
opposite).
Just negative opinions and
> rantings. Shouting down and insulting anyone who might disagree.
No, just those who disparage without offering anything substantive in
return: they deserve it.
Here we
> have some evidence that at least some of your authoratative claptrap is
just
> that.
Really? Since I've always been very careful in attributing the bases of my
extrapolations - usually to public statements made by Intel (in this case;
Compaq in many others) - I'd say you just haven't (as usual) been paying
enough attention. If HP's claim that their chip sets are 15% - 20% better
than the competition applies to Intel's chip sets, then guess what? Intel's
SPECint performance will wind up comfortably within the range I've been
predicting for it, and be entirely consistent with their statements upon
which I based those predictions.
Or not: we'll see, if and when SPECint figures for Intel chip sets (and for
that matter HP's as well) appear at spec.org. But that won't change the
reasonableness of the predictions I made based on the Intel-provided
material available at the time.
So I'll say it yet again, Fred: step up to the plate with something
substantial, or fuck off.
- bill
John Smith
>
>
> At the very least things are less stealthy in VMSland today than they were
> three months ago.
I would agree with that, however (there's always a however, isn't there?) to
use an analogy, F-117's are less stealthy than B-2's but you still can't
see them on radar.
> > They aren't serious about VMS. If they were, they'd be growing the
market
> > rather than preaching to the converted.
>
> I think it depends on who the "they" are. Certainly Mark Gorham and his
> understudies are serious. As for the folks higher up in the food chain, I
> can't help but wonder why NSK is viewed as a growth opportunity and VMS is
> not. I can understand why HPQ would want to stress HP-UX, but methinks
there
> are prospects who have no interest in HP-UX. VMS might be the Better
Answer
> for them. In competitive situations when going against IBM and MVS, VMS
> might be the Better Answer. Etc.
There has always been a core cadre of people in charge of the VMS 'division'
that has held out high hope and stuck their necks on the line for VMS.
Unfortuantely, there thave been goofs (I'd use the term 'fool' except that
sort of implies that they have considered their actions first) in charge of
executive managment who don't know a bit from a byte, a customer need from a
marketing target, and a coherent strategy from a pile of dung.
NSK isn't viewed as a growth strategy except to say that it will increase
sales in lockstep with the general growth of the population, perhaps 3% per
annum, as companies who use NSK increase their capacity. Meanwhile the
general computing market will grow at perhps twice that rate once business
really turns around. And that's with marketing and sales effort. Since VMS
is not accorded that same marketing and sales effort, its base will decline.
And as to MVS, I'd be really surprised if Compaq/HP has anyone left on staff
who knows how to spell MVS in a competitive sales situation, much less can
accurately speak about the strengths and weaknesses of it vs. OpenVMS.
>
> HPQ has yet to adequately articulate a rationale for its VMS strategy.
>
They just don't have a clue, any more than Comapq had a clue. They should
be looking to General Motors and Ford for ideas. Both of these companies
have products within their own lineups which overlap market segments, and
may even have multiple models within a 'brand' which overlap. ie. large and
small SUV's by Chevy, Cadillac, Buick, Hummer H2. They can choose to
advertise to one particular demographic group, or by changing the pitch they
can aim a Hummer H2 at the same guy who could buy a Cadillac SUV or a Chevy
SUV or a Buick SUV, or some other set of combinations, while at the same
time presenting ads that favorably position GM products vs. Ford's or BMW's
or Land Rover's SUV's.
But HP is choosing not to advertise/market OpenVMS at all.
Maybe George Bush in his push for good corporate governance should look at
the effects stupid corporate decision making on the part of suppliers has on
the competitiveness and effectiveness of American industry. If I were him,
and thank god I'm not, I'd look at ComHpaq as my first case of 'destructive
synergy' plaguing corporate America.
> > Bet you'd feel a lot more comfortable financially if you had more "SK*'
> > newsletter customers. Most VMS customers would feel more secure in their
> VMS
> > investments if HP were serious about growing the VMS market.
> >
>
> Can't argue that point, either.
So, he said rhetorically, if these are so many points that can't be argued,
maybe a special free issue of "SK*" detailing the corporate malfeasance of
HP towards its products and customers and the financial implications thereof
should be sent to all the fund managers (shareholders) that own big chunks
of HP stock. Maybe that could force HP to be more public about just what
they think their strategy is, and whether what they think is disconnected
from the reality in the field. Perhaps the fund managers could convince the
Board of Directors to change horses and strategies too.