Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk>
Newsgroups: comp.os.vms
Subject: Re: Itanium support is back in GCC 15
Date: Fri, 8 Nov 2024 09:04:05 -0500
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <vgl5om$37f44$1@dont-email.me>
References: <vgb3kb$12h4i$2@dont-email.me> <vgba26$13nmf$1@dont-email.me>
 <lp4c05FdsbqU1@mid.individual.net> <vgjck0$2qpmc$1@dont-email.me>
 <lp6284Fll3cU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 08 Nov 2024 15:04:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="26db8364c63de52c1f9edeb957a98169";
	logging-data="3390596"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+KWYltR+ceUgyg05COnusdHCGW4z23Znc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6IIIXHMZja/fDp42QSGrK6/zgDU=
Content-Language: en-US
In-Reply-To: <lp6284Fll3cU1@mid.individual.net>
Bytes: 3739

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