On 2/29/2024 12:49 PM, John Dallman wrote:
> In article <urq94k$m8rf$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> On 2/29/2024 3:06 AM, John Dallman wrote:
>>> HP-UX isn't all that different from Linux, and I seriously doubt
>>> there would be enough businesses that want to stay with HP-UX
>>> badly enough.
>> People liking HP-UX and liking Itanium may be a very small group.
>
> "Liking" doesn't mean so much when lots of money is involved. A decade
> ago, a fair few people may have expressed loyalty to HP-UX/Itanium, but
> it was obvious then that it wasn't going to grow, and the writing has
> been on the wall for Itanium since 2019.

I think the writing has been on the wall for Itanium since
the late 00's.

> Moving almost any kind of HP-UX software to Linux is much easier than
> moving VMS software that uses VMS hard to anything else.

Yes. Oracle DB, other RDBMS (Sybase, Informix), Apache httpd,
various Java EE servers (WAS, WL, JBoss, Tomcat etc.), custom
Java SE applications, custom C++ applications etc. all run
just as well on Linux as on HP-UX. So the companies have
the choice.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Dave Froble via
> Info-vax
> Sent: Thursday, February 29, 2024 2:16 PM
> To: info-vax@rbnsn.com
> Cc: Dave Froble <davef@tsoft-inc.com>
> Subject: Re: [Info-vax] HPE Integrity emulator
>
> On 2/29/2024 3:39 AM, John Dallman wrote:
> > In article <uroeg8$b8$1@panix2.panix.com>, kludge@panix.com (Scott
> > Dorsey)
> > wrote:
> >
> >> Well, that's sort of the thing. MAYBE the Itanium might actually
> >> have been a viable architecture if the compilers could have been made
> >> smart enough. But this turned out to be a whole lot harder than the
> >> Intel crew expected.
> >
> > No, it couldn't. The problem is the delays in accessing memory.
> >
> > EPIC requires the compilers to issue speculative loads far enough in
> > advance to keep the processor from stalling waiting for memory for
> > most of the time. However, that doesn't work: the information isn't
> > available enough of the time. The compiler also doesn't know what's in
> > what level of cache, because it's /impossible/ to know that when code
> > is running on a multi-tasking OS that is taking interrupts.
> >
> > Out-of-order execution, as used on modern x86 processors (and ARM,
> > POWER, IBM Z, and anything else that's still competitive) deals with
> > the memory and cache problems by letting the data dependencies for
> > instructions be resolved dynamically as data arrives. This works much
better.
> >
> > EPIC only made sense in a system that was running a single process and
> > taking few, if any, interrupts. That was how early embedded systems,
> > which were Intel's original market, worked in the 1970s and early 1980s.
> > Trying to apply that to a processor that appeared in 2001 was a
> > massive failure of concept and project management. Itanium was
> > obsolete when it shipped.
> >
> > John
> >
>
> In case we're looking for "blame", remember that EPIC wasn't Intel's brain
fart,
> it came from HP, who somehow got Intel to adopt it. You are correct, EPIC
was
> shown to be a poor choice before it even shipped. But someone(s) were too
> stubborn to listen to their own people.
>

Well, wrt to Integrity (aka IA64) there is likely enough blame to go around
with Compaq, Intel and HP.

Prior to buying DEC, Compaq was mostly a volume product shipper and the
culture / vision at the top was not there to really set the industry on any
new OS/HW directions. A big aspect of Compaq buying DEC was the services
portion of the business.

Since IA64 was really in its infancy when Intel acquired Alpha (rather was
forced to acquire Alpha due to legal issues), Intel could have decided to
drop IA64 and go full speed with next gen Alpha development. But, from what
I heard, there was a lot of "not invented here" culture in Intel, so Alpha
dev was pushed to the side.

And then IA64 was something like 6 or 7 years late to the market, which, by
this time, x86-64 was out and about, so IA64 never really recovered ..

Ah well, water under bridge and all that ..

Walk down memory lane reference:
<https://www.hpcwire.com/2001/06/24/intel-to-buy-alpha-chip-operation/>
"INTEL TO BUY ALPHA CHIP OPERATION - June 24, 2001"

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

In article <mailman.2.1712434050.27336.info-vax_rbnsn.com@rbnsn.com>,
kemain.nospam@gmail.com (Kerry Main c.o.v.) wrote:

> Since IA64 was really in its infancy when Intel acquired Alpha
> (rather was forced to acquire Alpha due to legal issues), Intel
> could have decided to drop IA64 and go full speed with next gen
> Alpha development. But, from what I heard, there was a lot of
> "not invented here" culture in Intel, so Alpha dev was pushed
> to the side.

There was far too much ego-driven decision-making at Intel in those days.
I made a joking suggestion to them in late 2002 or early 2003 that they
put IA-64 aside, and introduce "Itanium Pro," otherwise known as the next
generation of Alpha to replace it. The Intel engineer I made the
suggestion to was ex-DEC and thought this was funny, but did not fancy
passing the idea along.

> And then IA64 was something like 6 or 7 years late to the market,
> which, by this time, x86-64 was out and about, so IA64 never
> really recovered ..

Itanium shipped in June 2001. AMD Opteron shipped in April 2003. Itanium
was out first, but the lead didn't allow it to get established.

John