Re: Computer architects leaving Intel...

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.

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; 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
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>