Re: Computer architects leaving Intel...

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.