Hacker News Reader

Comment by btrask | Hacker News Reader

Yes, I do.

Turing completeness means that instruction sets simply do not matter. In fact, you cannot buy a "native" x86 processor today. Every modern x86 processor actually has hardware to run some highly optimized microcode instruction set, plus an x86 emulator in software that runs on top.

ARM is the current viable alternative to x86. You could put an ARM chip in a desktop and it would be cheaper and faster than RISC-V for the foreseeable future. RISC-V is even more experimental than that and it has nothing to offer even in theory. The only standard for an ISA is performance. Any other features can and should be built on top.

I set the bozo bit on anyone crowing about RISC-V. Don't get me started on the Mill, it's just a shitty GPU.

View on HN

It does matter!

* An open CPU ISA without the burdens of licenses means that more manufacturers can produce chips. This leads to healthy competition and more alternatives.

* Open designs make it easier for everyone to put together awesome new products.

* Simplicity and starting over with something that is not bloated means simpler compilers. No legacy means a clean design.

* Open source means that open source software could be recompiled for it. It is just another target so it does not really matter, unless you are running closed source software. If you are using open source software, the cost of switching to RISC-V is very small.

Regarding your argument about as long as there is one turing complete chip family, nothing matters: This argument is similiar to saying that since Windows exist and actually does work, and in theory does the same thing as Linux, then Linux does not need to exist. This argument is just moot. There are lots of arguments for running Linux instead of Windows, very much the same way that there are lots of arguments for running RISC-V instead of x86/ARM.

In the long run, RISC-V will take over, just like Linux once took over.

That Moore's Law has essentially ended probably also means that something like this probably is worth focusing on. It makes sense regarding to economy and optimization to redesign the CPUs now when we have reached this end of Moore's Law.

I'm going to nitpick.

Instruction sets matter as long as caches are fixed size. The real benefit of x86 is that the instruction encoding is very dense, making the L1 cache more effective.

There is not an x86 emulator in software. Microcode is not, and has never been, considered software. x86 needs a complicated decoder, and some infrequently used instructions can turn into hundreds of uops, but that doesn't make it an emulator.

There are ARM cores that use instruction cracking and uop fusion. That doesn't mean it's an ARM emulator on top of a highly optimized microcode instruction set. It's an implementation detail.

I think you're just arguing it doesn't solve problems that it never claimed to solve.

It's just an ISA, not an implementation design, yes. What's wrong with a nicely designed new, extensible, royalty-free ISA? Seems like a useful thing to me.

Please explain why you feel the Mill is "just a shitty GPU"

GPUs are the state of the art in massively parallel processors. If you are building a parallel processor, it should be evaluated as a GPU to see how it stands up. For example, Larabee was tried as a GPU and found wanting.

But the Mill is explicitly designed to be a superscalar CPU replacement...

Uh... not really.

Historically, the design of GPUs are essentially about having extremely high data-parallelism of relatively tiny, simple codes (shaders) that all operate on the same massive data unit but have very little communication. The tradeoffs that get involved in making this code means that GPUs are effective at speeding up only certain kinds of computations. Workloads that are memory-latency bound or communication heavy--such as a BFS graph traversal--turn out to be utter crap on GPUs, and you can only claw back some of that performance with epic engineering effort.

Larrabee and its successor Xeon Phi concepts were actually fairly well-received in terms of giving you something that could tackle non-GPU-amenable problems. What caused Larrabee to suffer was that Intel basically tried to flog a "just write C/C++/Fortran and the autovectorizer will take care of everything" model for programming which, well, didn't work (as many compiler people could have predicted for you before you started). Nvidia also made sure to do a massive push to get CUDA working in terms of library support, educational cooperation, and language flogging to get people interested into CUDA, which Intel didn't attempt for Xeon Phi.

>What caused Larrabee to suffer was that Intel basically tried to flog a "just write C/C++/Fortran and the autovectorizer will take care of everything" model for programming which,

This reminds me of the story of ispc [1] One guy wrote a compiler based on SPMD while the rest of the company was focused on the doomed auto vectorization.

[1] http://pharr.org/matt/blog/2018/04/30/ispc-all.html

That was one of the sources I used for the comment.

> The only standard for an ISA is performance.

That is so incredible wrong that its almost funny that somebody actually believes that.

I'll give you a simple proof by appeal to absurdity: Single instruction-set computers totally do exist, but perform very poorly. So clearly, the ISA does matter in the extreme ends.

That said, it is true that the data processing features available in modern ISA's have largely converged towards each other. ARM, Power, and x86 all have instructions for popcount, leading zero count, byte reversal, and efficient multiword arithmetic. ARMv8 and x86 both have multiplication in GF(2), too.

RISC-V doesn't have any of those things. And while its true that the vast majority of program code out there doesn't use it directly, the vast majority of total systems do use them somewhere important. Modern schedulers and memory allocators rely on fast leading zero count. Crypto codes rely on GF(2) and multiword arithmetic. Anything dealing with network packet processing needs low-latency byte reversal, and so on.

RISC-V's failure to include those features in the general-purpose profile will absolutely hurt its adoption for general-purpose compute.

Of course the ISA matters in the extrem but once some commen patterns are covered the changes are only lead to tiny further improvments.

RISC-V failure to include these feature was very diliberate because only feature that everybody needs are in the base ISA.

The feature you ask for will be in the 'B' extention that will be standardised soon and will probebly become part of many standard profiles.

You make good points but have not addressed the issue of licensing.

It's not clear to me that raw ISAs can be copyrighted or patented. Worst case there is clean room reverse engineering. Emulators are legal.

AFAIK intel threatened to sue someone who was implementing an x86 emulator on top of an arm chip. I think emulators are legal because they're not in hardware and so not infringing on intel's market space?

It might not be clear to you but it is very clear to Intel and ARM.

There are tons of patents out there for the circuits which efficiently implement some instructions. Most of those patents have expired by now, but new ones pop up every once in a while. One recent example would be the circuit which computes steering bits for implementing pext and pdep on a butterfly network.

There are also plenty of patents for particular descriptions of instructions. They may be fairly narrow in scope, depending on how close they are to prior art. But they don't have to be particularly wide in scope in order to prevent cloning. It would not surprise me at all if the x86's encoding choice for `reg + reg * scale + displacement` was patented.

Emulators can absolutely require licenses. The ARM emulator shipped with Android for x86 is licensed by ARM, for example. While there aren't very many (uh, any at all?) x86 phones, x86 Chromebooks with Android support is a thing.

Reply on news.ycombinator.com