Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Did any one post this Oracle link already?
197 views
Skip to first unread message
Dirk Munk
Jun 1, 2012, 3:57:52 AM6/1/12
to
http://www.oracle.com/us/corporate/features/itanium-346707.html
It has a list of HP documents that clearly shows that HP has been aware
that Itanium was dead years ago.
So we were right all along when this super expensive heated floor tile
'replaced' the Alpha.
Perhaps we should send HP that wonderful DEC pdf document that compared
the Alpha with the Itanium? Is it still on-line somewhere?
It has a list of HP documents that clearly shows that HP has been aware
that Itanium was dead years ago.
So we were right all along when this super expensive heated floor tile
'replaced' the Alpha.
Perhaps we should send HP that wonderful DEC pdf document that compared
the Alpha with the Itanium? Is it still on-line somewhere?
John Wallace
Jun 1, 2012, 4:57:42 AM6/1/12
to
with the conclusion I've included below, which for now is still online
at e.g.
http://www.cs.trinity.edu/~mlewis/CSCI3294-F01/Papers/alpha_ia64.pdf
Conclusion
An Alpha processor will be able to exploit static instruction-level
parallelism (discovered
by the compiler at compile-time) and dynamic instruction-level
parallelism (discovered
by the processor at run-time). An IA64 processor will only be able to
exploit static
instruction-level parallelism.
An Alpha processor can take advantage of the excellent compiler
technology developed
for IA64 and other VLIW processors; much of this technology is already
implemented in
the Alpha compilers. However, the Alpha compilers will be able to use
these
optimizations much more judiciously, avoiding excessive code growth,
because the Alpha
out-of-order processor can also discover instruction-level parallelism
at run-time.
An Alpha processor will be able to adapt to dynamic program behavior
at run-time. An
IA64 processor will not. An Alpha processor can adapt to memory
references that miss in
the cache, avoiding delays of 100 cycles or more. An IA64 processor
will stall. An
Alpha processor can find instruction-level parallelism when the
compiler does not
express it. And an Alpha processor can find instruction-level
parallelism at run-time
across branches, function calls, and compilation boundaries.
An Alpha processor will be able to exploit thread-level parallelism.
An IA64 processor
will not. Most server applications are divided into multiple threads,
and simultaneous
multithreading permits these applications to take full advantage of
the multiple execution
units on the processor. An Alpha processor can use thread-level
parallelism and
instruction-level parallelism interchangeably, adjusting to the
behavior of the application.
Amdahl’s law says that high performance requires speedups in both the
sequential and the
explicitly parallel portions of an application; an Alpha processor can
deliver these
speedups.
An Alpha processor will deliver the highest memory bandwidth in the
industry, and
systems built out of Alpha processors will lead the industry in high
performance technical
computing.
An Alpha processor will significantly outperform an IA64 processor on
commercial
applications. Alpha processors have addressed the main requirements of
commercial
applications: reducing the instruction cache footprint, tolerating
unpredictable cache
misses, increasing the pin bandwidth, and exploiting explicit thread-
level parallelism.
IA64 processors are not well designed for commercial applications.
They require a large
instruction cache footprint; they cannot dynamically tolerate cache
misses; and they
cannot exploit thread-level parallelism.
In the important server markets, Alpha will outperform IA64.
<followed by 14 references to other technical papers, patents, DTJ,
etc>
ChrisQ
Jun 1, 2012, 7:39:04 AM6/1/12
to
parallel with Itanium until they were sure which one was the better, but
i've given up expecting common sense from hp. Hubris and incompetence are
always eventually their own reward...
Regards,
Chris
Phillip Helbig---undress to reply
Jun 1, 2012, 8:09:58 AM6/1/12
to
In article <sR1yr.1048562$o93....@fx05.am4>, ChrisQ <me...@devnull.com>
writes:
> On 06/01/12 07:57, Dirk Munk wrote:
> > http://www.oracle.com/us/corporate/features/itanium-346707.html
> >
> > It has a list of HP documents that clearly shows that HP has been aware
> > that Itanium was dead years ago.
To be fair, someone posted a link from HP today which tells things from
their point of view. While some scepticism with respect to HP is in
order because of its treatment of VMS in the past, one certainly
shouldn't assume that Ellison is the, errm, oracle of truth. If
anything, he comes out of this looking worse.
writes:
> On 06/01/12 07:57, Dirk Munk wrote:
> > http://www.oracle.com/us/corporate/features/itanium-346707.html
> >
> > It has a list of HP documents that clearly shows that HP has been aware
> > that Itanium was dead years ago.
their point of view. While some scepticism with respect to HP is in
order because of its treatment of VMS in the past, one certainly
shouldn't assume that Ellison is the, errm, oracle of truth. If
anything, he comes out of this looking worse.
Dirk Munk
Jun 1, 2012, 9:17:44 AM6/1/12
to
I remember vividly the discussions we had about the Itanium at the time
of the Alphacide, I'm sure you remember them as well. No one in this
forum was in favour of the Itanium.
At the time Intel was still positioning the Itanium as *the* 64 bit
successor of the 32 bit x86 architecture. We did not believe it, and
certainly not when AMD came with the 64 bit x86. Remember how Intel
snubbed any one who said the AMD approach would succeed?
At the time the Itanium still had the 32 bit x86 instruction set
included for compatibility reasons, the problem was that in that mode it
was about as fast as the very first 60MHz Pentium, so it was absolutely
useless.
IBM also wrote damming reports on the Itanium.
In fact only HP wanted it, because it was also designed to replace the
PA-Risc and HP engineers were involved in the development.
In my view Compaq's Curly only decided to replace the Alpha by the
Itanium in order to make Compaq more attractive for HP. A prime example
of a very stupid short-sighted management decision.
Jeffrey H. Coffield
Jun 1, 2012, 10:06:20 AM6/1/12
to
On 06/01/2012 01:57 AM, John Wallace wrote:
> In the important server markets, Alpha will outperform IA64.
> <followed by 14 references to other technical papers, patents, DTJ,
> etc>
experience with moving our customers from Alpha to Itanium. Our
benchmarks for the applications we have developed showed that overall
the Itaniums were about 20% slower than an Alpha for the same clock
speed. BUT they were way cheaper when all the hardware and software
licences were added up. We were in general moving from single cpu 300 to
500 Mhz Alphas to dual processor 1.6 Ghz Itaniums with three years of
support for about the same amount of money that the hardware and
software maintenance on the existing Alphas was over three years. No one
cared that technically an Alpha at the same clock speed would have been
faster. For the same amount of money they were already going to spend
they got about 4 times the procesing power.
Jeff Coffield
www.digitalsynergyinc.com
Bob Koehler
Jun 1, 2012, 10:28:10 AM6/1/12
to
> The sensible thing would have been to keep Alpha development running in
> parallel with Itanium until they were sure which one was the better, but
> i've given up expecting common sense from hp. Hubris and incompetence are
> always eventually their own reward...
How could HP continue something that was stopped before they bought
> parallel with Itanium until they were sure which one was the better, but
> i've given up expecting common sense from hp. Hubris and incompetence are
> always eventually their own reward...
Compaq?
Restarting Alpha development might have been a good technical path,
but hardly promised to be commercially viable.
One of DEC's problems was trying to follow what they thought the
better technical path was, while ignoring business realities.
Dirk Munk
Jun 1, 2012, 11:41:01 AM6/1/12
to
1. There is no real reason why thee should be a difference in the price
of software licenses and maintenance between Alpha and Itanium. It is
purely artificial based on HP's desire to sell Itanium.
2. The same applies to the hardware, it tends to get cheaper. I wonder
what a modern Alpha system would cost these days.
glen herrmannsfeldt
Jun 1, 2012, 2:31:17 PM6/1/12
to
Jeffrey H. Coffield <jef...@digitalsynergyinc.com> wrote:
(snip)
> I normally stay out of these discussion but I would like to add my
> experience with moving our customers from Alpha to Itanium. Our
> benchmarks for the applications we have developed showed that overall
> the Itaniums were about 20% slower than an Alpha for the same clock
> speed.
It is normally not useful to compare pipelined processors by
clock speed. As part of the design, one must choose where to put
the pipeline registers, which can vary the amount of work done per
clock cycle by a fairly large factor. It gets even harder when you
compare multiple issue (start more than one instruction per cycle)
processors. VLIW makes it even harder.
> BUT they were way cheaper when all the hardware and software
> licences were added up. We were in general moving from single cpu 300 to
> 500 Mhz Alphas to dual processor 1.6 Ghz Itaniums with three years of
> support for about the same amount of money that the hardware and
> software maintenance on the existing Alphas was over three years. No one
> cared that technically an Alpha at the same clock speed would have been
> faster. For the same amount of money they were already going to spend
> they got about 4 times the procesing power.
The exact timing is a complicated function of the instruction
being executed.
For some time, I was working on problems that did a very large
number of byte and 16 bit fixed point arithmetic. The often did
relatively poorly on processors designed to pipeline 64 bit
floating point at high speed.
-- glen
(snip)
> I normally stay out of these discussion but I would like to add my
> experience with moving our customers from Alpha to Itanium. Our
> benchmarks for the applications we have developed showed that overall
> the Itaniums were about 20% slower than an Alpha for the same clock
> speed.
clock speed. As part of the design, one must choose where to put
the pipeline registers, which can vary the amount of work done per
clock cycle by a fairly large factor. It gets even harder when you
compare multiple issue (start more than one instruction per cycle)
processors. VLIW makes it even harder.
> BUT they were way cheaper when all the hardware and software
> licences were added up. We were in general moving from single cpu 300 to
> 500 Mhz Alphas to dual processor 1.6 Ghz Itaniums with three years of
> support for about the same amount of money that the hardware and
> software maintenance on the existing Alphas was over three years. No one
> cared that technically an Alpha at the same clock speed would have been
> faster. For the same amount of money they were already going to spend
> they got about 4 times the procesing power.
being executed.
For some time, I was working on problems that did a very large
number of byte and 16 bit fixed point arithmetic. The often did
relatively poorly on processors designed to pipeline 64 bit
floating point at high speed.
-- glen
glen herrmannsfeldt
Jun 1, 2012, 2:34:06 PM6/1/12
to
Dirk Munk <mu...@home.nl> wrote:
(snip)
processor less than twice as much. Also, dual processor box license
are often (maybe not always) less than twice single processor box
licenses.
> 2. The same applies to the hardware, it tends to get cheaper. I wonder
> what a modern Alpha system would cost these days.
It is usual for older hardware to have a higher maintenance cost,
and so higher cost contract.
-- glen
(snip)
> I see what you mean, however:
> 1. There is no real reason why thee should be a difference in the price
> of software licenses and maintenance between Alpha and Itanium. It is
> purely artificial based on HP's desire to sell Itanium.
It is usual not to price the license for a twice-as-fast
> 1. There is no real reason why thee should be a difference in the price
> of software licenses and maintenance between Alpha and Itanium. It is
> purely artificial based on HP's desire to sell Itanium.
processor less than twice as much. Also, dual processor box license
are often (maybe not always) less than twice single processor box
licenses.
> 2. The same applies to the hardware, it tends to get cheaper. I wonder
> what a modern Alpha system would cost these days.
and so higher cost contract.
-- glen
JF Mezei
Jun 1, 2012, 2:40:30 PM6/1/12
to
Bob Koehler wrote:
> How could HP continue something that was stopped before they bought
> Compaq?
Because it is LaCarly who told Curly to kill Alpha in June before the
> How could HP continue something that was stopped before they bought
> Compaq?
September 7th 2001 wedding announcement.
Remember that the couple were already in wedding planning at that time
and killing Alpha was likely a big precondition of the deal. And it also
meant that Compaq got to negotiate with Intel a separate deal for
porting funding which carried over after the wedding.
Phillip Helbig---undress to reply
Jun 2, 2012, 5:46:47 AM6/2/12
to
In article <63a23$4fc8c0f9$5ed43c14$11...@cache1.tilbu1.nb.home.nl>,
fool has said in his heart there is no God". This is the whole issue
here. One can demonstrate almost anything with cherry-picking,
quote-mining, selective citation. That's what the debate (soon court
case) is about.
> I remember vividly the discussions we had about the Itanium at the time
> of the Alphacide, I'm sure you remember them as well. No one in this
> forum was in favour of the Itanium.
There was a feeling that ALPHA was good and that it wasn't worth the
trouble to move to Itanium and the fear that Itanium wouldn't become
mainstream enough to justify moving to "industry standard" architecture.
Only experts know about the first but the second has certainly turned
out exactly as expected.
> At the time Intel was still positioning the Itanium as *the* 64 bit
> successor of the 32 bit x86 architecture. We did not believe it, and
> certainly not when AMD came with the 64 bit x86. Remember how Intel
> snubbed any one who said the AMD approach would succeed?
Right.
> In my view Compaq's Curly only decided to replace the Alpha by the
> Itanium in order to make Compaq more attractive for HP. A prime example
> of a very stupid short-sighted management decision.
I'm sure this is the case.
Dirk Munk <mu...@home.nl> writes:
> Phillip Helbig---undress to reply wrote:
> > In article<sR1yr.1048562$o93....@fx05.am4>, ChrisQ<me...@devnull.com>
> > writes:
> >
> >> On 06/01/12 07:57, Dirk Munk wrote:
> >>> http://www.oracle.com/us/corporate/features/itanium-346707.html
> >>>
> >>> It has a list of HP documents that clearly shows that HP has been aware
> >>> that Itanium was dead years ago.
> >
> > To be fair, someone posted a link from HP today which tells things from
> > their point of view. While some scepticism with respect to HP is in
> > order because of its treatment of VMS in the past, one certainly
> > shouldn't assume that Ellison is the, errm, oracle of truth. If
> > anything, he comes out of this looking worse.
>
> I'm sure, but these are HP documents, not Oracle documents.
One can read in the Bible "there is no God". The full sentence is "The
> Phillip Helbig---undress to reply wrote:
> > In article<sR1yr.1048562$o93....@fx05.am4>, ChrisQ<me...@devnull.com>
> > writes:
> >
> >> On 06/01/12 07:57, Dirk Munk wrote:
> >>> http://www.oracle.com/us/corporate/features/itanium-346707.html
> >>>
> >>> It has a list of HP documents that clearly shows that HP has been aware
> >>> that Itanium was dead years ago.
> >
> > To be fair, someone posted a link from HP today which tells things from
> > their point of view. While some scepticism with respect to HP is in
> > order because of its treatment of VMS in the past, one certainly
> > shouldn't assume that Ellison is the, errm, oracle of truth. If
> > anything, he comes out of this looking worse.
>
> I'm sure, but these are HP documents, not Oracle documents.
fool has said in his heart there is no God". This is the whole issue
here. One can demonstrate almost anything with cherry-picking,
quote-mining, selective citation. That's what the debate (soon court
case) is about.
> I remember vividly the discussions we had about the Itanium at the time
> of the Alphacide, I'm sure you remember them as well. No one in this
> forum was in favour of the Itanium.
trouble to move to Itanium and the fear that Itanium wouldn't become
mainstream enough to justify moving to "industry standard" architecture.
Only experts know about the first but the second has certainly turned
out exactly as expected.
> At the time Intel was still positioning the Itanium as *the* 64 bit
> successor of the 32 bit x86 architecture. We did not believe it, and
> certainly not when AMD came with the 64 bit x86. Remember how Intel
> snubbed any one who said the AMD approach would succeed?
> In my view Compaq's Curly only decided to replace the Alpha by the
> Itanium in order to make Compaq more attractive for HP. A prime example
> of a very stupid short-sighted management decision.
JF Mezei
Jun 2, 2012, 3:36:56 PM6/2/12
to
Phillip Helbig---undress to reply wrote:
> One can read in the Bible "there is no God". The full sentence is "The
> fool has said in his heart there is no God".
However, the snippets from Oracle match very well HP's behaviour with
> One can read in the Bible "there is no God". The full sentence is "The
> fool has said in his heart there is no God".
regards to IA64 and VMS since 2004.
Paying Intel to delay EOL of Itanium and paying Intel to keep mouth shut
and pretend all is well with IA64 is very hard to be taken out of
context especially when you consider how HP has caefully worded its
statements about IA64 and VMS/HP-UX over the years.
You also need to realise that IA64 is a low volume and highly expensive
chip to produce and design and its performance is years late and doesn't
give HP an edge compared to today's 8086s.
So, when you take all of the "snippets" together, it forms a
comprehensive picture which makes the Oracle snippets fit perfectly into
the puzzle.
Mazzini Alessandro
Jun 3, 2012, 4:40:09 AM6/3/12
to
> You also need to realise that IA64 is a low volume and highly expensive
> chip to produce and design and its performance is years late and doesn't
> give HP an edge compared to today's 8086s.
on an itanium based box. My innocent question is :
how much slower is itanium compared to a current x86 chip, assuming to run a
fairly complex math code written in C ( or whatever ) and compiled with an
optimized compiler (on both platforms)?
How much slower is , if the same operation is written on both in assembler ?
Phillip Helbig---undress to reply
Jun 3, 2012, 4:47:32 AM6/3/12
to
In article <4fca6b5a$0$65514$c3e8da3$4db3...@news.astraweb.com>, JF
costs of a business partner (think Intel and Microsoft) and it is not
uncommon that this not be disclosed.
> You also need to realise that IA64 is a low volume and highly expensive
> chip to produce and design and its performance is years late and doesn't
> give HP an edge compared to today's 8086s.
>
> So, when you take all of the "snippets" together, it forms a
> comprehensive picture which makes the Oracle snippets fit perfectly into
> the puzzle.
I'm not saying your analysis is wrong, I'm saying that both sides put
their own spin on it. One cannot ignore the fact that Ellison has his
own axe to grind.
Mezei <jfmezei...@vaxination.ca> writes:
> > One can read in the Bible "there is no God". The full sentence is "The
> > fool has said in his heart there is no God".
>
> However, the snippets from Oracle match very well HP's behaviour with
> regards to IA64 and VMS since 2004.
>
> Paying Intel to delay EOL of Itanium and paying Intel to keep mouth shut
> and pretend all is well with IA64 is very hard to be taken out of
> context especially when you consider how HP has caefully worded its
> statements about IA64 and VMS/HP-UX over the years.
This, too, is spin. It is not uncommon for a customer to subsidize
> > One can read in the Bible "there is no God". The full sentence is "The
> > fool has said in his heart there is no God".
>
> However, the snippets from Oracle match very well HP's behaviour with
> regards to IA64 and VMS since 2004.
>
> Paying Intel to delay EOL of Itanium and paying Intel to keep mouth shut
> and pretend all is well with IA64 is very hard to be taken out of
> context especially when you consider how HP has caefully worded its
> statements about IA64 and VMS/HP-UX over the years.
costs of a business partner (think Intel and Microsoft) and it is not
uncommon that this not be disclosed.
> You also need to realise that IA64 is a low volume and highly expensive
> chip to produce and design and its performance is years late and doesn't
> give HP an edge compared to today's 8086s.
>
> So, when you take all of the "snippets" together, it forms a
> comprehensive picture which makes the Oracle snippets fit perfectly into
> the puzzle.
their own spin on it. One cannot ignore the fact that Ellison has his
own axe to grind.
johnso...@gmail.com
Jun 3, 2012, 8:43:27 AM6/3/12
to
On Sunday, June 3, 2012 4:40:09 AM UTC-4, Mazzini Alessandro wrote:
> I'm an intruder and a lurker + I've never had the chance of putting my hands
> on an itanium based box. My innocent question is :
>
> how much slower is itanium compared to a current x86 chip, assuming to run a
> fairly complex math code written in C ( or whatever ) and compiled with an
> optimized compiler (on both platforms)?
>
> How much slower is , if the same operation is written on both in assembler ?
I only compared compiled code (C and C++) on x86 to Itanium.
> I'm an intruder and a lurker + I've never had the chance of putting my hands
> on an itanium based box. My innocent question is :
>
> how much slower is itanium compared to a current x86 chip, assuming to run a
> fairly complex math code written in C ( or whatever ) and compiled with an
> optimized compiler (on both platforms)?
>
> How much slower is , if the same operation is written on both in assembler ?
In my experience, x86 was always faster. Usually in the range of 2x-4x faster.
They were small programs that had a heavy CPU focus. They were home grown
programs that would reflect the simplified notion of what the system was doing.
I was trying to avoid anything that smelled of "SPEC" style benchmarks since
many compilers are heavily optimized towards just those problems.
What I found interesting about the comparison is that I could never come up
with a program that ran faster on Itanium. x86 *always* won. It was very
sobering and disappointing. The gap will continue to widen.
I suspect some of the problem is related to the compiler. The Itanium placed
a huge optimization burden onto the compiler and the compiler folks already
have their hands full. The Itanium EPIC pipe dream never came true.
Perhaps hand written assembly could truly showcase what the chip was capable
of. But I never delved that far.
EJ
Mazzini Alessandro
Jun 3, 2012, 10:18:35 AM6/3/12
to
Thanks for the answer, it gives a perfect picture of the situation
<johnso...@gmail.com> ha scritto nel messaggio
news:2e8e7937-c03d-49a2...@googlegroups.com...
<johnso...@gmail.com> ha scritto nel messaggio
news:2e8e7937-c03d-49a2...@googlegroups.com...
David Froble
Jun 3, 2012, 10:23:35 AM6/3/12
to
running both on the same process size. I don't remember the current process size for the
itanic, but the latest x86 from Intel is down to 22 nm, and AMD is I believe at 35 nm.
When asked what was more important for speed, architecture or process size, one of the
Alpha chip designers answered that process size is more important.
It's not that the itanic is better than Alpha, (and I believe it is not), but that the
process size (along with a hugh cache) continued to shrink for the itanic.
It's rather simple. Competition will improve just about anything. Lack of competition
promotes lack of effort. Intel is working as hard as they can to improve x86, because so
is AMD. Intel and HP were successful in killing off an impressive competitor, the Alpha
CPU design, and without much competition Intel has no overriding drive to improve IA-64.
Personally, I think that federal regulators totally screwed up, but then, campaign
contributions are so much more important than the good of the country, right?
johnso...@gmail.com
Jun 3, 2012, 10:40:04 AM6/3/12
to
On Sunday, June 3, 2012 10:23:35 AM UTC-4, David Froble wrote:
> Your testing is not appropriate, if you're looking to compare
> architectures, unless you're running both on the same process size.
The context I'm coming from is what I would expect most competitively minded
> Your testing is not appropriate, if you're looking to compare
> architectures, unless you're running both on the same process size.
businesses would be coming from. If your system can generate more profit by
consuming less elapsed time, then a switch to x86 can make a lot of sense.
Limiting that comparison to same sized "die" isn't a valid requirement in
the eyes of most shareholders.
If one is teaching a CPU architecture class and trying to highlight the
relative strengths of choices in pipelines, instruction design, compiler
choices, and the like, then such a request makes a ton of sense.
The fact that x86 is consistently faster should be a sobering fact to
anyone who is responsible for managing a system that can generate more
profit through additional speed.
EJ
Phillip Helbig---undress to reply
Jun 3, 2012, 11:01:00 AM6/3/12
to
In article <1fd0c16d-aea7-4faa...@googlegroups.com>,
programmers and system managers? Maybe less with VMS. What about HBVS
and clustering for availability? What about Rdb? None of this is
available without VMS (though some might use the same non-trademarked
buzzwords).
IF you are looking at costs, you have to look at TOTAL costs.
Depending on the application, adding some nodes to the cluster can make
up for slower CPUs.
johnso...@gmail.com writes:
> The context I'm coming from is what I would expect most competitively minded
> businesses would be coming from. If your system can generate more profit by
> consuming less elapsed time, then a switch to x86 can make a lot of sense.
> Limiting that comparison to same sized "die" isn't a valid requirement in
> the eyes of most shareholders.
But sometimes raw CPU speed isn't everything. What about costs for
> The context I'm coming from is what I would expect most competitively minded
> businesses would be coming from. If your system can generate more profit by
> consuming less elapsed time, then a switch to x86 can make a lot of sense.
> Limiting that comparison to same sized "die" isn't a valid requirement in
> the eyes of most shareholders.
programmers and system managers? Maybe less with VMS. What about HBVS
and clustering for availability? What about Rdb? None of this is
available without VMS (though some might use the same non-trademarked
buzzwords).
IF you are looking at costs, you have to look at TOTAL costs.
Depending on the application, adding some nodes to the cluster can make
up for slower CPUs.
johnso...@gmail.com
Jun 3, 2012, 1:01:49 PM6/3/12
to
> But sometimes raw CPU speed isn't
> everything. What about costs for
> programmers and system managers?
> Maybe less with VMS.
I don't think x86 lowers the total cost of
> everything. What about costs for
> programmers and system managers?
> Maybe less with VMS.
ownership. But I don't think any acronym
has that power including VMS. Quality
people who understand the technology
pieces and the business problems do that.
I know adding nodes can sometimes enable
a system to go faster. But in my own experience
these situations were rare unless the CPUs
were really oversubscribed. Faster CPUs and
a faster memory subsystem (eg. Marvel)
were a bigger win way more often.
The performance gap between x86 and itanium
is going to be increasingly hard to ignore
if you manage a system that can generate more
value by consuming less elapsed time. If that
gap doesn't matter to you, then you have other
problems to contend with.
EJ
Michael Kraemer
Jun 3, 2012, 2:45:50 PM6/3/12
to
johnso...@gmail.com schrieb:
> In my experience, x86 was always faster. Usually in the range of 2x-4x faster.
> They were small programs that had a heavy CPU focus. They were home grown
> programs that would reflect the simplified notion of what the system was doing.
> I was trying to avoid anything that smelled of "SPEC" style benchmarks since
> many compilers are heavily optimized towards just those problems.
This is just rubbish, IMHO.
The SPEC suites are exactly made to avoid the cheating you suspect.
Do you honestly think you can do a better job?
Maybe you tell us what kind of fancy programs you have
used to ensure a fair comparison. Useless Dhrystone loops?
For commercial workloads both your tests as well as SPEC
aren't appropriate anyway, TPC would be more important.
> What I found interesting about the comparison is that I could never come up
> with a program that ran faster on Itanium. x86 *always* won.
Maybe you came up with the wrong programs?
Such which aren't interesting in the market into which
Itanics are sold?
> Perhaps hand written assembly could truly showcase what the chip was capable
> of.
You think hand coded assembly is representative for today's
commercial software development?
> In my experience, x86 was always faster. Usually in the range of 2x-4x faster.
> They were small programs that had a heavy CPU focus. They were home grown
> programs that would reflect the simplified notion of what the system was doing.
> I was trying to avoid anything that smelled of "SPEC" style benchmarks since
> many compilers are heavily optimized towards just those problems.
The SPEC suites are exactly made to avoid the cheating you suspect.
Do you honestly think you can do a better job?
Maybe you tell us what kind of fancy programs you have
used to ensure a fair comparison. Useless Dhrystone loops?
For commercial workloads both your tests as well as SPEC
aren't appropriate anyway, TPC would be more important.
> What I found interesting about the comparison is that I could never come up
> with a program that ran faster on Itanium. x86 *always* won.
Such which aren't interesting in the market into which
Itanics are sold?
> Perhaps hand written assembly could truly showcase what the chip was capable
> of.
commercial software development?
Michael Kraemer
Jun 3, 2012, 2:57:37 PM6/3/12
to
David Froble schrieb:
> It's rather simple. Competition will improve just about anything. Lack
> of competition promotes lack of effort. Intel is working as hard as
> they can to improve x86, because so is AMD. Intel and HP were
> successful in killing off an impressive competitor, the Alpha CPU
> design, and without much competition Intel has no overriding drive to
> improve IA-64.
>
> Personally, I think that federal regulators totally screwed up, but
> then, campaign contributions are so much more important than the good of
> the country, right?
Why aren't intel and AMD "good for the country"?
Both are US based companies, last time I checked.
> It's rather simple. Competition will improve just about anything. Lack
> of competition promotes lack of effort. Intel is working as hard as
> they can to improve x86, because so is AMD. Intel and HP were
> successful in killing off an impressive competitor, the Alpha CPU
> design, and without much competition Intel has no overriding drive to
> improve IA-64.
>
> Personally, I think that federal regulators totally screwed up, but
> then, campaign contributions are so much more important than the good of
> the country, right?
Both are US based companies, last time I checked.
JF Mezei
Jun 3, 2012, 4:04:41 PM6/3/12
to
David Froble wrote:
> Your testing is not appropriate, if you're looking to compare architectures, unless you're
> running both on the same process size. I don't remember the current process size for the
> itanic, but the latest x86 from Intel is down to 22 nm, and AMD is I believe at 35 nm.
The testing is appropriate. What counts is what is available on the
> Your testing is not appropriate, if you're looking to compare architectures, unless you're
> running both on the same process size. I don't remember the current process size for the
> itanic, but the latest x86 from Intel is down to 22 nm, and AMD is I believe at 35 nm.
market, now what "could" be available. And for a number of years, the
8076 has surpassed IA64's performance in what is available on the market.
The difference is that IA64 was included in larger "mainframe" systems
(aka superdomes) whereas the 8086 wasn't scaled as big.
But with the 8086 having the same memory interconnect, there is no
reason to not be abe to scale the 8086 to the same size and this is
exactly what HP is doing, by building 8086 based superdomes (project
Odyssey)
When HP bought Compaq, it should have ditched the yet unborn IA64 and
gove with the existing Alpha and put back the resourced to finish EV7 on
time.
Everyone knew IA64 was going to be a failure. I trust the dec engineers
who studied the design far mroe than HP's marketers . And the dec
engineers had compelling arguments on why IA64 wouldn't lead the industry.
Michael Kraemer
Jun 3, 2012, 4:05:22 PM6/3/12
to
ChrisQ schrieb:
> The sensible thing would have been to keep Alpha development running in
> parallel with Itanium until they were sure which one was the better, but
> i've given up expecting common sense from hp.
HP killed their own chip (which was way more viable than Alpha)
in favour of the Itanic, why should they care about the one
inherited from (and killed by) Compaq?
In fact the Alpha's fate was sealed by DEC themselves,
since the 1997's deal with intel involved the obligation
to endorse the Itanic, once it would be available,
see e.g.
http://www.wired.com/techbiz/media/news/1997/10/8024
DEC just didn't live long enough, and so it was Compaq's
turn to finally axe the Alpha.
> The sensible thing would have been to keep Alpha development running in
> parallel with Itanium until they were sure which one was the better, but
> i've given up expecting common sense from hp.
in favour of the Itanic, why should they care about the one
inherited from (and killed by) Compaq?
In fact the Alpha's fate was sealed by DEC themselves,
since the 1997's deal with intel involved the obligation
to endorse the Itanic, once it would be available,
see e.g.
http://www.wired.com/techbiz/media/news/1997/10/8024
DEC just didn't live long enough, and so it was Compaq's
turn to finally axe the Alpha.
JF Mezei
Jun 3, 2012, 4:06:54 PM6/3/12
to
Michael Kraemer wrote:
> The SPEC suites are exactly made to avoid the cheating you suspect.
Which is why HP didn't bother with SPEC evaluation of the current
> The SPEC suites are exactly made to avoid the cheating you suspect.
generation of IA64 since it would have confirmed IA64 has no advantage
over the lowly 8086.
Michael Kraemer
Jun 3, 2012, 4:24:01 PM6/3/12
to
JF Mezei schrieb:
market the Itanic is sold into.
Some years ago the SPEC numbers must have been
good enough to consider it for HPC.
> the current
> generation of IA64 since it would have confirmed IA64 has no advantage
> over the lowly 8086.
One would assume the IA64 will beat the 8086 hands down, as well as
the 80286, 80386, and 486 through 686.
> Michael Kraemer wrote:
>
>
>>The SPEC suites are exactly made to avoid the cheating you suspect.
>
>
> Which is why HP didn't bother with SPEC evaluation of
Or maybe SPEC isn't very relevant for the remaining
>
>
>>The SPEC suites are exactly made to avoid the cheating you suspect.
>
>
> Which is why HP didn't bother with SPEC evaluation of
market the Itanic is sold into.
Some years ago the SPEC numbers must have been
good enough to consider it for HPC.
> the current
> generation of IA64 since it would have confirmed IA64 has no advantage
> over the lowly 8086.
the 80286, 80386, and 486 through 686.
Dirk Munk
Jun 3, 2012, 4:37:05 PM6/3/12
to
Remember the Itanium was designed to replace the x86!
Also remember there was an Alpha roadmap up to EV12, and Alpha engineers
were touring universities etc. to explain how EV9 would be designed.
Jan-Erik Soderholm
Jun 3, 2012, 4:47:34 PM6/3/12
to
Michael Kraemer wrote 2012-06-03 22:24:
> JF Mezei schrieb:
>> Michael Kraemer wrote:
>>
>>
>>> The SPEC suites are exactly made to avoid the cheating you suspect.
>>
>>
>> Which is why HP didn't bother with SPEC evaluation of
>
> Or maybe SPEC isn't very relevant for the remaining
> market the Itanic is sold into.
As far as I know, IA64 beats any of the 8086 decendants,
> JF Mezei schrieb:
>> Michael Kraemer wrote:
>>
>>
>>> The SPEC suites are exactly made to avoid the cheating you suspect.
>>
>>
>> Which is why HP didn't bother with SPEC evaluation of
>
> Or maybe SPEC isn't very relevant for the remaining
> market the Itanic is sold into.
when running VMS. :-) That might be why SPEC's aren't *that*
rellevant in this day and time (and context). OpenVMS just
couldn't care less, so to speek. :-)
Alpha would probably been a better processor today with the
same ampount of resources put into it as have been put into
IA64. Some even says that Tru64 was better then HP-UX :-)
Jan-Erik.
Jan-Erik Soderholm
Jun 3, 2012, 5:03:18 PM6/3/12
to
Dirk Munk wrote 2012-06-03 22:37:
> Michael Kraemer wrote:
>> ChrisQ schrieb:
>>
>>> The sensible thing would have been to keep Alpha development running in
>>> parallel with Itanium until they were sure which one was the better, but
>>> i've given up expecting common sense from hp.
>>
>> HP killed their own chip (which was way more viable than Alpha)
>> in favour of the Itanic, why should they care about the one
>> inherited from (and killed by) Compaq?
>> In fact the Alpha's fate was sealed by DEC themselves,
>> since the 1997's deal with intel involved the obligation
>> to endorse the Itanic, once it would be available,
>> see e.g.
>>
>> http://www.wired.com/techbiz/media/news/1997/10/8024
>>
>> DEC just didn't live long enough, and so it was Compaq's
>> turn to finally axe the Alpha.
>>
>>
>
> The article does not say that DEC would use the IA64 to replace Alpha.
> Remember the Itanium was designed to replace the x86!
Wasn't HP originaly developing the EPIC architecture primarily to
> Michael Kraemer wrote:
>> ChrisQ schrieb:
>>
>>> The sensible thing would have been to keep Alpha development running in
>>> parallel with Itanium until they were sure which one was the better, but
>>> i've given up expecting common sense from hp.
>>
>> HP killed their own chip (which was way more viable than Alpha)
>> in favour of the Itanic, why should they care about the one
>> inherited from (and killed by) Compaq?
>> In fact the Alpha's fate was sealed by DEC themselves,
>> since the 1997's deal with intel involved the obligation
>> to endorse the Itanic, once it would be available,
>> see e.g.
>>
>> http://www.wired.com/techbiz/media/news/1997/10/8024
>>
>> DEC just didn't live long enough, and so it was Compaq's
>> turn to finally axe the Alpha.
>>
>>
>
> The article does not say that DEC would use the IA64 to replace Alpha.
> Remember the Itanium was designed to replace the x86!
replace the 32-bit PA-RISC processors ?
x86 and Alpha was later when Intel come into the picture, not ?
Jan-Erik.
Michael Kraemer
Jun 3, 2012, 5:35:43 PM6/3/12
to
Dirk Munk schrieb:
> The article does not say that DEC would use the IA64 to replace Alpha.
Of course DEC didn't say that explicitly (they still had ongoing
business), but it was the only logical outcome.
Considering that their VMS/DUNIX sales numbers already lagged
way behind the competition,
it wouldn't have made much sense to split that further.
> Remember the Itanium was designed to replace the x86!
It was meant to replace everything, not just the x86.
> Also remember there was an Alpha roadmap up to EV12, and Alpha engineers
> were touring universities etc. to explain how EV9 would be designed.
So what, roadmaps going farther than one or two generations aren't
worth the paper they're written on.
What was the current version in 1997, EV56?
So already EV9 was rather speculative and EV12 (six future generations)
appears to be sheer science fiction.
It costs (almost) nothing to talk about design,
so it doesn't mean much.
> The article does not say that DEC would use the IA64 to replace Alpha.
business), but it was the only logical outcome.
Considering that their VMS/DUNIX sales numbers already lagged
way behind the competition,
it wouldn't have made much sense to split that further.
> Remember the Itanium was designed to replace the x86!
> Also remember there was an Alpha roadmap up to EV12, and Alpha engineers
> were touring universities etc. to explain how EV9 would be designed.
worth the paper they're written on.
What was the current version in 1997, EV56?
So already EV9 was rather speculative and EV12 (six future generations)
appears to be sheer science fiction.
It costs (almost) nothing to talk about design,
so it doesn't mean much.
Michael Kraemer
Jun 3, 2012, 6:05:18 PM6/3/12
to
Jan-Erik Soderholm schrieb:
> Wasn't HP originaly developing the EPIC architecture primarily to
> replace the 32-bit PA-RISC processors ?
Originally it was an HP research project,
but at the time they teamed with intel,
PA business was still going strong, far from
needing a replacement. However, HP probably
realized that increasing costs and limited
sales would sooner or later get them.
IBM solved this problem by teaming up with
Motorola and expanding into the "embedded" market.
This left only intel as a potential partner,
but unfortunately intel didn't need a new chip
as desperately as HP needed a partner to share costs.
Probably at this point the idea came up to create
a new "universal" chip to replace all others,
otherwise intel might not have been interested.
> Wasn't HP originaly developing the EPIC architecture primarily to
> replace the 32-bit PA-RISC processors ?
but at the time they teamed with intel,
PA business was still going strong, far from
needing a replacement. However, HP probably
realized that increasing costs and limited
sales would sooner or later get them.
IBM solved this problem by teaming up with
Motorola and expanding into the "embedded" market.
This left only intel as a potential partner,
but unfortunately intel didn't need a new chip
as desperately as HP needed a partner to share costs.
Probably at this point the idea came up to create
a new "universal" chip to replace all others,
otherwise intel might not have been interested.
Dirk Munk
Jun 3, 2012, 6:07:49 PM6/3/12
to
before the Alphacide. As far as I know there were coarse design plans
for later generations of Alphas. If EV9 was already being designed, than
a roadmap to EV12 isn't that strange.
Dirk Munk
Jun 3, 2012, 6:11:39 PM6/3/12
to
because it became clear that the PA-Risc architecture would reach the
end of it's possibilities.
Dirk Munk
Jun 3, 2012, 6:19:14 PM6/3/12
to
Jan-Erik Soderholm wrote:
> Michael Kraemer wrote 2012-06-03 22:24:
>> JF Mezei schrieb:
>>> Michael Kraemer wrote:
>>>
>>>
>>>> The SPEC suites are exactly made to avoid the cheating you suspect.
>>>
>>>
>>> Which is why HP didn't bother with SPEC evaluation of
>>
>> Or maybe SPEC isn't very relevant for the remaining
>> market the Itanic is sold into.
>
> As far as I know, IA64 beats any of the 8086 decendants,
> when running VMS. :-) That might be why SPEC's aren't *that*
> rellevant in this day and time (and context). OpenVMS just
> couldn't care less, so to speek. :-)
>
> Alpha would probably been a better processor today with the
> same ampount of resources put into it as have been put into
> IA64. Some even says that Tru64 was better then HP-UX :-)
No doubt, Tru64 was better. HP-UX is a rather monolithic old fashioned
> Michael Kraemer wrote 2012-06-03 22:24:
>> JF Mezei schrieb:
>>> Michael Kraemer wrote:
>>>
>>>
>>>> The SPEC suites are exactly made to avoid the cheating you suspect.
>>>
>>>
>>> Which is why HP didn't bother with SPEC evaluation of
>>
>> Or maybe SPEC isn't very relevant for the remaining
>> market the Itanic is sold into.
>
> As far as I know, IA64 beats any of the 8086 decendants,
> when running VMS. :-) That might be why SPEC's aren't *that*
> rellevant in this day and time (and context). OpenVMS just
> couldn't care less, so to speek. :-)
>
> Alpha would probably been a better processor today with the
> same ampount of resources put into it as have been put into
> IA64. Some even says that Tru64 was better then HP-UX :-)
kind of Unix, Tru64 was designed as a 64 bit modern Unix from the start.
According to people who have experience with Hp-UX, Solaris, Tru64 and
Linux, Tru64 is the best.
Dirk Munk
Jun 3, 2012, 6:30:33 PM6/3/12
to
x86, and this architecture reaches the end of it's potential, then what?
If anything, the Itanic disaster showed us that.
Michael Kraemer
Jun 3, 2012, 6:54:31 PM6/3/12
to
Dirk Munk schrieb:
> Simple, "biodiversity' is also very important. If everyone is using the
> x86, and this architecture reaches the end of it's potential, then what?
So if "diversity" is so important,
why is everybody here (and elsewhere) so keen of
everything being ported to x86?
Why not just say "no" to x86, for the sake of diversity?
It's easy to blame "federal regulators", but essentially
it's the customer who decides what to buy.
> If anything, the Itanic disaster showed us that.
The Itanic is a minor detail.
> Simple, "biodiversity' is also very important. If everyone is using the
> x86, and this architecture reaches the end of it's potential, then what?
why is everybody here (and elsewhere) so keen of
everything being ported to x86?
Why not just say "no" to x86, for the sake of diversity?
It's easy to blame "federal regulators", but essentially
it's the customer who decides what to buy.
> If anything, the Itanic disaster showed us that.
Michael Kraemer
Jun 3, 2012, 7:04:46 PM6/3/12
to
Dirk Munk schrieb:
> No doubt, Tru64 was better.
Define "better".
> HP-UX is a rather monolithic old fashioned
> kind of Unix,
Kernelwise that may be true, but that wasn't unusual
among the Unices until the early 1990s,
with the possible exception of AIX.
OTOH, HP-UX had a very modern and fancy GUI (VUE, ancestor of CDE),
and this was a strong selling point back then.
> Tru64 was designed as a 64 bit modern Unix from the start.
I wouldn't subscribe. The versions until 3.x looked and felt
just like good old Ultrix. Only the later versions added more
modern features, but that was too late.
> According to people who have experience with Hp-UX, Solaris, Tru64 and
> Linux, Tru64 is the best.
Probably depends on where they started.
> No doubt, Tru64 was better.
> HP-UX is a rather monolithic old fashioned
> kind of Unix,
among the Unices until the early 1990s,
with the possible exception of AIX.
OTOH, HP-UX had a very modern and fancy GUI (VUE, ancestor of CDE),
and this was a strong selling point back then.
> Tru64 was designed as a 64 bit modern Unix from the start.
just like good old Ultrix. Only the later versions added more
modern features, but that was too late.
> According to people who have experience with Hp-UX, Solaris, Tru64 and
> Linux, Tru64 is the best.
Michael Kraemer
Jun 3, 2012, 7:17:14 PM6/3/12
to
Dirk Munk schrieb:
> No, Intel had already started developing the Itanium.
Not true. It started at HP (VLIW, EPIC).
> HP joined later
> because it became clear that the PA-Risc architecture would reach the
> end of it's possibilities.
The HP/intel joint (ad)venture started in 1994, about three years
after HP had introduced their very successful line of "Snake"
PA-RISC workstations/servers. They generated almost as much revenue
as DEC had with Alpha/Mips/VAX altogether.
So there was absolutely no "end of possibilities" in sight.
What HP was concerned about (and rightfully so),
was the increasing cost of CPU development.
> No, Intel had already started developing the Itanium.
> HP joined later
> because it became clear that the PA-Risc architecture would reach the
> end of it's possibilities.
after HP had introduced their very successful line of "Snake"
PA-RISC workstations/servers. They generated almost as much revenue
as DEC had with Alpha/Mips/VAX altogether.
So there was absolutely no "end of possibilities" in sight.
What HP was concerned about (and rightfully so),
was the increasing cost of CPU development.
Michael Kraemer
Jun 3, 2012, 7:40:57 PM6/3/12
to
Dirk Munk schrieb:
> The EV9 tour took place at the time that EV8 was almost ready,
This is a bold statement, since, iirc, it was even difficult to produce
its predecessor(s), EV7/EV7z. Everything beyond these didn't make
it in silicon, afaik.
> so just
> before the Alphacide. As far as I know there were coarse design plans
> for later generations of Alphas. If EV9 was already being designed, than
> a roadmap to EV12 isn't that strange.
Design on paper means (almost) nothing.
The difficult part is to produce the chips in silicon.
Only at this stage they are "ready".
Provided the associated costs didn't kill the company before.
> The EV9 tour took place at the time that EV8 was almost ready,
its predecessor(s), EV7/EV7z. Everything beyond these didn't make
it in silicon, afaik.
> so just
> before the Alphacide. As far as I know there were coarse design plans
> for later generations of Alphas. If EV9 was already being designed, than
> a roadmap to EV12 isn't that strange.
The difficult part is to produce the chips in silicon.
Only at this stage they are "ready".
Provided the associated costs didn't kill the company before.
johnso...@gmail.com
Jun 3, 2012, 7:49:13 PM6/3/12
to
On Sunday, June 3, 2012 2:45:50 PM UTC-4, Michael Kraemer wrote:
> The SPEC suites are exactly made to avoid the cheating you suspect.
That's good to hear.
> The SPEC suites are exactly made to avoid the cheating you suspect.
> Do you honestly think you can do a better job?
the essence of a system that I was familiar with. It wasn't intended to
be generic for everyone. But speaking about a performance gap between
itanium and x86 was in some ways easier with homemade benchmarks when
discussing possible impact on a business.
> Maybe you tell us what kind of fancy programs you have
> used to ensure a fair comparison.
For example, one piece of code I played with was a home grown compression
algorithm that was in frequent use. It originated on VAX, migrated to
Alpha and survived the journey onto Itanium. It wasn't particularly
brilliant, but it met the needs of the system at the time and it saw
heavy usage.
The same chunk of code when compiled on x86-64 performed considerably
faster. As I recall, it was at least 2x faster.
And no, the Itanium flavor was not hobbled by alignment faults.
There were others. They would typically center around doing a mix of
string manipulations, basic math, and small memory moves that would
superficially resemble the system I was familiar with. It didn't come
from the belief that I was smarter than SPEC, but just trying to
come up with something that resembled roughly what a given system did.
I also recall playing with a set of solutions to the same problem. An
inhouse training program culminated in the students writing a solution
to a word boggle like problem. The solutions used a variety of techniques
and ran in a range of times. Some were smart and fast. Others not so
much. They solved the same problem in a variety of ways.
So I grabbed a few and recompiled them on Itanium. They always
consumed more CPU time than their x86 counterpart. And I spent
a little bit of time inspecting them to be sure they weren't
abusing the C RTL in a way that made VMS unhappy.
> Maybe you came up with the wrong programs?
EJ
Michael Kraemer
Jun 3, 2012, 8:04:16 PM6/3/12
to
johnso...@gmail.com schrieb:
> They were far from fancy, but they weren't useless loops either.
>
> For example, one piece of code I played with was a home grown compression
> algorithm that was in frequent use. It originated on VAX, migrated to
> Alpha and survived the journey onto Itanium.
OK, I know this kind of fun stuff :-)
But it's a bit dangereous to compare entire architectures
solely based on such "anecdotal evidence".
You also didn't tell what kind of machines/OS/compilers
you used (comparing single chips isn't too meaningful).
> They were far from fancy, but they weren't useless loops either.
>
> For example, one piece of code I played with was a home grown compression
> algorithm that was in frequent use. It originated on VAX, migrated to
> Alpha and survived the journey onto Itanium.
But it's a bit dangereous to compare entire architectures
solely based on such "anecdotal evidence".
You also didn't tell what kind of machines/OS/compilers
you used (comparing single chips isn't too meaningful).
johnso...@gmail.com
Jun 3, 2012, 8:53:16 PM6/3/12
to
On Sunday, June 3, 2012 8:04:16 PM UTC-4, Michael Kraemer wrote:
> OK, I know this kind of fun stuff :-)
> But it's a bit dangereous to compare entire architectures
> solely based on such "anecdotal evidence".
It can be dangerous, but I found it interesting that every time
> OK, I know this kind of fun stuff :-)
> But it's a bit dangereous to compare entire architectures
> solely based on such "anecdotal evidence".
I went to grab something contrived either written by myself
or someone else, the situation for Itanium was grim.
> You also didn't tell what kind of machines/OS/compilers
> you used (comparing single chips isn't too meaningful).
OpenVMS v8.4 on Tukwila. The Tukwila box was, I believe, a two
seater with four or 8 cores for each cpu. I believe it was the
9340.
The x86 side was just prior to the Westmere generation, but the
exact model escapes me now. 2.8 GHz range. Compiler was gcc
4.3 or a little later I believe. But I also recall specifically
playing with a Nehalem generation x86 chip just because that was
addressing the weakest part of Intel's x86 offering.
I'm sorry I can't be more precise as I no longer have access to
those systems.
I can appreciate the dangers of looking at a system through
just a handful of simple lenses, but I think that some of you
may not be aware of just how much the x86 world has charged ahead.
I also have a hard time believing that Itanium is so far ahead of the
x86 curve that its anemic pace of evolution still leaves it ahead.
EJ
Jan-Erik Soderholm
Jun 4, 2012, 3:06:49 AM6/4/12
to
"The architecture originated at Hewlett-Packard (HP), and was
later jointly developed by HP and Intel."
"In *1989*, HP determined that reduced instruction set computer (RISC)
architectures were approaching a processing limit at one instruction
per cycle. HP researchers investigated a new architecture, later named
explicitly parallel instruction computing (EPIC), that allows the
processor to execute multiple instructions in each clock cycle."
"HP believed that it was no longer cost-effective for individual
enterprise systems companies such as itself to develop proprietary
microprocessors, so it partnered with Intel in *1994* to develop the
IA-64 architecture, derived from EPIC."
I read that the other way around.
Jan-Erik.
Michael Kraemer
Jun 4, 2012, 3:21:53 AM6/4/12
to
johnso...@gmail.com schrieb:
is less than stellar. However, if you run only
workstation class programs you might not measure
what a typical Itanic customer is interested in,
i.e. throughput of commercial workloads.
And sure Itanic is unbeatable when it comes
to the ability to run HP-UX or VMS software.
Unless, of course, you're waiting for x86
to provide an emulated VMS/Alpha environment faster than
the native Itanic one.
> On Sunday, June 3, 2012 8:04:16 PM UTC-4, Michael Kraemer wrote:
>
>
>>OK, I know this kind of fun stuff :-)
>>But it's a bit dangereous to compare entire architectures
>>solely based on such "anecdotal evidence".
>
>
> It can be dangerous, but I found it interesting that every time
> I went to grab something contrived either written by myself
> or someone else, the situation for Itanium was grim.
Well, it's an open secret that Itanic's raw performance
>
>
>>OK, I know this kind of fun stuff :-)
>>But it's a bit dangereous to compare entire architectures
>>solely based on such "anecdotal evidence".
>
>
> It can be dangerous, but I found it interesting that every time
> I went to grab something contrived either written by myself
> or someone else, the situation for Itanium was grim.
is less than stellar. However, if you run only
workstation class programs you might not measure
what a typical Itanic customer is interested in,
i.e. throughput of commercial workloads.
And sure Itanic is unbeatable when it comes
to the ability to run HP-UX or VMS software.
Unless, of course, you're waiting for x86
to provide an emulated VMS/Alpha environment faster than
the native Itanic one.
Dirk Munk
Jun 4, 2012, 3:44:27 AM6/4/12
to
Michael Kraemer wrote:
> Dirk Munk schrieb:
>
>> Simple, "biodiversity' is also very important. If everyone is using
>> the x86, and this architecture reaches the end of it's potential, then
>> what?
>
> So if "diversity" is so important,
> why is everybody here (and elsewhere) so keen of
> everything being ported to x86?
> Why not just say "no" to x86, for the sake of diversity?
That might be wise in certain cases. But managers seldom have a vision
> Dirk Munk schrieb:
>
>> Simple, "biodiversity' is also very important. If everyone is using
>> the x86, and this architecture reaches the end of it's potential, then
>> what?
>
> So if "diversity" is so important,
> why is everybody here (and elsewhere) so keen of
> everything being ported to x86?
> Why not just say "no" to x86, for the sake of diversity?
that extends beyond the next quarterly financial figurers. For them
there is no difference between a computer and a coffee machine.
Dirk Munk
Jun 4, 2012, 3:45:02 AM6/4/12
to
Dirk Munk
Jun 4, 2012, 4:22:43 AM6/4/12
to
Michael Kraemer wrote:
> Dirk Munk schrieb:
>
>> The EV9 tour took place at the time that EV8 was almost ready,
>
> This is a bold statement, since, iirc, it was even difficult to produce
> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
> it in silicon, afaik.
The EV8 was scheduled for 2003, and was in a very late state of
> Dirk Munk schrieb:
>
>> The EV9 tour took place at the time that EV8 was almost ready,
>
> This is a bold statement, since, iirc, it was even difficult to produce
> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
> it in silicon, afaik.
development when the Alphacide took place. EV7z came later when the
EV78/79 was cancelled.
>
>> so just before the Alphacide. As far as I know there were coarse
>> design plans for later generations of Alphas. If EV9 was already being
>> designed, than a roadmap to EV12 isn't that strange.
>
> Design on paper means (almost) nothing.
> The difficult part is to produce the chips in silicon.
> Only at this stage they are "ready".
> Provided the associated costs didn't kill the company before.
>
the idea to put the memory controller in the cpu, to integrate fast
network controllers in the cpu for very fast inter cpu communication.
Today we see these things on many cpus including x86, but they were the
first. They had an idea, a vision.
glen herrmannsfeldt
Jun 4, 2012, 5:38:18 AM6/4/12
to
(snip)
> The goal wasn't to be smarter than SPEC, but to try to better capture
> the essence of a system that I was familiar with. It wasn't intended to
> be generic for everyone. But speaking about a performance gap between
> itanium and x86 was in some ways easier with homemade benchmarks when
> discussing possible impact on a business.
>> Maybe you tell us what kind of fancy programs you have
>> used to ensure a fair comparison.
> They were far from fancy, but they weren't useless loops either.
> For example, one piece of code I played with was a home grown compression
> algorithm that was in frequent use. It originated on VAX, migrated to
> Alpha and survived the journey onto Itanium. It wasn't particularly
> brilliant, but it met the needs of the system at the time and it saw
> heavy usage.
In some tests, it seems to me that IA32 is much faster for
character (byte) operations than comparable processors.
Many, especially with a scientific computing goal, are optimized
for double precision floating point, but slow for byte moving.
> The same chunk of code when compiled on x86-64 performed considerably
> faster. As I recall, it was at least 2x faster.
> And no, the Itanium flavor was not hobbled by alignment faults.
-- glen
> The goal wasn't to be smarter than SPEC, but to try to better capture
> the essence of a system that I was familiar with. It wasn't intended to
> be generic for everyone. But speaking about a performance gap between
> itanium and x86 was in some ways easier with homemade benchmarks when
> discussing possible impact on a business.
>> Maybe you tell us what kind of fancy programs you have
>> used to ensure a fair comparison.
> They were far from fancy, but they weren't useless loops either.
> For example, one piece of code I played with was a home grown compression
> algorithm that was in frequent use. It originated on VAX, migrated to
> Alpha and survived the journey onto Itanium. It wasn't particularly
> brilliant, but it met the needs of the system at the time and it saw
> heavy usage.
character (byte) operations than comparable processors.
Many, especially with a scientific computing goal, are optimized
for double precision floating point, but slow for byte moving.
> The same chunk of code when compiled on x86-64 performed considerably
> faster. As I recall, it was at least 2x faster.
> And no, the Itanium flavor was not hobbled by alignment faults.
Nomen Nescio
Jun 4, 2012, 6:15:16 AM6/4/12
to
Michael Kraemer <M.Kr...@gsi.de> wrote:
> johnso...@gmail.com schrieb:
>
> > In my experience, x86 was always faster. Usually in the range of 2x-4x faster.
> > They were small programs that had a heavy CPU focus. They were home grown
> > programs that would reflect the simplified notion of what the system was doing.
> > I was trying to avoid anything that smelled of "SPEC" style benchmarks since
> > many compilers are heavily optimized towards just those problems.
>
> This is just rubbish, IMHO.
> For commercial workloads both your tests as well as SPEC
> aren't appropriate anyway, TPC would be more important.
>
> > What I found interesting about the comparison is that I could never come up
> > with a program that ran faster on Itanium. x86 *always* won.
> Itanics are sold?
>
> > Perhaps hand written assembly could truly showcase what the chip was capable
> > of.
>
> You think hand coded assembly is representative for today's
> commercial software development?
Depends on what platform you're asking about.
In the IBM mainframe world, yes, it is representative.
I'm always amazed that VMS guys who should know better think all the world's
a PC and everybody runs Windows or UNIX...
> johnso...@gmail.com schrieb:
>
> > In my experience, x86 was always faster. Usually in the range of 2x-4x faster.
> > They were small programs that had a heavy CPU focus. They were home grown
> > programs that would reflect the simplified notion of what the system was doing.
> > I was trying to avoid anything that smelled of "SPEC" style benchmarks since
> > many compilers are heavily optimized towards just those problems.
>
> This is just rubbish, IMHO.
> The SPEC suites are exactly made to avoid the cheating you suspect.
> Do you honestly think you can do a better job?
> Maybe you tell us what kind of fancy programs you have
> used to ensure a fair comparison. Useless Dhrystone loops?
> For commercial workloads both your tests as well as SPEC
> aren't appropriate anyway, TPC would be more important.
>
> > What I found interesting about the comparison is that I could never come up
> > with a program that ran faster on Itanium. x86 *always* won.
>
> Maybe you came up with the wrong programs?
> Such which aren't interesting in the market into which
> Maybe you came up with the wrong programs?
> Itanics are sold?
>
> > Perhaps hand written assembly could truly showcase what the chip was capable
> > of.
>
> You think hand coded assembly is representative for today's
> commercial software development?
Depends on what platform you're asking about.
In the IBM mainframe world, yes, it is representative.
I'm always amazed that VMS guys who should know better think all the world's
a PC and everybody runs Windows or UNIX...
Michael Kraemer
Jun 4, 2012, 6:22:50 AM6/4/12
to
In article <49b493ef11be23ed...@dizum.com>, Nomen Nescio
but almost certainly not on the app level.
Or are you telling me that stuff like Oracle DB or SAP R/2
are entirely coded in 370 assembly?
> I'm always amazed that VMS guys who should know better think all the world's
> a PC and everybody runs Windows or UNIX...
I'm amazed you think that I'm a VMS guy or that I'm running a PC.
<nob...@dizum.com> writes:
> Depends on what platform you're asking about.
>
> In the IBM mainframe world, yes, it is representative.
On the system programmer's level, maybe (still),
> Depends on what platform you're asking about.
>
> In the IBM mainframe world, yes, it is representative.
but almost certainly not on the app level.
Or are you telling me that stuff like Oracle DB or SAP R/2
are entirely coded in 370 assembly?
> I'm always amazed that VMS guys who should know better think all the world's
> a PC and everybody runs Windows or UNIX...
Nomen Nescio
Jun 4, 2012, 6:46:02 AM6/4/12
to
Michael Kraemer <M.Kr...@gsi.de> wrote:
> Dirk Munk schrieb:
>
> > Simple, "biodiversity' is also very important. If everyone is using the
> > x86, and this architecture reaches the end of it's potential, then what?
blah blah blah. cry us a river.
> Dirk Munk schrieb:
>
> > Simple, "biodiversity' is also very important. If everyone is using the
> > x86, and this architecture reaches the end of it's potential, then what?
> So if "diversity" is so important,
> why is everybody here (and elsewhere) so keen of
> everything being ported to x86?
> Why not just say "no" to x86, for the sake of diversity?
Intel is garbage.
Fast, cheap, good. Pick 2! Pick Intel...
> It's easy to blame "federal regulators", but essentially
> it's the customer who decides what to buy.
allowed to buy.
Michael Kraemer
Jun 4, 2012, 7:22:53 AM6/4/12
to
In article <602decf0e09903d2...@dizum.com>, Nomen Nescio
<nob...@dizum.com> writes:
>
> > It's easy to blame "federal regulators", but essentially
> > it's the customer who decides what to buy.
>
> No, it's not. It's up to the marketers and the government what people are
> allowed to buy.
It's new to me that somebody has disallowed to buy Power or Sparc based servers
rather than x86.
I also didn't know that the government had forbidden to buy PA-RISC or Alpha
boxes, back then when both still existed.
The customers prefer(red) x86 over the alternatives, it seems.
<nob...@dizum.com> writes:
> Michael Kraemer <M.Kr...@gsi.de> wrote:
>
>
> > So if "diversity" is so important,
> > why is everybody here (and elsewhere) so keen of
> > everything being ported to x86?
>
> We're not.
Who is "we"? Obviously not c.o.v.
>
>
> > So if "diversity" is so important,
> > why is everybody here (and elsewhere) so keen of
> > everything being ported to x86?
>
> We're not.
>
> > It's easy to blame "federal regulators", but essentially
> > it's the customer who decides what to buy.
>
> No, it's not. It's up to the marketers and the government what people are
> allowed to buy.
rather than x86.
I also didn't know that the government had forbidden to buy PA-RISC or Alpha
boxes, back then when both still existed.
The customers prefer(red) x86 over the alternatives, it seems.
MG
Jun 4, 2012, 7:29:38 AM6/4/12
to
On 4-6-2012 12:22, Michael Kraemer wrote:
> I'm amazed you think that I'm a VMS guy [...]
That equally amazes me, that anyone could mistake you for that!
- MG
> I'm amazed you think that I'm a VMS guy [...]
That equally amazes me, that anyone could mistake you for that!
- MG
David Froble
Jun 4, 2012, 9:20:16 AM6/4/12
to
johnso...@gmail.com wrote:
>> But sometimes raw CPU speed isn't
>> everything. What about costs for
>> programmers and system managers?
>> Maybe less with VMS.
>
> I don't think x86 lowers the total cost of
> ownership. But I don't think any acronym
> has that power including VMS. Quality
> people who understand the technology
> pieces and the business problems do that.
>
> I know adding nodes can sometimes enable
> a system to go faster. But in my own experience
> these situations were rare unless the CPUs
> were really oversubscribed. Faster CPUs and
> a faster memory subsystem (eg. Marvel)
> were a bigger win way more often.
>
> The performance gap between x86 and itanium
> is going to be increasingly hard to ignore
> if you manage a system that can generate more
> value by consuming less elapsed time. If that
> gap doesn't matter to you, then you have other
> problems to contend with.
>
> EJ
Does the hardware really matter?
Is it the hardware, or your applications, that provide the needed capabilities for your
business?
If your applications can run on either platform, or if you use generic applications such
that it's not a problem to switch from a VMS based application to an application that will
run on x86, then sure, the hardware can be a bigger piece of any decisions.
But what if you have custom applications that run only on VMS? What if there is
significant value in the applications? In such a case, does the hardware really matter?
>> But sometimes raw CPU speed isn't
>> everything. What about costs for
>> programmers and system managers?
>> Maybe less with VMS.
>
> I don't think x86 lowers the total cost of
> ownership. But I don't think any acronym
> has that power including VMS. Quality
> people who understand the technology
> pieces and the business problems do that.
>
> I know adding nodes can sometimes enable
> a system to go faster. But in my own experience
> these situations were rare unless the CPUs
> were really oversubscribed. Faster CPUs and
> a faster memory subsystem (eg. Marvel)
> were a bigger win way more often.
>
> The performance gap between x86 and itanium
> is going to be increasingly hard to ignore
> if you manage a system that can generate more
> value by consuming less elapsed time. If that
> gap doesn't matter to you, then you have other
> problems to contend with.
>
> EJ
Does the hardware really matter?
Is it the hardware, or your applications, that provide the needed capabilities for your
business?
If your applications can run on either platform, or if you use generic applications such
that it's not a problem to switch from a VMS based application to an application that will
run on x86, then sure, the hardware can be a bigger piece of any decisions.
But what if you have custom applications that run only on VMS? What if there is
significant value in the applications? In such a case, does the hardware really matter?
Bob Koehler
Jun 4, 2012, 9:21:41 AM6/4/12
to
In article <edef7$4fcbe589$5ed43c14$28...@cache1.tilbu1.nb.home.nl>, Dirk Munk <mu...@home.nl> writes:
>
> Simple, "biodiversity' is also very important. If everyone is using the
> x86, and this architecture reaches the end of it's potential, then what?
> If anything, the Itanic disaster showed us that.
The Windows really moves to something else and everyone follows.
>
> Simple, "biodiversity' is also very important. If everyone is using the
> x86, and this architecture reaches the end of it's potential, then what?
> If anything, the Itanic disaster showed us that.
John Reagan
Jun 4, 2012, 9:38:19 AM6/4/12
to
"Michael Kraemer" wrote in message news:jqgqie$f8q$1...@solani.org...
>> HP-UX is a rather monolithic old fashioned kind of Unix,
>Kernelwise that may be true, but that wasn't unusual
>among the Unices until the early 1990s,
kernel modules) for over 10 years.
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01943990/c01943990.pdf?jumpid=reg_R1002_USEN
The HP-UX kernel isn't the monolith that you suggest.
David Froble
Jun 4, 2012, 9:42:51 AM6/4/12
to
others won't be able to see any difference between you two ....
I probably devote more time to c.o.v than I should, and I'm a VMS person. I got to wonder
why some non-VMS person is here spreading so much false information ....
MG
Jun 4, 2012, 10:26:07 AM6/4/12
to
On 4-6-2012 15:42, David Froble wrote:
> I probably devote more time to c.o.v than I should, and I'm a VMS
> person. I got to wonder why some non-VMS person is here spreading so
> much false information ....
Unemployed, bored, frustrated or a combination of the aforementioned?
> I probably devote more time to c.o.v than I should, and I'm a VMS
> person. I got to wonder why some non-VMS person is here spreading so
> much false information ....
You should see the times when he posts.
- MG
Richard B. Gilbert
Jun 4, 2012, 11:32:46 AM6/4/12
to
On 6/3/2012 6:11 PM, Dirk Munk wrote:
> Michael Kraemer wrote:
> Michael Kraemer wrote:
>> Jan-Erik Soderholm schrieb:
>>
>>> Wasn't HP originaly developing the EPIC architecture primarily to
>>> replace the 32-bit PA-RISC processors ?
>>
>> Originally it was an HP research project,
>> but at the time they teamed with intel,
>> PA business was still going strong, far from
>> needing a replacement. However, HP probably
>> realized that increasing costs and limited
>> sales would sooner or later get them.
>> IBM solved this problem by teaming up with
>> Motorola and expanding into the "embedded" market.
>> This left only intel as a potential partner,
>> but unfortunately intel didn't need a new chip
>> as desperately as HP needed a partner to share costs.
>> Probably at this point the idea came up to create
>> a new "universal" chip to replace all others,
>> otherwise intel might not have been interested.
>>
>
> No, Intel had already started developing the Itanium. HP joined later
> because it became clear that the PA-Risc architecture would reach the
>>
>>> Wasn't HP originaly developing the EPIC architecture primarily to
>>> replace the 32-bit PA-RISC processors ?
>>
>> Originally it was an HP research project,
>> but at the time they teamed with intel,
>> PA business was still going strong, far from
>> needing a replacement. However, HP probably
>> realized that increasing costs and limited
>> sales would sooner or later get them.
>> IBM solved this problem by teaming up with
>> Motorola and expanding into the "embedded" market.
>> This left only intel as a potential partner,
>> but unfortunately intel didn't need a new chip
>> as desperately as HP needed a partner to share costs.
>> Probably at this point the idea came up to create
>> a new "universal" chip to replace all others,
>> otherwise intel might not have been interested.
>>
>
> No, Intel had already started developing the Itanium. HP joined later
> end of it's possibilities.
It seems to me that you could say that about *any* architecture!
Dirk Munk
Jun 4, 2012, 11:34:18 AM6/4/12
to
John Wallace
Jun 4, 2012, 11:41:55 AM6/4/12
to
On Jun 4, 2:20 pm, David Froble <da...@tsoft-inc.com> wrote:
The hardware matters, but IA64 mostly matters in a negative/purchase-
obstructing kind of way.
x86 is basically acceptable everywhere - software developers,
resellers, IT departments, end users, boards of management. there
aren't many where x86 doesn't fit. Suggesting x86 is very rarely a
direct route to losing a project, UNLESS the project is one of the
remaining few where native VMS is a non-negotiable requirement, or the
project is one of the tiny number where ultra-massive SMP is a non
negotiable requirement and AMD64 systems don't currently offer quite
the same memory capacity or number of processors in an SMP box as
today's biggest IA64 boxes (but I haven't checked for a few months so
even that may be out of date).
Suggesting IA64, on the other hand, is a recipe for hours of fun,
trying to get *everyone* in the picture convinced that because VMS is
required, so is IA64. That discussion wouldn't be needed if VMS was
available native on run of the mill x86 boxes.
Suggesting IBM/Power is probably a bit awkward too, but it's IBM,
whose enterprise credibility is generally a bit better than HP's.
Of course if VMS was available on a selection of VMS-qualified but
otherwise run of the mill x86 boxes, there'd be an interesting pricing
question to address, just as there was back in the days of blue box/
white box Alpha systems.
That question would also have arisen with IA64 systems if IA64 had
ever turned into "industry standard 64 bit". But it didn't.
obstructing kind of way.
x86 is basically acceptable everywhere - software developers,
resellers, IT departments, end users, boards of management. there
aren't many where x86 doesn't fit. Suggesting x86 is very rarely a
direct route to losing a project, UNLESS the project is one of the
remaining few where native VMS is a non-negotiable requirement, or the
project is one of the tiny number where ultra-massive SMP is a non
negotiable requirement and AMD64 systems don't currently offer quite
the same memory capacity or number of processors in an SMP box as
today's biggest IA64 boxes (but I haven't checked for a few months so
even that may be out of date).
Suggesting IA64, on the other hand, is a recipe for hours of fun,
trying to get *everyone* in the picture convinced that because VMS is
required, so is IA64. That discussion wouldn't be needed if VMS was
available native on run of the mill x86 boxes.
Suggesting IBM/Power is probably a bit awkward too, but it's IBM,
whose enterprise credibility is generally a bit better than HP's.
Of course if VMS was available on a selection of VMS-qualified but
otherwise run of the mill x86 boxes, there'd be an interesting pricing
question to address, just as there was back in the days of blue box/
white box Alpha systems.
That question would also have arisen with IA64 systems if IA64 had
ever turned into "industry standard 64 bit". But it didn't.
Richard B. Gilbert
Jun 4, 2012, 12:04:24 PM6/4/12
to
Cards! And the VAX 11/780! Not to mention the 11/750.
Keith Parris
Jun 4, 2012, 5:13:50 PM6/4/12
to
On 6/3/2012 8:23 AM, David Froble wrote:
> When asked what was more important for speed, architecture or process
> size, one of the Alpha chip designers answered that process size is more
> important.
It will be interesting to see the effect of this in Poulson, which
skipped the 45 nm process and went directly to 32 nm (and has 8 cores
also). Tukwila was in a 65 nm process (with 4 cores).
Kittson should appear in 22 nm.
> When asked what was more important for speed, architecture or process
> size, one of the Alpha chip designers answered that process size is more
> important.
It will be interesting to see the effect of this in Poulson, which
skipped the 45 nm process and went directly to 32 nm (and has 8 cores
also). Tukwila was in a 65 nm process (with 4 cores).
Kittson should appear in 22 nm.
Richard B. Gilbert
Jun 4, 2012, 7:02:45 PM6/4/12
to
On 6/4/2012 6:15 AM, Nomen Nescio wrote:
some Automatic Teller Machines? Makes my blood run cold! Someday, some
bank is going to get screwed! BIG TIME!!!!!!
FrankS
Jun 4, 2012, 8:05:36 PM6/4/12
to M.Kr...@gsi.de
On Monday, June 4, 2012 6:22:50 AM UTC-4, Michael Kraemer wrote:
> On the system programmer's level, maybe (still),
> but almost certainly not on the app level.
Back in March, or so, I bumped into an old acquaintance in Pennsylvania. He's working for some PA State agency, and said he writes IBM S/370 Assembly language all day to maintain and enhance an accounts payable system. Or some general business type applications -- I can't remember the details.
> On the system programmer's level, maybe (still),
> but almost certainly not on the app level.
So, yeah, there's at least one general purpose application out there still being coded in Assembly.
FrankS
Jun 4, 2012, 8:11:19 PM6/4/12
to
On Monday, June 4, 2012 11:41:55 AM UTC-4, John Wallace wrote:
> Of course if VMS was available on a selection of VMS-qualified but
> otherwise run of the mill x86 boxes, there'd be an interesting pricing
> question to address, just as there was back in the days of blue box/
> white box Alpha systems.
Not just that, but once it gets the "x86 Inside" sticker on the box, then there'd be an expectation that one could go out and buy any x86 box and getting OpenVMS running on it, or use any PCI adapters too. In order to keep the hardware spend down in x86 territory I'm sure lots of sites would ignore the "OpenVMS qualified" requirement and would consider doing their shopping at Best Buy.
> Of course if VMS was available on a selection of VMS-qualified but
> otherwise run of the mill x86 boxes, there'd be an interesting pricing
> question to address, just as there was back in the days of blue box/
> white box Alpha systems.
David Froble
Jun 4, 2012, 11:33:16 PM6/4/12
to
publicity if they publically admitted being hacked ...
When you try to warn Microsoft bigots, they reply, "but everyone is using it".
MG
Jun 5, 2012, 3:56:22 AM6/5/12
to
On 5-6-2012 5:33, David Froble wrote:
it. The problem though, if banks fall we tend to get these "bail outs"
and that's hardly just 'their problem'...
Wasn't there at least one person here on comp.os.vms, in the recent
months, who was ridiculed by the usual suspects when he pointed out
that the increased (possible) loss of VMS could very well end up to
be literally 'disasterous'? One could say that greediness, saving
a buck on disaster tolerant hardware and software is going to make
the IT/ICT infrastructure less disaster-tolerant, to even use HP's
jargon.
- MG
> Richard B. Gilbert wrote:
>> Nearly everybody DOES run Windows! Did you know that Windows is used
>> in some Automatic Teller Machines? Makes my blood run cold! Someday,
>> some bank is going to get screwed! BIG TIME!!!!!!
>
> What makes you think it hasn't already happened? Banks would not like
> the negative publicity if they publically admitted being hacked ...
>
> When you try to warn Microsoft bigots, they reply, "but everyone is
> using it".
You, both of you, beat me to it. You know what? Maybe they 'deserve'
>> Nearly everybody DOES run Windows! Did you know that Windows is used
>> in some Automatic Teller Machines? Makes my blood run cold! Someday,
>> some bank is going to get screwed! BIG TIME!!!!!!
>
> What makes you think it hasn't already happened? Banks would not like
> the negative publicity if they publically admitted being hacked ...
>
> When you try to warn Microsoft bigots, they reply, "but everyone is
> using it".
it. The problem though, if banks fall we tend to get these "bail outs"
and that's hardly just 'their problem'...
Wasn't there at least one person here on comp.os.vms, in the recent
months, who was ridiculed by the usual suspects when he pointed out
that the increased (possible) loss of VMS could very well end up to
be literally 'disasterous'? One could say that greediness, saving
a buck on disaster tolerant hardware and software is going to make
the IT/ICT infrastructure less disaster-tolerant, to even use HP's
jargon.
- MG
Paul Sture
Jun 5, 2012, 5:03:26 AM6/5/12
to
On Mon, 04 Jun 2012 00:54:31 +0200, Michael Kraemer wrote:
> Dirk Munk schrieb:
>
> Dirk Munk schrieb:
>
>> Simple, "biodiversity' is also very important. If everyone is using the
>> x86, and this architecture reaches the end of it's potential, then
>> what?
>
> So if "diversity" is so important,
> why is everybody here (and elsewhere) so keen of everything being ported
> to x86?
> Why not just say "no" to x86, for the sake of diversity? It's easy to
> So if "diversity" is so important,
> why is everybody here (and elsewhere) so keen of everything being ported
> to x86?
> blame "federal regulators", but essentially it's the customer who
> decides what to buy.
Don't you remember "Curly" Capellas saying something like "too much
> decides what to buy.
choice confuses the customer"?
--
Paul Sture
Paul Sture
Jun 5, 2012, 5:13:04 AM6/5/12
to
profile project fail because the supplier went the Best Buy route.
--
Paul Sture
MG
Jun 5, 2012, 5:17:51 AM6/5/12
to
On 5-6-2012 11:03, Paul Sture wrote:
> Don't you remember "Curly" Capellas saying something like "too much
> choice confuses the customer"?
There's a mild bit of truth in that... that is, for those who are
> Don't you remember "Curly" Capellas saying something like "too much
> choice confuses the customer"?
greedy and who don't know anything about what they're supposed to
be the least bit knowledgeable about (read: typical 'managers' and
the other equally yacht-aspiring 'company men' who decide on the
IT/ICT infrastructure and who'd rather switch to Windows or Linux).
- MG
Michael Kraemer
Jun 5, 2012, 5:52:30 AM6/5/12
to
In article <uju0a9-...@mint-hp.chingola.ch>, Paul Sture
seriously what this guys says.
<paul....@sture.ch> writes:
> Don't you remember "Curly" Capellas saying something like "too much
> choice confuses the customer"?
well, I always thought it's common understanding here not to take too
> Don't you remember "Curly" Capellas saying something like "too much
> choice confuses the customer"?
seriously what this guys says.
Michael Kraemer
Jun 5, 2012, 6:14:46 AM6/5/12
to
In article <7057ee66-3dcc-4c31...@googlegroups.com>, FrankS
> e's working for some PA State agency, and said he writes IBM S/370 Assembly=
> language all day to maintain and enhance an accounts payable system. Or s=
> being coded in Assembly.
Well, if you dig long and deep enough you'll always find one or two weird
exceptions to the rule.
But unless you tell me otherwise,
I suspect this to be a "legacy" app from the 1980s or earlier,
which necessarily has to be maintained in assembly because nobody
has the resources to convert or rewrite in some HLL.
I was referring more to apps developed in the past two decades
and I would be surprised if significant parts of such new apps are
still coded in "z" assembly. There are a few HL languages available
(Cobol, PL/I, possibly even C/C++) which should make software development
much more efficient.
<sapi...@noesys.com> writes:
> On Monday, June 4, 2012 6:22:50 AM UTC-4, Michael Kraemer wrote:
> > On the system programmer's level, maybe (still),
> > but almost certainly not on the app level.
>
> Back in March, or so, I bumped into an old acquaintance in Pennsylvania. H=
> On Monday, June 4, 2012 6:22:50 AM UTC-4, Michael Kraemer wrote:
> > On the system programmer's level, maybe (still),
> > but almost certainly not on the app level.
>
> e's working for some PA State agency, and said he writes IBM S/370 Assembly=
> language all day to maintain and enhance an accounts payable system. Or s=
> ome general business type applications -- I can't remember the details.
>
> So, yeah, there's at least one general purpose application out there still =
>
> being coded in Assembly.
Well, if you dig long and deep enough you'll always find one or two weird
exceptions to the rule.
But unless you tell me otherwise,
I suspect this to be a "legacy" app from the 1980s or earlier,
which necessarily has to be maintained in assembly because nobody
has the resources to convert or rewrite in some HLL.
I was referring more to apps developed in the past two decades
and I would be surprised if significant parts of such new apps are
still coded in "z" assembly. There are a few HL languages available
(Cobol, PL/I, possibly even C/C++) which should make software development
much more efficient.
Nomen Nescio
Jun 5, 2012, 10:25:40 AM6/5/12
to
applications) I agree assembler is not a good choice for writing apps even
on IBM. COBOL is the most popular and there is even Java! And the other
languages you mentioned all have their uses too. The applications written in
assembler are all from the 1960s, 70s, etc. and still in use and need people
to work on them. In PA it's probably the IRS or FICA that still has apps in
assembler. You still see adds for programmers to work on their stuff.
John Wallace
Jun 5, 2012, 11:06:02 AM6/5/12
to
"it works on [...]" and "it is supported on [...]".
The traditional Wintel world (end users, IT departments, resellers,
etc) largely has no historic understanding of what "support" really
means, and therefore the distinction between supported and unsupported
is currently irrelevant to them. A PC is a PC, an x86 server is an x86
server [Maybe I exaggerate a little bit, but not much]. Might be nice
if they had an opportunity to see what "support" actually means, no?
Who remembers Windows Datacentre Edition, where the hardware vendor
was supposed to provide specifically qualified hardware and dedicated
frontline support? And the cost was (is?) thousands of dollars per
processor?
Could VMS justify Datacenter Edition style of pricing for the server
side of things (maybe a little bit more, and a LOT less for
development licences, MSDN style)? Could it ever be profitable enough
to keep VMS going?
Michael Kraemer
Jun 6, 2012, 3:23:56 AM6/6/12
to
Dirk Munk schrieb:
http://alasir.com/articles/alpha_history/alpha_21364_21464.html
(a site positively biased towards the Alpha, so you can't diss them
as being trolls)
even the predecessor EV7 machines appeared as late as 2003.
The EV79 seemed to exist at least as silicon prototypes,
but according to HP couldn't even be made by IBM
(wasn't intel obliged to produce Alphas according
to that 1997 deal?).
Whether this was a lame excuse on HP's part or not,
it certainly gave them a face saving reason
to put an end to Alpha's misery.
And finally, as the above site speculates,
those funny EV7z's might well be just overclocked EV7's
which by chance survived the high clock rate.
This shows that all paperwork and roadmaps
aren't worth a dime if one can't produce the stuff.
> and was in a very late state of
> development when the Alphacide took place. EV7z came later when the
> EV78/79 was cancelled.
>
They existed (for real) already in the 1990s,
based on PPC (and possibly others).
> Today we see these things on many cpus including x86, but they were the
> first. They had an idea, a vision.
You call it vision, I'd call it vapourware.
> Michael Kraemer wrote:
>
>> Dirk Munk schrieb:
>>
>
>> Dirk Munk schrieb:
>>
>>> The EV9 tour took place at the time that EV8 was almost ready,
>>
>>
>> This is a bold statement, since, iirc, it was even difficult to produce
>> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
>> it in silicon, afaik.
>
>
> The EV8 was scheduled for 2003,
How can that be? According to
>>
>>
>> This is a bold statement, since, iirc, it was even difficult to produce
>> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
>> it in silicon, afaik.
>
>
> The EV8 was scheduled for 2003,
http://alasir.com/articles/alpha_history/alpha_21364_21464.html
(a site positively biased towards the Alpha, so you can't diss them
as being trolls)
even the predecessor EV7 machines appeared as late as 2003.
The EV79 seemed to exist at least as silicon prototypes,
but according to HP couldn't even be made by IBM
(wasn't intel obliged to produce Alphas according
to that 1997 deal?).
Whether this was a lame excuse on HP's part or not,
it certainly gave them a face saving reason
to put an end to Alpha's misery.
And finally, as the above site speculates,
those funny EV7z's might well be just overclocked EV7's
which by chance survived the high clock rate.
This shows that all paperwork and roadmaps
aren't worth a dime if one can't produce the stuff.
> and was in a very late state of
> development when the Alphacide took place. EV7z came later when the
> EV78/79 was cancelled.
>
> Everything starts with an idea, with a design. The Alpha engineers had
> the idea to put the memory controller in the cpu, to integrate fast
> network controllers in the cpu for very fast inter cpu communication.
SoC designs weren't a new idea anymore at that time.
> the idea to put the memory controller in the cpu, to integrate fast
> network controllers in the cpu for very fast inter cpu communication.
They existed (for real) already in the 1990s,
based on PPC (and possibly others).
> Today we see these things on many cpus including x86, but they were the
> first. They had an idea, a vision.
Michael Kraemer
Jun 6, 2012, 3:37:28 AM6/6/12
to
John Reagan schrieb:
> You folks need to get out more. HP-UX has had DKLM (dynamically loaded
> kernel modules) for over 10 years.
>
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01943990/c01943990.pdf?jumpid=reg_R1002_USEN
>
>
> The HP-UX kernel isn't the monolith that you suggest.
HP-UX started as a monolith, and stayed this way
during its best years (versions 9 through 11).
In the course of time the old dog certainly has learned some new tricks,
but I have some doubts whether it could be called entirely "dynamic".
> You folks need to get out more. HP-UX has had DKLM (dynamically loaded
> kernel modules) for over 10 years.
>
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01943990/c01943990.pdf?jumpid=reg_R1002_USEN
>
>
> The HP-UX kernel isn't the monolith that you suggest.
during its best years (versions 9 through 11).
In the course of time the old dog certainly has learned some new tricks,
but I have some doubts whether it could be called entirely "dynamic".
Paul Sture
Jun 6, 2012, 8:51:27 AM6/6/12
to
from other platforms was that they didn't need assembler knowledge. You
could simply get a contractor (or presumably IBM themselves) in for the
occasional bit of assembler.
--
Paul Sture
Fritz Wuehler
Jun 6, 2012, 2:51:44 PM6/6/12
to
Paul Sture <paul....@sture.ch> wrote:
> As far back as 1980 IBM's recommendation for system managers migrating
> from other platforms was that they didn't need assembler knowledge. You
> could simply get a contractor (or presumably IBM themselves) in for the
> occasional bit of assembler.
If you're migrating from another platform you didn't need much assembler
> As far back as 1980 IBM's recommendation for system managers migrating
> from other platforms was that they didn't need assembler knowledge. You
> could simply get a contractor (or presumably IBM themselves) in for the
> occasional bit of assembler.
knowledge because by definition, you won't have legacy code on the new
platform. The issue is maintaining existing applications and you don't have
any existing applications in a migration, at least not in assembler ;-)
John Wallace
Jun 6, 2012, 4:16:21 PM6/6/12
to
On Jun 6, 8:23 am, Michael Kraemer <M.Krae...@gsi.de> wrote:
> Dirk Munk schrieb:
>
> > Michael Kraemer wrote:
>
> >> Dirk Munk schrieb:
>
> >>> The EV9 tour took place at the time that EV8 was almost ready,
>
> >> This is a bold statement, since, iirc, it was even difficult to produce
> >> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
> >> it in silicon, afaik.
>
> > The EV8 was scheduled for 2003,
>
> How can that be? According tohttp://alasir.com/articles/alpha_history/alpha_21364_21464.html
> Dirk Munk schrieb:
>
> > Michael Kraemer wrote:
>
> >> Dirk Munk schrieb:
>
> >>> The EV9 tour took place at the time that EV8 was almost ready,
>
> >> This is a bold statement, since, iirc, it was even difficult to produce
> >> its predecessor(s), EV7/EV7z. Everything beyond these didn't make
> >> it in silicon, afaik.
>
> > The EV8 was scheduled for 2003,
>
with the main chip even including basic video out, basically just add
DRAM and an SROM and you're good to go) was a fine idea, and got way
past the vapourware stage back in the early days of Alpha. The
implementation left a great deal to be desired in performance terms,
and volume PC builders understandably saw no compelling reason to
build systems around it, even when the reference motherboard design(s)
were handed to them on a plate. It did find a home in the Alpha Multia
- have a look at one and see just how little glue logic there is once
you take away the network, SCSI and decent graphics.
These days ARM licencees will build you a complete system (usually
minus the ROM and RAM) on a chip, and most of us have one or more of
them, whether we know it or not. Intel have a lot of catching up to do
if they really want to play in this market.
68 page 21066 data sheet: http://h18000.www1.hp.com/cpq-alphaserver/technology/literature/21066ads.pdf
The "21066 Product Brief" is worth a look (usual search engines should
find it) if you're interested and can cope with PostScript rather than
something newer.
Michael Kraemer
Jun 6, 2012, 7:14:47 PM6/6/12
to
John Wallace schrieb:
I wonder who would have produced them if Alpha wasn't terminated.
Iirc the EV68 (back in Compaq times) was already fabbed by IBM.
Intel wouldn't or couldn't do that, what happened to the 1997
DEC/intel deal?
The EV79 also was made by IBM, but not to HP's satisfaction,
at least according to HP.
So who could have produced EV8 onwards, if even IBM,
one of the best chipmakers at that time, couldn't do the
preceeding EV79?
> The "21066 Product Brief" is worth a look (usual search engines should
> find it) if you're interested and can cope with PostScript rather than
> something newer.
I can :-)
> On Jun 6, 8:23 am, Michael Kraemer <M.Krae...@gsi.de> wrote:
>>
>>You call it vision, I'd call it vapourware.
>
>
> The 21066/21068 concept from the mid 1990s (a glueless Alpha system
> with the main chip even including basic video out, basically just add
> DRAM and an SROM and you're good to go) was a fine idea, and got way
> past the vapourware stage back in the early days of Alpha.
"Vapourware" referred to the EV8..EV12 which never existed.
>>
>>You call it vision, I'd call it vapourware.
>
>
> The 21066/21068 concept from the mid 1990s (a glueless Alpha system
> with the main chip even including basic video out, basically just add
> DRAM and an SROM and you're good to go) was a fine idea, and got way
> past the vapourware stage back in the early days of Alpha.
I wonder who would have produced them if Alpha wasn't terminated.
Iirc the EV68 (back in Compaq times) was already fabbed by IBM.
Intel wouldn't or couldn't do that, what happened to the 1997
DEC/intel deal?
The EV79 also was made by IBM, but not to HP's satisfaction,
at least according to HP.
So who could have produced EV8 onwards, if even IBM,
one of the best chipmakers at that time, couldn't do the
preceeding EV79?
> The "21066 Product Brief" is worth a look (usual search engines should
> find it) if you're interested and can cope with PostScript rather than
> something newer.
MG
Jun 7, 2012, 6:50:56 AM6/7/12
to
On 6-6-2012 9:23, Michael Kraemer wrote:
> How can that be? According to
> http://alasir.com/articles/alpha_history/alpha_21364_21464.html
> (a site positively biased towards the Alpha, so you can't diss them
> as being trolls)
"Diss"?
> How can that be? According to
> http://alasir.com/articles/alpha_history/alpha_21364_21464.html
> (a site positively biased towards the Alpha, so you can't diss them
> as being trolls)
- MG
Paul Sture
Jun 7, 2012, 8:06:11 AM6/7/12
to
a sister company, but that was written in PL/I.
Looking back at that, it was a complete contrast to the outsourcing that
is so popular nowadays. We were buying software from a trusted supplier
who was "on our own side", being part of the same group. The software
was a known quantity which only needed modifying where our business model
had a different emphasis from the sister company's.
--
Paul Sture
Paul Sture
Jun 7, 2012, 8:27:15 AM6/7/12
to
or more. I don't think it was quite the same product as Windows 2008 R2
Datacenter Edition, but that comes in at $2,999 per processor according
to the following chart:
<http://news.softpedia.com/newsImage/Windows-Server-2008-R2-Pricing-and-
Licensing-3.png/>
A couple of years ago I saw a rant about the RAM limitations of the lower
end flavours of Windows Server. The Standard Edition supports a maximum
of 32 GB RAM, for more you need the Enterprise or Datacenter Editions.
Taken from:
<https://en.wikipedia.org/wiki/Windows_Server_2008#System_requirements>
In contrast Windows 7 Professional and above supports 192 GB:
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778%
28v=vs.85%29.aspx#physical_memory_limits_windows_7>
> Could VMS justify Datacenter Edition style of pricing for the server
> side of things (maybe a little bit more, and a LOT less for development
> licences, MSDN style)? Could it ever be profitable enough to keep VMS
> going?
have clearly worked in Microsoft's favour. I gather that if you have a
serious product for sale, you can get the lot for free with the BizSpark
programme
<http://www.microsoft.com/bizspark/default.aspx>
--
Paul Sture
Paul Sture
Jun 7, 2012, 8:31:36 AM6/7/12
to
query=diss&title=21st>
"diss verb (dissed, dissing) slang, especially US to reject or dismiss
someone with contempt; to bad mouth them.
ETYMOLOGY: 20c rapper slang, probably from disrespect."
"20th Century" covers a lot. I recognize it as a relatively recent term.
--
Paul Sture
MG
Jun 7, 2012, 9:59:56 AM6/7/12
to
On 7-6-2012 14:31, Paul Sture wrote:
> <http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/main?
> query=diss&title=21st>
>
> "diss verb (dissed, dissing) slang, especially US to reject or dismiss
> someone with contempt; to bad mouth them.
>
> ETYMOLOGY: 20c rapper slang, probably from disrespect."
>
> "20th Century" covers a lot. I recognize it as a relatively recent term.
So, I see that Michael Kraemer is a "rapper" or "rap" connoisseur.
> <http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/main?
> query=diss&title=21st>
>
> "diss verb (dissed, dissing) slang, especially US to reject or dismiss
> someone with contempt; to bad mouth them.
>
> ETYMOLOGY: 20c rapper slang, probably from disrespect."
>
> "20th Century" covers a lot. I recognize it as a relatively recent term.
- MG
JF Mezei
Jun 8, 2012, 9:43:38 PM6/8/12
to
Michael Kraemer wrote:
> is less than stellar. However, if you run only
> workstation class programs you might not measure
> what a typical Itanic customer is interested in
You can build a small office server with the same CPU chip as used on an
enterprise server. The enterprise servers has better performance because
of faster supporting chips and faster interconnects to peripherals.
So if chip 1 gives you noticably better performance on a small server,
chances are that it will also perform better on the enterprise serers.
You need to remember that today's 8086s use Quickpath for memory
interconnects, the same stuff that IA64.
So it should be relatively easy for HP to build 8086 based superdomes
with the quickppath interconnect in the backpane so that each blade can
access other blades' memory.
But it appears HP is too busy with constant maagement reorganisations to
actually deliver that "project Odyssey". Maybe Witman found out that
Hurd had fired the whole development deal and HP doesn't have any
resources to develop its own enterprise computers anymore ?
> is less than stellar. However, if you run only
> workstation class programs you might not measure
> what a typical Itanic customer is interested in
You can build a small office server with the same CPU chip as used on an
enterprise server. The enterprise servers has better performance because
of faster supporting chips and faster interconnects to peripherals.
So if chip 1 gives you noticably better performance on a small server,
chances are that it will also perform better on the enterprise serers.
You need to remember that today's 8086s use Quickpath for memory
interconnects, the same stuff that IA64.
So it should be relatively easy for HP to build 8086 based superdomes
with the quickppath interconnect in the backpane so that each blade can
access other blades' memory.
But it appears HP is too busy with constant maagement reorganisations to
actually deliver that "project Odyssey". Maybe Witman found out that
Hurd had fired the whole development deal and HP doesn't have any
resources to develop its own enterprise computers anymore ?
JF Mezei
Jun 8, 2012, 9:52:37 PM6/8/12
to
FrankS wrote:
> Not just that, but once it gets the "x86 Inside" sticker on the box, then there'd be an expectation that one could go out and buy any x86 box and getting OpenVMS running on it,
This perception has changed quite a bit since the introduction of Linux
> Not just that, but once it gets the "x86 Inside" sticker on the box, then there'd be an expectation that one could go out and buy any x86 box and getting OpenVMS running on it,
(whose driver inventory is less than Windows) and also when Apple
adopted the 8086 but built it with its own flavour of EFI and of course
drivers to support hardware that Apple has approved.
So if VMS were ported to the 8086, one would expect that it would
require a system with a compliant EFI firmware (I think it si called
UEFI now) and certain chipsets, and again, limited drivers for monitors
and other peripherals.
John Wallace
Jun 9, 2012, 5:49:50 AM6/9/12
to
addressability is not much use to a customer who wants a fast SMP
server with massive memory. This is (was? I haven't checked the latest
generation from Intel and AMD) one of the few areas where Itanium
chips had a clear advantage over AMD64 in recent years.
Also, Quickpath is primarily an IO and interprocessor bus. Systems
using QPI are generally expected to use processors with an on-chip
memory controller.
"interconnect in the backpane so that each blade can access other
blades' memory."
it allows you to interconnect Integrity blades to make them into a
single 8socket system comprised of multiple blades. I'm not sure of
the exact details, pointers welcome. Who cares whether the pins have
Quickpath on them or some other bus, and how hard would it be to make
an AMD64 variant if one doesn't already exist?
"Maybe ... HP doesn't have any resources to develop its own enterprise
computers anymore."
Most of the IT world these days considers HPQ Proliant to be adequate
hardware for enterprise-class. Mostly these days it's the software
that holds it back relative to the non-x86 competition (I'm still
waiting for details of what RAS features need to be added to "catch
up" with IA64). And we know what's happened to the important parts of
HP's OS development resources.
johnso...@gmail.com
Jun 9, 2012, 7:03:28 AM6/9/12
to
On Saturday, June 9, 2012 5:49:50 AM UTC-4, John Wallace wrote:
> A fast desktop class chip with (relatively) limited memory
> addressability is not much use to a customer who wants a fast SMP
> server with massive memory. This is (was? I haven't checked the latest
> generation from Intel and AMD) one of the few areas where Itanium
> chips had a clear advantage over AMD64 in recent years.
I believe that advantage no longer exists.
> A fast desktop class chip with (relatively) limited memory
> addressability is not much use to a customer who wants a fast SMP
> server with massive memory. This is (was? I haven't checked the latest
> generation from Intel and AMD) one of the few areas where Itanium
> chips had a clear advantage over AMD64 in recent years.
You can get x86 systems with 1 TB of RAM and 8 socket x86 CPUs.
Put a 10 core in each of those sockets and you have an 80 core box.
This is the example I was looking at. There are others.
http://www.supermicro.com/products/system/5U/5086/SYS-5086B-TRF.cfm
I believe that QPI provides the fast memory interconnect that one would
expect from a traditional enterprise enabled SMP box. Interestingly
enough, the QPI offered in that supermicro product appears to have more
bandwidth (6.4 Gbps) than the ones offered in an Itanium (4.8 Gbps).
EJ
John Wallace
Jun 9, 2012, 9:09:51 AM6/9/12
to
these days). I had been thinking it was only a matter of time before
x86-64 processor count and memory limits caught up with Itanium, hence
the "not checked lately" caveat.
I just checked and the HPQ Proliant DL980 G7 has a similar basic spec
to that Supermicro - up to 80 Xeon cores in 8 sockets (each with up to
30MB cache), with up to 2TB of system memory. The DL980 G7 brochure
and quickspec actually says "up to 4TB"; the 2TB is in the current
Proliant Family overview.
This latest Proliant uses a "Superdome 2 derived" (whatever that
means) node controller, as part of something called PREMA
Architecture, to interconnect two 4-socket Xeon subsystems and provide
"smart CPU caching and the redundant system fabric. These serve to
reduce communication and coordination overhead as well as to enhance
system resiliency."
Maybe all it needs now is a decent OS other than Linux and Windows for
these high end systems; Solaris and VMware are qualified on this box,
do they count?
Accessing (some) memory via QPI sounds a bit NUMA-ish to me, and round
here some readers may remember that NUMA systems don't always deliver
what you might have hoped for, depending on the capabilities of the
interconnect and the OS, and the behaviours of the application(s). If
the interconnect truly delivers remote memory access which is barely
distinguishable from local memory access, all is well, otherwise
readers may wish to set the wayback machine to the pre-EV7 days when
remote memory access was fast, but not really as fast as local memory
access. I haven't looked at how well that works in recent x86-64 or
Superdome hardware.
I'd guess the implementation of Quickpath in the x86 boxes is more
recent than the one in the IA64 boxes, and hence the bigger IO numbers
in the x86 boxes (nb those numbers are transactions per second, not
just bits/bytes per second).
Whether any sane business would still want to buy that class of x86-64
system from HPQ rather than SuperMicro is a more interesting
discussion these days than it would have been a few years ago. IBM do
similar boxes too (up to 4 sockets anyway), for those of a more
nervous disposition.
For reference:
HP DL980 G7 brochure:
http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA1-5671ENW.pdf
HP Proliant Family Guide:
http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA3-0132ENW.pdf
HP DL980 G7 PREMA overview:
http://h20427.www2.hp.com/campaign/promotion/kr/ko/09_storagesolution/doc/PREMA_architecture-Tech.pdf
John Wallace
Jun 9, 2012, 9:26:53 AM6/9/12
to
Not only have I fallen behind the times, I've forgotten this from
December 2010, with very similar (but maybe not quite the same) DL980
G7 references:
http://groups.google.com/group/comp.os.vms/msg/b1d0204a5a1a5f7c
Author: yours truly.
I probably don't need 2TB of memory, but I'd like what I have got to
be reliable. Ho hum.
Have a lot of fun (SUSE is qualified on the DL980 G7 too).
JF Mezei
Jun 9, 2012, 12:18:16 PM6/9/12
to
John Wallace wrote:
> Accessing (some) memory via QPI sounds a bit NUMA-ish to me, and round
> here some readers may remember that NUMA systems don't always deliver
> what you might have hoped for,
Quickpath is closeer to what EV7 got than what the first galaxy/wildfire
> Accessing (some) memory via QPI sounds a bit NUMA-ish to me, and round
> here some readers may remember that NUMA systems don't always deliver
> what you might have hoped for,
class machines had.
Also, since both IA64 and 8086 use Quickpath, they are on a level
playing field when it comes to performance in system with high core count.
John Wallace
Jun 9, 2012, 12:38:05 PM6/9/12
to
can see they're not using the *comparable implementations* of
Quickpath. How level is the playing field if (on paper at least), Xeon
hardware is twice as fast as Itanium (presumably because Xeon is a
year or two ahead)?
JF Mezei
Jun 9, 2012, 1:29:05 PM6/9/12
to
John Wallace wrote:
> Quickpath. How level is the playing field if (on paper at least), Xeon
> hardware is twice as fast as Itanium (presumably because Xeon is a
> year or two ahead)?
The thing is that IA64 is going to be consistently behind XEON because
> Quickpath. How level is the playing field if (on paper at least), Xeon
> hardware is twice as fast as Itanium (presumably because Xeon is a
> year or two ahead)?
HP has slowed development speed to space the final 2 releases more to
pretent IA64 still has a long life ahead of it.
Heck, if HP really wants to pretrent IA64 will be developped until 2022,
it can tell Intel to release Kittson in 2022. 10 years between Poulson
and Kittson during which HP can still claim IA64 is being developped.
But during this time, Poulson will become like the microvax II compared
to current 8086s which will continue to evolve.
ChrisQ
Jun 9, 2012, 2:36:14 PM6/9/12
to
On 06/04/12 11:22, Michael Kraemer wrote:
> The customers prefer(red) x86 over the alternatives, it seems.
>
The reason being that it is the plain vanilla of computing. Most
software runs on it as do most hardware interfaces.
But the point being missed is that biodiversity is the only way
to get progress. There are now only 3 major architectures in use in
the world of computing, with one dominating the market. I expect no
seriously advanced architectures within the next decade, especially
after the cost, hubris and eventual failure of Itanic. No-one will
take the risk. What we will get is what Intel decide is good for
their bottom line and no more.
20 years ago, the industry was teeming with life, now a pale shadow
of it's former self...
Regards,
Chris
> The customers prefer(red) x86 over the alternatives, it seems.
>
The reason being that it is the plain vanilla of computing. Most
software runs on it as do most hardware interfaces.
But the point being missed is that biodiversity is the only way
to get progress. There are now only 3 major architectures in use in
the world of computing, with one dominating the market. I expect no
seriously advanced architectures within the next decade, especially
after the cost, hubris and eventual failure of Itanic. No-one will
take the risk. What we will get is what Intel decide is good for
their bottom line and no more.
20 years ago, the industry was teeming with life, now a pale shadow
of it's former self...
Regards,
Chris
ChrisQ
Jun 9, 2012, 2:50:05 PM6/9/12
to
On 06/03/12 20:47, Jan-Erik Soderholm wrote:
>
> Alpha would probably been a better processor today with the
> same ampount of resources put into it as have been put into
> IA64. Some even says that Tru64 was better then HP-UX :-)
>
> Jan-Erik.
>
I ran tru64 on alpha for 10+ years and it was a very solid and
friendly os to use on a day to day basis. No fancy frills or non
standard utility names (as with hp-ux), just a good solid unix
with no major snags. With further development of both hardware
and software, it would have been the equal or better than Solaris
and much faster than sparc.
Hp could never have kept either alpha or tru64 - the stench of
of nih factor was overpowering at the time. As i've said before,
hubris, overeach and shear obstinate stupidity are eventually
their own reward...
Regards,
Chris
>
> Alpha would probably been a better processor today with the
> same ampount of resources put into it as have been put into
> IA64. Some even says that Tru64 was better then HP-UX :-)
>
> Jan-Erik.
>
I ran tru64 on alpha for 10+ years and it was a very solid and
friendly os to use on a day to day basis. No fancy frills or non
standard utility names (as with hp-ux), just a good solid unix
with no major snags. With further development of both hardware
and software, it would have been the equal or better than Solaris
and much faster than sparc.
Hp could never have kept either alpha or tru64 - the stench of
of nih factor was overpowering at the time. As i've said before,
hubris, overeach and shear obstinate stupidity are eventually
their own reward...
Regards,
Chris
ChrisQ
Jun 9, 2012, 7:08:53 PM6/9/12
to
On 06/06/12 23:14, Michael Kraemer wrote:
> "Vapourware" referred to the EV8..EV12 which never existed.
> I wonder who would have produced them if Alpha wasn't terminated.
> Iirc the EV68 (back in Compaq times) was already fabbed by IBM.
> Intel wouldn't or couldn't do that, what happened to the 1997
> DEC/intel deal?
> The EV79 also was made by IBM, but not to HP's satisfaction,
> at least according to HP.
> So who could have produced EV8 onwards, if even IBM,
> one of the best chipmakers at that time, couldn't do the
> preceeding EV79?
>
Michael, if you want a *real* vapourware story, examine the history of
> "Vapourware" referred to the EV8..EV12 which never existed.
> I wonder who would have produced them if Alpha wasn't terminated.
> Iirc the EV68 (back in Compaq times) was already fabbed by IBM.
> Intel wouldn't or couldn't do that, what happened to the 1997
> DEC/intel deal?
> The EV79 also was made by IBM, but not to HP's satisfaction,
> at least according to HP.
> So who could have produced EV8 onwards, if even IBM,
> one of the best chipmakers at that time, couldn't do the
> preceeding EV79?
>
itanic, which cost some nation's gdp, promised much, was always late
and always underwhelming and behind the competition in performance terms.
You can troll as much as you like, but the facts speak for themselves.
What dec had was hard intellect, in hw design, software and compilers.
People wanted to work there. Why ?, because they had a culture of
innovation,
pursuit of excellence and doing it right. Qualities engineers could
respect.
Something hp might remember as being the founding values of their
company, if
they wern't so stoned on their own Koolaid and bulls**t.
How many good engineering companies have hp trashed now ?. Dec, Compaq and
3Com, for starters, two of whom I worked for and all of whom built very
well
engineered product. Sunk without trace, along with their culture and
engineering prowess...
Regards,
Chris
Bob Koehler
Jun 11, 2012, 9:39:55 AM6/11/12
to
In article <yVMAr.27615$ME5....@fx22.am4>, ChrisQ <me...@devnull.com> writes:
>
> I ran tru64 on alpha for 10+ years and it was a very solid and
> friendly os to use on a day to day basis. No fancy frills or non
> standard utility names (as with hp-ux), just a good solid unix
> with no major snags. With further development of both hardware
> and software, it would have been the equal or better than Solaris
> and much faster than sparc.
Faster in instruction processing? Perhaps. But Tru64 was much
>
> I ran tru64 on alpha for 10+ years and it was a very solid and
> friendly os to use on a day to day basis. No fancy frills or non
> standard utility names (as with hp-ux), just a good solid unix
> with no major snags. With further development of both hardware
> and software, it would have been the equal or better than Solaris
> and much faster than sparc.
slower where it counted - sales.
When Curly decided to talk to Carly about reselling HP-UX rather
than continuing Tru64, he wasn't being a complete fool.
> Hp could never have kept either alpha or tru64 - the stench of
> of nih factor was overpowering at the time. As i've said before,
> hubris, overeach and shear obstinate stupidity are eventually
> their own reward...
of whether you think HP influenced Compaq's decision to kill Alpha.
Of course, since Alpha was bi-endian, porting HP-UX to is would have
been much easier than porting it to x86, but Alpha had become just
another boutique processor.
And HP's recent discussions make it quite clear that they are not going to
port HP-UX again.
0 new messages