Hacker News Reader

Comment by PaulHoule | Hacker News Reader

I wonder what Charlie Demerjian is going to say about this.

It is an awful lot of registers for a feature that few programs may use. There's the risk that bfloat16 is a fad and five years from now it is used hardly at all. At best it is for a full stack perception-and-synthesis feature about as good as

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

Most of all it drives me nuts that Intel is going down the fixed-length SIMD instruction route (going wider) where the instructions you write are specific to the structures of the processor you run on. Machines like the ILLIAC, Cray, and the vector processor for the 3090 mainframe would automatically chunk the work so that you didn't need to rewrite your code for a future wider model.

ARM is doing it the right way:

https://alastairreid.github.io/papers/sve-ieee-micro-2017.pd...

View on HN

It's a controversial opinion I've not heard anyone else express, but IMO variable-width vector instructions are the wrong approach, since they're optimizing for the easy cases and solving problems that don't matter much, like instruction counts.

Although x86's SIMD extensions have a bunch of crippling issues, fixed-width instructions are fundamentally more general because they work both for vectorizable length-N loops, and for the many, many cases where you have a fixed units of work that you can perform in parallel. If you design your architecture to depend on loops to extract full performance, you cut yourself off from many productive uses of vector instructions outside of loops, and make it more difficult to juggle cases where you have more than one loop dimension.

Upgrading to new architectures with longer supported vector lengths is best left to recompilation and variable-width vector libraries.

Wouldn't be the first of Intel's ISA extensions to be unsuccessful because of its limitations, look at MPX: https://intel-mpx.github.io/

> It is an awful lot of registers for a feature that few programs may use

I was just wondering what you could do with 8KiB of register memory, if you ignored the intent of the registers outright (assuming you can load/store to the classical registers from these registers).

Cache expanded cryptographic keys and tables entirely in registers for one...

AFAIK SIMD accelerated cipher implementations already mostly do it. For example, AES-NI based implementations of AES-128 and AES-192 keep round keys in XMM registers without reloading them during processing of blocks.

Intel reasons it's so massive that any way they decide to go is The Right Way and people will accommodate anything they do. So far, this is mostly true - we have code that takes different branches depending on the ISA extensions available, probably all the way down to x87.

I don't think that's how these features get developed. Someone who orders CPUs by the cubic meter comes to Intel and asks for a bfloat16 unit. Six years later, they ship one. I know for a fact this is how BMI came to exist.

Indeed. We should never think that we are Intel's (or AMD's or IBM's) customers. They have a very short list - Dell, Lenovo, HP and, more recently, Google, AWS, Facebook and some of these are procuring directly from TSMC.

Commodity GPU's and before that playstations were used by researchers for their excellent parallel computing performance. So the influences go both ways.

Thinking it over a bit more, there definitely are examples that seem to have been driven speculatively by Intel, and their application in industry is not clear. Optane is the one that strikes me as a thing that Intel decided they _could_ do, and then did. The companies where I have worked that considered Optane did so after Intel shipped it, they didn't do research that concluded they needed it before it existed. Also, I can't recall an instance where the TCO looked good for Optane.

But as for architectural extensions, there clearly are customers asking for these things, even TSX which has never worked.

Reply on news.ycombinator.com