Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 30 Aug 2024 14:52:46 +0300
Organization: A noiseless patient Spider
Lines: 105
Message-ID: <20240830145246.00003587@yahoo.com>
References: <vaqgtl$3526$1@dont-email.me>
	<memo.20240830090549.19028u@jgd.cix.co.uk>
	<vas3tq$eev5$1@dont-email.me>
	<2024Aug30.122638@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Aug 2024 13:52:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="84095aa47f02d0f520b248b5be4ecbd4";
	logging-data="489299"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+V2C+glnfEoly1K2+OdW0LmxvlnqpW0HQ="
Cancel-Lock: sha1:dxeXD7EKM0oN12VQduJ2U0EQiDs=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 5464

On Fri, 30 Aug 2024 10:26:38 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Thomas Koenig <tkoenig@netcologne.de> writes:
> >John Dallman <jgd@cix.co.uk> schrieb:  
> [...]
> >What is an ISV? I assume "SV" is for "software vendor", but what
> >does the I stand for?  
> 
> <https://en.wikipedia.org/wiki/Independent_software_vendor>
> 
> >> Variant ISAs create fear, uncertainty and doubt, and that means
> >> delay. ISA promotors fear delay, because their investors will run
> >> out of patience.   
> >
> >Which makes me wonder why companies such as Intel introduce new
> >instructions all the time.  
> 
> AMD64 already has the buy-in of application vendors for desktops and
> servers, so it does not have the problem that extensions create
> uncertainty among application vendors.
> 
> My guess is that there are the following motivations:
> 
> 1) The new instructions make technical sense (for certain
> applications).
> 
> 2) Even if the applications that the users use don't benefit from the
> extensions, the users think (thanks also to Intels marketing) that
> they might (because of 1); maybe not today, but maybe the next version
> or maybe the application that the user will run in a year or two.  And
> I certainly have seen reports that this or that game does not work on
> K10 or whatever because the game uses some SSE4.2 instruction that the
> K10 does not have.  Intel could have increased this kind of
> obsolescence (and the resulting new sales) through instruction set
> extensions by supporting AVX across the board early on (as AMD did),
> and later by supporting AVX512 across the board, but Intel marketing
> apparently thinks it's better to get people to buy Core-branded rather
> than Pentium-branded CPUs by disabling AVX for a long time on the
> latter.
> 

I wish if it was only marketing, i.e. if it were only fuses in big-core
derived Pentiums and Celerons.
Unfortunately, the bigger problem was poor work (laziness) of Intel's
engineering that didn't have AVX, or any for VEX decoding, in their
Atom line until Gracemont.
It's not marketing, it's engineers, who produced quite capable core
like Tremont with thhe level of ISA support 10 years behind its time.

> 3) I expect that Intel patents the extensions.  So these days
> everybody could build an AMD64 CPU, because the patent has expired,
> but nobody wants to buy such a CPU without the extensions (because of
> 2), and the extensions are patented.
> 
> >and it can even make sense to have
> >architecture-optimized core libraries such as BLAS, or switch on
> >availability of features such as AVX512  
> 
> Yes.  And given that a lot of software uses some library or other, a
> lot of software may benefit from the extensions.  Of course, the
> question is how big the benefit is.
> 
> E.g., glibc has many different versions of memcpy() and memmove() and
> selects among them based on the actual CPU used in the run, thanks to
> 
> 
> >But standard software (office applications, browsers...) should
> >just run everywhere, and there it gets hard to justify.  
> 
> That will also benefit from libraries.
> 
> For browsers the JavaScript and WASM JIT compiler can generate code
> specific to the extensions present in the hardware; however, no ISA
> extension comes to my mind that a JavaScript or current WASM JIT
> compiler will benefit from;

More convenient FP->Int conversion than what is available in SSE3.
Also, I'd guess, due to non-destructive ops scalar DPFP code could be
sometimes more compact with AVX encoding than with SSE2 encoding.

> IIRC there is discussion about explicit
> vector stuff in WASM, and there the extensions may make a difference.
> 
> Also, a friend who works on a JavaVM JIT told me he is working on
> auto-vectorization, but I don't know if they really went for that;
> Auto-vectorization is not just the wrong approach, it also seems
> particularly inappropriate for JIT compilers, because it requires a
> lot of analysis, i.e., compile time.
> 
> - anton

I agree for case of JS. Not so much for case of Enterprise Java.
OTOH, personally I care about performance of JS and don't care at all
about Enterprise Java. Would think that great majority of the world
is like me in that regard, but may be not so great among those who
sign checks.