Hacker News Reader

Comment by jackyinger | Hacker News Reader

WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it. Which sinks the x86 binary portability that we've all come to know and love. Which leads to the fundamental ease that ubiquity brings to working with x86 as an end user or any software dev that doesn't really care about processor internals.

It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition I doubt they will provide it. SIMD as used by GPUs is useful only when you have very structured parallelism like arithmetic on large data sets.

I think if we're going to see a challenger worth noting they'll look like they're crazy with the hard uphill battle and novel tech they will have to produce.

View on HN

If you're looking for innovation on vector operations (i.e. not packed SIMD or GPU-style SPMD), then RISC-V's vector extension (especially if you consider extensions to it for graphics or scientific compute or machine learning) should seem very promising. It's not technically groundbreaking (Cray did it first), but I think it has more potential than the endless treadmill of wider packed SIMD instructions (which dissipate an immense amount of power on intel's hardware), and it is amenable to more general tasks than SPMD is.

I assumed they just went for parity since they were on smaller budgets. You're saying they did something clever with a Cray reference. Could you elaborate on that?

Well, that was the subject of Krste's thesis at Berkeley:

Vector Microprocessors

https://people.eecs.berkeley.edu/~krste/thesis.html

I wasn't aware that it was his thesis, thanks for pointing that out. There's also all the work on the Xhwacha RoCC (which I knew prof. Asanović was involved with). I think it all looks very promising and makes me eager to see what comes out of SiFive with Yunsup and Krste at or near the helm.

> WRT Itanium and all VLIW processors for that mater, you have to compile for the microarchitecture of the processor to fully take advantage of it

True of course, but Itanium did think of this and had an "abstracted" VLIW where you worked with generic instruction bundles which the hardware was then more free to pull apart in different ways underneath. I do wonder, if we'd all taken a different path, if we'd be in more of a JIT-compiled type world. who knows?

We are in a JIT world, it's just that the code is running on the IVM ("Intel Virtual machine) being interpreted by intel's microcode.

>"It sure would be interesting to see something else challenge x86, but since ARM/Power/RISC-V are all within the same architectural tradition"

Can you elaborate on what you mean by "architectural tradition"? I am not familiar with this term. What is the commonality of all those different architectures?

There are three main conventional instruction set architectures: RISC, CISC, and VLIW.

ARM/Power/MIPS/RISC-V are all examples of a reduced instruction set architecture, RISC.

Of course, I completely misread that. I thought the OP was including the x86(which is obviously CISC) in that. Thanks.

Actually I was, CISC and RISC are both Von Neumann machines. ISA has more to do with encoding these days anyway.

Basically, despite how sophisticated the CPU of these machines becomes it is still trying to make the appearance of executing instructions in sequence.

Current x86 processors can execute many instructions in parallel under the correct conditions leading to Instructions Per Clock (IPC) greater much than one. However typical IPC hovers around 1 and some change, unless a lot of optimization effort is invested.

In order execution of an instruction sequence (or the appearance to the user of it) is the bottleneck that has led to single threaded CPU speed increases to all but disappear now that CPU frequency scaling has more or less halted.

x86 stopped being a pure CISC long time ago.

Sure, everything now reduces to microcode and micro-ops that are completely RISC but in a historical context about CPU architecture X86 is the poster child for CISC.

I think that's all the OP was getting at.

> but in a historical context about CPU architecture X86 is the poster child for CISC

Rather the DEC VAX and perhaps MC68k are poster childs of CISC. For a discussion of RISC vs. CISC see

> http://userpages.umbc.edu/~vijay/mashey.on.risc.html

or its extended version

> http://yarchive.net/comp/risc_definition.html

and look at the tables there. You will see that among the processors on the "CISC side", the Intel i486 is nearer to RISC than many other CISC architectures.

Does the Mill architecture count as looking crazy enough?

Mill isn't too crazy from what I've seen, they seem acutely aware of the pitfalls of poor cache utilization and other things which were the bane of VLIW (outside of DSP). The future holds the truth on just how much that awareness translates into performance, but at least they're thinking a bit. The thing which concerns me about the Mill is the software-managed binary incompatibility between every model. They say this is manageable but I have some doubts about it, especially about how it plays with JITs.

They say that JITs will have to link to their proprietary system library in order to work, which seems like it could be devastating for uptake.

Reply on news.ycombinator.com