Comment by graycat | Hacker News Reader

Comment by graycat | Hacker News Reader

Parent Full thread

> Compared to what?

A single core processor, of course.

> What does ordinary code mean?

Say, simple random sample of all the other code being run.

> VLIW has been around for a while

Yup. I never claimed otherwise.

> Itanium is probably the most famous "general purpose" example

Yup.

> and has failed to gain traction outside of GPUs and DSP (ie not "ordinary code").

Yup.

Still, yet again, over again, one more time, once again, VLIW can get 9:1 speedup.

Why mention this? Because the OP was talking about the challenges of getting faster computing. Well, if want faster computing, one approach, that, indeed, works on general purpose code, and gives ballpark 9:1 speedup is, and may I have the envelope please [drum roll, please], VLIW. Really new? Nope. Tried with Itanium? Yup. Works? Yup.

Bottom line -- we still have 9:1 speedup available to us.

Maybe an objection is that pay a factor of 24 in transistor count and electrical power but get only a factor of 9 in performance.

Not everyone knows about VLIW.

Where did I say something wrong?

Citing a paper from the mid 90s isn't a credible answer in 2016.

All VLIW does is move a lot of on-chip logic off-chip into the compiler. This only works for a small set of computing tasks - which is why the closest thing we have to VLIW today lives in GPUs. And why Itanium was nicknamed Itanic.

It's a non-starter for general computing because as soon as you start dealing with real-time conditions the compiler can't optimise in advance, the speed advantage turns into a speed penalty.

IIRC the 9:1 worked for the IBM 370 instruction set on general purpose code. Kemal was across the hall from me at Watson and explained it.

Yes, the compiler is involved. So what?

> Citing a paper from the mid 90s isn't a credible answer in 2016.

I think it's unfair to generalize from VLIW to everything published 20+ years ago. Plenty of the things discovered back then, or earlier, are still applicable and in production today. Your compiler picked most of its low hanging fruit ages ago. Lots of PhD theses are rehashing old ideas, often unknowingly. Results are results, what matters more is whether there's a relevant context, as you've highlighted.

> It's a non-starter for general computing because as soon as you start dealing with real-time conditions the compiler can't optimise in advance, the speed advantage turns into a speed penalty.

"Real time"? What?

VLIW is just a way of achieving instruction level parallelism. That 9:1 speed-up is vs a single issue, in-order core, which PCs haven't used since the mid-90s. Modern superscalar processors can not only handle multiple instructions in parallel, but extensions like AVX allow very wide instructions for embarrassingly parallel things like matrix operations. We've probably achieved 95% of the theoretical speedup from amazing VLIW.

So, just when did we get that 8:1 or 9:1 speedup without having the processor clocks run faster. IBM was doing speculative execution, branch prediction, out of order execution, and vector instructions also in the 1990s. There were careful instruction level traces of the advantages and speedups. Of course, vector instructions are for special purpose code, e.g., the ubiquitous inner products in linear algebra, probability, and digital filtering, but 9:1 was on general purpose code.

IIRC, the instruction traces didn't show 9:1 or anywhere near that.

Both mechagodzilla and TheOtherHobbes have pretty much covered my response. The only thing I wanted to add was that you're acting incredibly defensive to essentially a request for context. The 9:1 speedup you quoted doesn't exist in a vacuum (and repeating the phrase "general purpose code" doesn't fix that.)

We all know quite well what "general purpose code" is.

I'm sorry about Itanium, but VLIW has to remain a possible path to faster cores. That my information is old does not mean it is wrong: The guy got 9:1 speedup on 24-way VLIW. Saying that the tricks of branch prediction, out of order execution, speculative execution, register renaming, etc. make VLIW forever obsolete is shaky without some solid references.

Moreover, if we want faster cores, then obvious, right in front of us, are two possibilities: (1) Design instruction sets that make VLIW easier to do and more productive. (2) Integrate and coordinate up and down the stack, that is, from application, e.g., collection classes, string operations, function calling, memory management, exceptional condition handling, to compilers to instructions to VLIW to the gate level logic and look for speedups. E.g., the now famous instruction sets look like they were designed for assembly language programming, and likely no compiler makes good use of all the instructions. E.g., C code, supposedly fast, forces the programmer to do the multidimensional array indexing arithmetic themselves, and to the machine language it all looks like normal work. In fact, that addressing is necessarily ubiquitous across computing, so maybe have an instruction for it. Same for string compare -- the usual C approach is just comparing one character at a time in a loop -- bummer.

In tool making, a key is to design the right tools. Else end up with a huge toolbox where most of the tools are used little or not at all. IMHO, we are still looking for the right tools in the stack from logic gates to microcode, register sets, instructions, caches, compilers, and applications. Then, VLIW in some form needs to be kept in mind.

Reply on news.ycombinator.com