Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's no free parallelism™️ though.

> Author: AgnerDate: 2015-12-28 01:46

> Ethan wrote:

> > Agner, what's your opinion on the Itanium instruction set in isolation, assuming a compiler is written and backwards compatibility do not matter?

> The advantage of the Itanium instruction set was of course that decoding was easy. The biggest problem with the Itanium instruction set was indeed that it was almost impossible to write a good compiler for it. It is quite inflexible because the compiler always has to schedule instructions 3 at a time, whether this fits the actual amount of parallelism in the code or not. Branching is messy when all instructions are organized into triplets. The instruction size is fixed at 41 bits and 5 bits are wasted on a template. If you need more bits and make an 82 bit instruction then it has to be paired with a 41 bit instruction.

(https://www.agner.org/optimize/blog/read.php?i=425)

Besides, the memory consistency model of Itanium is also a brain teaser used in interviews as counterexamples to poorly-synchonized solutions.



Agner is obviously brilliant, but I think maybe he's looking at general purpose applications.

If I'm doing a million point FFT, I can easily give you 2 million operations in a row without a loop/branch. Maybe 1000 of those at a time could be run in parallel before the results needed to commit for the next 1000. I'd be willing to pay for 1 or 2 nops in the last bundle of every 1000 operations. I admit, the idea might not be awesome for a word processor or spreadsheet, but I did specify signal processing and machine learning.


A common complaint about Itanium was that it was an overpriced DSP masquerading as general purpose CPU.


I actually kind of like that characterization :-)


For signal processing and machine learning, maybe you'd be better off with a systolic array processor or at least a bunch of deep Cray-style vector pipelines? And, like you said, GPUs seem to be doing better at those, in a vaguely Tera-like way, than the Itanic ever could have.


I never got to play on a Cray, but I remember working on a Convex for a couple semesters in school. I had no idea what I was doing back then.

Nowdays, it's pretty clear GPUs are the winner, but like I said, they just don't feel like you actually live and breath inside of them the way you do with CPU code (you shuffle your data over and shuffle it back), and I'm kind of just imagining an alternative timeline where Intel and compiler writers got a chance to run with the EPIC idea.


The dark silicon era will presumably also be the heterogeneous hardware era.


> I admit, the idea might not be awesome for a word processor or spreadsheet,

Or a web server or browser. In fact, it pretty much only helps for your use case. Which is why people are converging on specialised hardware for it, and why Itanium was a commercial failure.


The computationally heavy part of a web browser is the rendering/video engine, which is standard super parallel graphics stuff. Web servers are dominantly I/O (or running wastefully slow scripting languages).

I know it's all a fantasy now, but I wonder what the world might have been like if there wasn't such a split between what you can only do on a CPU and what you can only do on a GPU. Maybe you like heterogeneous computing and gluing C++ to CUDA, but I think it's ugly. Stretch outside of the current box a little bit and imagine a hybrid somewhere in the middle ground of CPUs and GPUs. I think a variable sized VLIW could've gotten there if the market had any more imagination than it does. It's Ford's "faster horses" problem.


Check Xeon Phi (not VLIW though), which executes unmodified amd64 instructions on many cores. However it never becomes a mainstream product and Intel recently killed it. There are many reasons behind its sunset - tooling, programming difficulty to reach max throughput, perf/cost ratio, ...

Related discussion: https://news.ycombinator.com/item?id=17606037




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: