gcalliet <gerard.calliet@pia-sofer.fr> wrote:

On my side I have always thought the failure of Itanium - they said
Itanic - have been just the bad meeting between the conservatism of
geeks and the inchoate laws of the market. Our hatred of Itanium
contributed to the long life of the very archaic x86 to which the very
wise Intel returned, for its greater good.

Failure of Itanic was extensively disscussed in comp.arch. There
were fundamental issues, EPIC concept required compiler arrange
code in clever way to gain good performance. Hand coding small
examples suggested that it is possible to write fast code for
EPIC, but both when Itanic project started and now nobody knows
how to do this in a compiler. There is related issue, when
Itanic started is was not known how to get good instruction
paralellism on conventional architectures. But then branch predictors
happened and Intel and AMD were able to get good ILP from x86
(the same could be done with many other architectures, but is
incompatible with Itanic principles).

Beside fundamental problems there were several specific blunders.

Anyway, Itanic was late, expensive and had unimpressive performance.
Some people were waiting for it, but what was promised (top
performance) never appeared.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Itanium support will no longer be removed from GCC and Itanium will
instead continue as a supported architecture (at least for Linux).

https://www.theregister.com/2024/11/01/gcc_15_keep_itanium_support/

There's a call in that article for an open source full-system emulator.
Good luck with that one, especially for one that would run VMS as well. :-)

One question: Why ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/4/2024 1:26 PM, Simon Clubley wrote:

Itanium support will no longer be removed from GCC and Itanium will
instead continue as a supported architecture (at least for Linux).

https://www.theregister.com/2024/11/01/gcc_15_keep_itanium_support/

There's a call in that article for an open source full-system emulator.
Good luck with that one, especially for one that would run VMS as well. :-)

One question: Why ? :-)

Regarding why, then it seems obvious that there are no
good commercial reason for GCC to support Itanium, but
apparently someone is willing to do the work just for fun.

And in the open source world if someone is willing
to do the work for fun then it (usually) does happen.

And Itanium is rather different from most other
architectures, so from an academic perspective it
may be interesting.

I wish someone would volunteer to create VMS support
in GCC 16 or whatever!

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 04/11/2024 à 21:16, Arne Vajhøj a écrit :

On 11/4/2024 1:26 PM, Simon Clubley wrote:

Itanium support will no longer be removed from GCC and Itanium will
instead continue as a supported architecture (at least for Linux).

https://www.theregister.com/2024/11/01/gcc_15_keep_itanium_support/

There's a call in that article for an open source full-system emulator.
Good luck with that one, especially for one that would run VMS as
well. :-)

One question: Why ? :-)

Regarding why, then it seems obvious that there are no
good commercial reason for GCC to support Itanium, but
apparently someone is willing to do the work just for fun.

And in the open source world if someone is willing
to do the work for fun then it (usually) does happen.

And Itanium is rather different from most other
architectures, so from an academic perspective it
may be interesting.

I wish someone would volunteer to create VMS support
in GCC 16 or whatever!

Arne

Because I created (canadian method) Gnat Ada (on gcc) for VMS Itanium,
and because we were on gcc 4.7, there is some work ahead, but why not :)

The big issue is the step to gcc 5, where they upgraded to c++ mode. It
is one of the reasons why Adacore didn't continue support of gnat ada on
VMS in 2015.

I have to know who likes Itanium so much :)

gcalliet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/7/2024 12:33 PM, gcalliet wrote:

Le 04/11/2024 à 21:16, Arne Vajhøj a écrit :

I wish someone would volunteer to create VMS support
in GCC 16 or whatever!

Because I created (canadian method) Gnat Ada (on gcc) for VMS Itanium,
and because we were on gcc 4.7, there is some work ahead, but why not :)

The big issue is the step to gcc 5, where they upgraded to c++ mode. It
is one of the reasons why Adacore didn't continue support of gnat ada on
VMS in 2015.

VMS x86-64 has a better C++ compiler than VMS Itanium.

But I have no idea which is best for boot strapping:

g++/Linux -> GXX/VMS

clang/VMS -> GXX/VMS

I assume that if a recent GXX/VMS is working then getting
GFortran and Gnat working would become a lot easier.

But obviously a lot of work. And I do not expect it to happen. Just
a thought given that someone wanted to support GCC/Itanium.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 07/11/2024 à 22:48, Arne Vajhøj a écrit :

But obviously a lot of work. And I do not expect it to happen. Just
a thought given that someone wanted to support GCC/Itanium.

You are right, a lot of work. But perhaps a lot of fun :)

About Itanium, who knows? I heard about some specific uses of Itanium.
So perhaps a very little business with Itanium could exist sometime.

On my side I have always thought the failure of Itanium - they said
Itanic - have been just the bad meeting between the conservatism of
geeks and the inchoate laws of the market. Our hatred of Itanium
contributed to the long life of the very archaic x86 to which the very
wise Intel returned, for its greater good.

Just to initiate a great controversy :)

gcalliet

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/8/2024 3:59 AM, gcalliet wrote:

About Itanium, who knows? I heard about some specific uses of Itanium.
So perhaps a very little business with Itanium could exist sometime.

On my side I have always thought the failure of Itanium - they said
Itanic - have been just the bad meeting between the conservatism of
geeks and the inchoate laws of the market. Our hatred of Itanium
contributed to the long life of the very archaic x86 to which the very
wise Intel returned, for its greater good.

VMS people never liked Itanium. We loved VAX and Alpha, we are OK with
x86-64, but Itanium was only bought because for almost 2 decades it
was the only option for a new VMS box.

Itanium never had a chance. But it was due to money.

The CPU cost structure (huge fixed cost for design and fab construction
vs relative small variable cost) means that only CPU's selling
in hundreds of millions can compete cost wise. So Itanium fell
behind in clock speed, number of cores and energy efficiency.

The EPIC concept has been translated to "leave the real work to the
compiler" and for that to succeed then huge investments in
compiler technology would have been needed - hundreds maybe
thousands of engineers working on compiler backend. Did not
happen - not in HP not in Intel not anywhere. So on VMS Itanium
the generated "bundles" has a huge percentage of NOP's.

Could Itanium design have worked out if by magic the necessary
money for CPU development and compiler backend development had
been there? That is an academic question with no practical
impact - it did not happen and it could never have happened.

But from the technical perspective then I do see some
benefits from the Itanium design. CPU's has hit the GHz
cap - just doubling clock speed every generation
is not physical possible. x86-64 has worked around that
mostly by increasing number of cores. 1->2->4->8->16->24->32 cores
worked pretty well as both servers and desktop computers does
a lot of processes and/or threads in parallel. But 64, 128,
192 and 256 cores? If running a hypervisor and 10 VM's then all
good, but what if that is not the case? The Itanium bundles
offer a way to parallelize hardware usage for single
threads.

Modern x86-64 does a lot of advanced stuff under the hood to
do similar things. But it is limited by the instructions
and the memory model. With same level of investments then
I believe Itanium would do better.

But it is all pretty pointless. It is like: what if the speed
of light was 20 MPH instead of 200000 MPS.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <lp6284Fll3cU1@mid.individual.net>,
gerard.calliet@pia-sofer.fr (gcalliet) wrote:

About Itanium, who knows? I heard about some specific uses of
Itanium. So perhaps a very little business with Itanium could exist
sometime.

It can't last now. There are a finite supply of Itanium CPUs and no more
being made.

On my side I have always thought the failure of Itanium - they said
Itanic - have been just the bad meeting between the conservatism of
geeks and the inchoate laws of the market.

It also had fundamental technical flaws. The basic idea of EPIC, that a compiler with plenty of time to plan, can optimise memory advance loads
to make Out-of-Order execution unnecessary, is wrong.

It would be possible to do that in a single-core system with no processor caches, a single-tasking operating system, and few interrupts going off.
In a multi-processor, multi-tasking system which is taking interrupts, it
is impossible to know in advance what data will be in which cache levels,
and hence to optimise memory access in advance.

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)