16 ms·

I'm not a computer architect (so my opinion shouldn't count in this thread), but as someone who did a lot of numerical programming over the years, I really thou

by xscott 7y ago

I'm not a computer architect (so my opinion shouldn't count in this thread), but as someone who did a lot of numerical programming over the years, I really thought Itanium looked super promising. The idea that you can indicate a whole ton of instructions can be run in parallel seemed really scalable for FFTs and linear algebra. Instead of more cores, give me more ALUs. I know "most" software doesn't have enough work between branches to fill up that kind of pipeline, but machine learning and signal processing can certainly use long branchless basic blocks if you can fit them in icache. At the time, it seemed (to me at least) that it really only died because the backwards compatibility mode was slow. (I think some of the current perception of Itanium is revisionist history.) It's tough to say what it could've become if AMD64 hadn't eaten it's lunch by running precompiled software better. It would've been interesting if Intel and compiler writers could've kept focus on it. Nowdays, it's obvious GPUs are the winners for horsepower, and it's telling that we're willing to use new languages and strategies to get that win. However, GPU programming really feels like you're locked outside of the box - you shuffle the data back and forth to it. I like to imagine a C-like language (analogous to CUDA) that would pump a lot of instructions to the "Explicitly Parallel" architecture. Now we're all stuck with the AMD64 ISA for our compatibility processor, and it seems like another example where the computing world isn't as good as it should be.

sansnomme 7y ago
That C like language is called "Verilog". (Yes I know it's a HDL but the point still stands. FPGAs are commodity these days.)
- xscott 7y ago
  Heh, I suspect hardware folks would like a CPU which programmed well with Verilog or VHDL, and I know that trying to make a hardware description language accessible to software folks has been a pipe dream for at least 25 years. However, I don't think Verilog was the solution for Itanium, and the useful niche for FPGAs seems increasingly limited to low Size Weight And Power realms. The FPGA projects I've seen (using very high end FPAGs, not commodity/cheap ones) seem like they're always bumping up against clock rates and making timing as soon as they try to do anything approaching what you can do on a CPU or GPU. Of course there are exceptions where the FPGA does really simple and parallel things, but FPAGs aren't a panacea.
  - sansnomme 7y ago
    There was a company called reconfigure.io that came the closest to an accessible HDL (they compiled Go to VHDL/Verilog) but seems to have died and their founder is now with ARM.
    - xscott 7y ago
      I recently worked with another company trying to solve the same problem, but I suspect I should keep my mouth shut due to NDA crap. Regardless, I suspect we're easily another decade out before anyone makes FPGAs accessible to the masses, and I can't think of many problems where I would take an FPGA over a GPU, but there are still some.
- krupan 7y ago
  Verilog isn't really very c-like. It is slightly more c-like than jts main competitor, VHDL. It is more c-like than lisp. But really, neither of those is saying much. Ways it is not c-like: - begin...end instead of curly braces - parallelism with assign, always, initial - tasks and functions and their subtle differences - non-blocking assignment - bit-oriented variables and operations - 4-state logic (0, 1, X, Z) - other constructs for modeling hardware like time delays, tri-state wires, drive strengths, etc. Not to mention that SystemVerilog has taken over Verilog and adds OOP with classes, a complicated (sorry, powerful) assertion mini-language, constrained randomization, a streaming operator, and so on.
- esmi 7y ago
  Or you could prototype the algorithm in matlab then convert to HDL. https://www.mathworks.com/products/hdl-coder.html https://www.mathworks.com/products/hdl-coder.html
acomjean 7y ago
I worked on a project with machines that used the pa-risc cpus. The importance of optimized compilers can’t be understated (and math libraries) which made those machines really shine. My understanding was the Itanium (which basically replaced pa-risc in hp Unix machine lineup) never got the compiler support to realize the architectures strengths, so everyone looked to the safer bet in 64bit computing. It’s hard to compete with the scale of x86. Like software I feel the industry tends toward one architecture (the more people use the architecture the better the compilers the more users ...) Even Apple abandoned PowerPC chips.
- xscott 7y ago
  If anyone stood a chance to compete against x86, I'd think Intel would be it :-)
  - kjs3 7y ago
    But Intel failed here with the same mistake they've made many times before: the people who actually buy Intel kit basically want a faster 8088/80386/Pentium, not a novel, cleaner, sexier new architecture. See: iAXP432, i860, i960Mx and recently Itanium. Linux Torvald has an interesting take on this (whether or not you agree): https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html
    - xscott 7y ago
      I think Linus is very focussed on the stuff he cares about, and that shows by his complaint about PAE, which is pretty invisible to use userland folk. > the people who actually buy Intel kit basically want a faster 8088/80386/Pentium My company is small fries compared to most folks, but what we really wanted at the time was cheaper DEC Alphas.
      - kjs3 7y ago
        I think Linus is very focussed on the stuff he cares about I think he'd be the first to agree with that. PAE, which is pretty invisible to use userland folk Perhaps, but the original conversation is about architecture, and PAE was a pretty grungy architectural wart, and the sort of thing that's very visible to the OS folks (as you say, what Linus cares about). we really wanted at the time was cheaper DEC Alphas There were 'cheap' Alphas: the 21066/21068 like in the Multia. But they were dogs; to be cheap, they had to give up big cache and wide paths to main memory. Expensive system support level stuff was required for fast Alphas (complex support chipsets, 128-bit wide (later 256-bit) memory buses). More commodity inertia would have fixed that over time, but they never got there. Intel on the other hand was way down the road reaping commodity benefits, and it ran the software commodity folks wanted.
htfy96 7y ago
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 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.
- xscott 7y ago
  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.
  - kragen 7y ago
    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.
    - xscott 7y ago
      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.
jcranmer 7y ago
Itanium is essentially a VLIW architecture and... well, as the bottom of the page mentions, VLIW architectures tend to turn out to be bad ideas in practice. GPUs showed two things: one, you can relegate kernels to accelerators instead of having to maximize performance in the CPU core; and two, you can convince people to rewrite their code, if the gains are sufficiently compelling.
- cpr 7y ago
  Specifically, the promise of VLIWs (scalar parallelism) was overhyped--the Multiflow compiler couldn't find enough scalar parallelism in practice to keep all 28 ALUs busy (in the widest model we built), or even all 7 ALUs (in the narrowest). (I ended up running the OS group at Multiflow before bailing right before they hit the wall.)
  - zozbot234 7y ago
    We need new programming models that make it easier to expose static parallelism to the compiler. Doing it all in plain old C/C++, or even in "managed" VM-based languages, cannot possibly work - and even conventional multi-threading is way too coarse-grained by comparison to what's most likely needed. Something based on a dataflow-oriented description of the code would probably work well, and be possible to integrate well enough with modern functional-like paradigms.
    - pdimitar 7y ago
      I reached the same conclusion. We need a way to be able to explicitly say "this piece of code here is a standalone unit that is independent of everything else until we have to coalesce results of computation", or "this unit manages those other units and coalesces their results". Erlang's OTP captures this pretty okay-ish with their concept of processes (preemptively scheduled green threads that get aggressively multiplexed on all CPU cores) but I feel we can go a little bit further than that and have some sort of shorter markers in the code, say `actor { ... }` or `supervises(a1, a2, a3) { ... }` or something.
    - 7y ago
titzer 7y ago
15 years ago I thought Itanium was the coolest thing ever. As a compilers student, a software scheduled superscalar processor was kind of like a wet dream. The only problem is that that dream never materialized, due a number of reasons. First, compilers just could never seem to find enough (static) ILP in programs to fill up all the instructions in a VLIW bundle. Integer and pointer-chasing programs are just too full of branches and loops can't be unrolled enough before register pressure kills you (which, btw, is why Itanium had a stupidly huge register file). Second, it exposes microarchitectural details that can (and maybe should) change quite rapidly. The width of the VLIW is baked into the ISA. Processors these days have 8 or even 10 execution ports; no way one could even have space for that many instructions in a bundle. Third, all those wasted slots in VLIW words and huge 6-bit register indices take up a lot of space in instruction encodings. That means I-cache problems, fetch bandwidth problems, etc. Fetch bandwidth is one of the big bottlenecks these days, which is why processors now have big u-op caches and loop stream detectors. Fourth, there are just too many dynamic data dependencies through memory and too many cache misses to statically schedule code. Code in VLIW is scheduled for the best case, which means a cache miss completely stalls out the carefully constructed static schedule. So the processor fundamentally needs to go out of order to find some work (from the future) to do right now, otherwise all those execution units are idle. If you are going out of order with a huge number of execution ports, there is almost no point in bothering with static instruction scheduling at all. (E.g. our advice from Intel in deploying instruction scheduling for TurboFan was to not bother for big cores--it only makes sense on Core and Atom that don't have (as) fancy OOO engines). There is one exception though, and that is floating point code. There, kernels are so much different from integer/pointer programs that one can do lots of tricks from SIMD to vectors to lots of loop transforms. The code is dense with operations and far easier to parallelize. The Itanium was a real superstar for floating point performance. But even there I think a lot of the scheduling was done by hand with hand-written assembly.
- xscott 7y ago
  > There is one exception though, and that is floating point code. I wish I had read to the end before replying (and then deleting) responses to each of your items. :-) I think we're mostly in agreement, except for the following minor tidbits: > The width of the VLIW is baked into the ISA [...] no way one could even have space for that many instructions in a bundle. My understanding was that your software/compiler could indicate as many instructions as possible in parallel, and then stuff a "stop" into the 5 bit "template" to indicate the previous batch needed to commit before proceeding. So, you wouldn't be limited to 3 instructions per bundle, and if done well (hopefull), your software would automatically run faster as the next generation comes out and has more parallel execution units. > all those wasted slots in VLIW words and huge 6-bit register indices take up a lot of space in instruction encodings 128 registers, so I'd think it'd be 7 bit indices. Each instruction was 41 bits, which is roughly 5 bytes. Most SSE/AVX instructions end up being 4-5 bytes (assuming no immediates or displacements), and that's for just 4 bit register indices. So it doesn't seem much worse than we have now.
nwallin 7y ago
> Instead of more cores, give me more ALUs. It kinda didn't work that way though. In practice, all of your ALUs, including your extra ones, were waiting on cache fetches or latencies from previous ALU instructions. Modern x86 CPUs have 2-4 ALUs which are dispatched to in parallel 4-5 instructions wide, and these dispatches are aware of cache fetches and previous latencies in real time. VLIW can't compete here. VLIW made sense when main memory was as fast as CPU and all instructions shared the same latency. History hasn't been kind to these assumptions. I doubt we'll see another VLIW arch anytime soon. I accept the idea that x86 is a local minimum, but it's a deep, wide one. Itanium or other VLIW architectures like it were never deep enough to disrupt it.
- xscott 7y ago
  > In practice, all of your ALUs, including your extra ones, were waiting on cache fetches I think if anyone could get around memory bandwidth problems they would, but for some very interesting and useful algorithms, I can tell you way in advance exactly when I'll need each piece of memory. For these problems, VLIW/EPIC with prefetch instructions would be a win over all the speculation and cleverness. > Itanium or other VLIW architectures like it were never deep enough to disrupt it. History is what it is, but I'm just imagining an alternative timeline where all the effort spent making Pentium/AMD64 fast was pumped into Itanium instead, and compiler writers and language creators got to target an architecture that didn't act like a 64 bit PDP-11.
  - zozbot234 7y ago
    Are these sorts of prefetch instructions widely supported in VLIW, though? AIUI, one of the "tricks" the Mill folks had to come up with as part of designing a generally-usable VLIW-like architecture, is making RAM accesses inherently "async", making it easy to statically-schedule other instructions in case the RAM access stalls.
  - derefr 7y ago
    Rather than individual-memory-address prefetch instructions, how would you feel about sending a DMA program to a controller on-board a memory DIMM, that would then enable you to send short external commands to the memory that would be translated by the DMA program into custom “vector requests”, to which the memory could respond with long streams of fetch responses—shaped somewhat like the output of a CCD’s shift-register—where this stream of fetch responses would then entirely overwrite the calling CPU’s cache lines with the retrieved values?
yongjik 7y ago
I don't think x86 compatibility mattered. When it launched in 2001 it was supposed to replace HP's PA-RISC architecture which is totally different anyway. Sun and its SPARC processors were very much alive, Google was only three years old, and AWS was five years away - the idea that a massive array of cheap x86 processors will outperform enterprise-class servers simply hadn't occurred to most people yet. Of course, the joke is that cheap x86 processors did outperform Itanium (and every other architectures, eventually).
- xscott 7y ago
  > I don't think x86 compatibility mattered. I'll admit I had a limited worldview, but not running Excel as quickly seemed like the kind of criticisms I saw in the trade rags at the time. > the idea that a massive array of cheap x86 processors will outperform enterprise-class servers simply hadn't occurred to most people yet Oh, I don't know. There was a really common Slashdot cliche running around at that time: "Can you imagine a Beowulf cluster of these?"
  - kragen 7y ago
    Yeah, it had clearly occurred to everyone on Slashdot. On the other hand, we liked to "imagine Beowulf clusters" of all kinds of recondite hardware. Elbrus 2000 is real power! HOT GRITS!
    - bloopernova 7y ago
      /. was another world, one that I miss sometimes. I'm probably viewing it through rose-tinted nostalgia, but I don't remember the vitriol and hatred that so many social sites are soaked in these days. The Mozilla open source announcement, the Microsoft anti-trust case, Linux exploding in popularity, it all felt like we were changing the world for the better.
      - AnimalMuppet 7y ago
        /. was great... and then it wasn't. The troll population went way up, the "first post" thing was just noise, and eventually I just quit going there. HN is also less than it used to be, but I think that the mods have kept it better than /. became - so far, at least.
gnufx 7y ago
That seems right on such important sorts of computation, disregarding other factors. On the history, actual HPC numbers for Itanium have appeared in the Infamous Annual Martyn Guest Presentation over the years. An example that came to hand from 15 years ago to compare with bald statements is is https://www.researchgate.net/profile/Martyn_Guest/publication/30416847_Performance_of_Various_Computers_in_Computational_Chemistry/links/0046352471d0d1cd54000000.pdf https://www.researchgate.net/profile/Martyn_Guest/publicatio... Regarding GPUs, Fujitsu may not agree (for Fugaku and spin-offs) depending on the value of "horsepower" relevant for HPC systems, even if an A64FX doesn't have the peak performance of a V100. They have form from the K Computer, and if they basically did it themselves again, there was presumably "co-design" for the hardware and software which may be relevant here; I haven't seen anything written about that, though.

by xscott 7y ago

sansnomme 7y ago

That C like language is called "Verilog". (Yes I know it's a HDL but the point still stands. FPGAs are commodity these days.)

xscott 7y ago
Heh, I suspect hardware folks would like a CPU which programmed well with Verilog or VHDL, and I know that trying to make a hardware description language accessible to software folks has been a pipe dream for at least 25 years. However, I don't think Verilog was the solution for Itanium, and the useful niche for FPGAs seems increasingly limited to low Size Weight And Power realms. The FPGA projects I've seen (using very high end FPAGs, not commodity/cheap ones) seem like they're always bumping up against clock rates and making timing as soon as they try to do anything approaching what you can do on a CPU or GPU. Of course there are exceptions where the FPGA does really simple and parallel things, but FPAGs aren't a panacea.
- sansnomme 7y ago
  There was a company called reconfigure.io that came the closest to an accessible HDL (they compiled Go to VHDL/Verilog) but seems to have died and their founder is now with ARM.
  - xscott 7y ago
    I recently worked with another company trying to solve the same problem, but I suspect I should keep my mouth shut due to NDA crap. Regardless, I suspect we're easily another decade out before anyone makes FPGAs accessible to the masses, and I can't think of many problems where I would take an FPGA over a GPU, but there are still some.
krupan 7y ago
Verilog isn't really very c-like. It is slightly more c-like than jts main competitor, VHDL. It is more c-like than lisp. But really, neither of those is saying much. Ways it is not c-like: - begin...end instead of curly braces - parallelism with assign, always, initial - tasks and functions and their subtle differences - non-blocking assignment - bit-oriented variables and operations - 4-state logic (0, 1, X, Z) - other constructs for modeling hardware like time delays, tri-state wires, drive strengths, etc. Not to mention that SystemVerilog has taken over Verilog and adds OOP with classes, a complicated (sorry, powerful) assertion mini-language, constrained randomization, a streaming operator, and so on.
esmi 7y ago
Or you could prototype the algorithm in matlab then convert to HDL. https://www.mathworks.com/products/hdl-coder.html https://www.mathworks.com/products/hdl-coder.html

acomjean 7y ago

I worked on a project with machines that used the pa-risc cpus. The importance of optimized compilers can’t be understated (and math libraries) which made those machines really shine. My understanding was the Itanium (which basically replaced pa-risc in hp Unix machine lineup) never got the compiler support to realize the architectures strengths, so everyone looked to the safer bet in 64bit computing. It’s hard to compete with the scale of x86. Like software I feel the industry tends toward one architecture (the more people use the architecture the better the compilers the more users ...) Even Apple abandoned PowerPC chips.

xscott 7y ago
If anyone stood a chance to compete against x86, I'd think Intel would be it :-)
- kjs3 7y ago
  But Intel failed here with the same mistake they've made many times before: the people who actually buy Intel kit basically want a faster 8088/80386/Pentium, not a novel, cleaner, sexier new architecture. See: iAXP432, i860, i960Mx and recently Itanium. Linux Torvald has an interesting take on this (whether or not you agree): https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html
  - xscott 7y ago
    I think Linus is very focussed on the stuff he cares about, and that shows by his complaint about PAE, which is pretty invisible to use userland folk. > the people who actually buy Intel kit basically want a faster 8088/80386/Pentium My company is small fries compared to most folks, but what we really wanted at the time was cheaper DEC Alphas.
    - kjs3 7y ago
      I think Linus is very focussed on the stuff he cares about I think he'd be the first to agree with that. PAE, which is pretty invisible to use userland folk Perhaps, but the original conversation is about architecture, and PAE was a pretty grungy architectural wart, and the sort of thing that's very visible to the OS folks (as you say, what Linus cares about). we really wanted at the time was cheaper DEC Alphas There were 'cheap' Alphas: the 21066/21068 like in the Multia. But they were dogs; to be cheap, they had to give up big cache and wide paths to main memory. Expensive system support level stuff was required for fast Alphas (complex support chipsets, 128-bit wide (later 256-bit) memory buses). More commodity inertia would have fixed that over time, but they never got there. Intel on the other hand was way down the road reaping commodity benefits, and it ran the software commodity folks wanted.

htfy96 7y ago

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 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.

xscott 7y ago
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.
- kragen 7y ago
  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.
  - xscott 7y ago
    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.

jcranmer 7y ago

Itanium is essentially a VLIW architecture and... well, as the bottom of the page mentions, VLIW architectures tend to turn out to be bad ideas in practice. GPUs showed two things: one, you can relegate kernels to accelerators instead of having to maximize performance in the CPU core; and two, you can convince people to rewrite their code, if the gains are sufficiently compelling.

cpr 7y ago
Specifically, the promise of VLIWs (scalar parallelism) was overhyped--the Multiflow compiler couldn't find enough scalar parallelism in practice to keep all 28 ALUs busy (in the widest model we built), or even all 7 ALUs (in the narrowest). (I ended up running the OS group at Multiflow before bailing right before they hit the wall.)
- zozbot234 7y ago
  We need new programming models that make it easier to expose static parallelism to the compiler. Doing it all in plain old C/C++, or even in "managed" VM-based languages, cannot possibly work - and even conventional multi-threading is way too coarse-grained by comparison to what's most likely needed. Something based on a dataflow-oriented description of the code would probably work well, and be possible to integrate well enough with modern functional-like paradigms.
  - pdimitar 7y ago
    I reached the same conclusion. We need a way to be able to explicitly say "this piece of code here is a standalone unit that is independent of everything else until we have to coalesce results of computation", or "this unit manages those other units and coalesces their results". Erlang's OTP captures this pretty okay-ish with their concept of processes (preemptively scheduled green threads that get aggressively multiplexed on all CPU cores) but I feel we can go a little bit further than that and have some sort of shorter markers in the code, say `actor { ... }` or `supervises(a1, a2, a3) { ... }` or something.
  - 7y ago

titzer 7y ago

15 years ago I thought Itanium was the coolest thing ever. As a compilers student, a software scheduled superscalar processor was kind of like a wet dream. The only problem is that that dream never materialized, due a number of reasons. First, compilers just could never seem to find enough (static) ILP in programs to fill up all the instructions in a VLIW bundle. Integer and pointer-chasing programs are just too full of branches and loops can't be unrolled enough before register pressure kills you (which, btw, is why Itanium had a stupidly huge register file). Second, it exposes microarchitectural details that can (and maybe should) change quite rapidly. The width of the VLIW is baked into the ISA. Processors these days have 8 or even 10 execution ports; no way one could even have space for that many instructions in a bundle. Third, all those wasted slots in VLIW words and huge 6-bit register indices take up a lot of space in instruction encodings. That means I-cache problems, fetch bandwidth problems, etc. Fetch bandwidth is one of the big bottlenecks these days, which is why processors now have big u-op caches and loop stream detectors. Fourth, there are just too many dynamic data dependencies through memory and too many cache misses to statically schedule code. Code in VLIW is scheduled for the best case, which means a cache miss completely stalls out the carefully constructed static schedule. So the processor fundamentally needs to go out of order to find some work (from the future) to do right now, otherwise all those execution units are idle. If you are going out of order with a huge number of execution ports, there is almost no point in bothering with static instruction scheduling at all. (E.g. our advice from Intel in deploying instruction scheduling for TurboFan was to not bother for big cores--it only makes sense on Core and Atom that don't have (as) fancy OOO engines). There is one exception though, and that is floating point code. There, kernels are so much different from integer/pointer programs that one can do lots of tricks from SIMD to vectors to lots of loop transforms. The code is dense with operations and far easier to parallelize. The Itanium was a real superstar for floating point performance. But even there I think a lot of the scheduling was done by hand with hand-written assembly.

xscott 7y ago
> There is one exception though, and that is floating point code. I wish I had read to the end before replying (and then deleting) responses to each of your items. :-) I think we're mostly in agreement, except for the following minor tidbits: > The width of the VLIW is baked into the ISA [...] no way one could even have space for that many instructions in a bundle. My understanding was that your software/compiler could indicate as many instructions as possible in parallel, and then stuff a "stop" into the 5 bit "template" to indicate the previous batch needed to commit before proceeding. So, you wouldn't be limited to 3 instructions per bundle, and if done well (hopefull), your software would automatically run faster as the next generation comes out and has more parallel execution units. > all those wasted slots in VLIW words and huge 6-bit register indices take up a lot of space in instruction encodings 128 registers, so I'd think it'd be 7 bit indices. Each instruction was 41 bits, which is roughly 5 bytes. Most SSE/AVX instructions end up being 4-5 bytes (assuming no immediates or displacements), and that's for just 4 bit register indices. So it doesn't seem much worse than we have now.

nwallin 7y ago

> Instead of more cores, give me more ALUs. It kinda didn't work that way though. In practice, all of your ALUs, including your extra ones, were waiting on cache fetches or latencies from previous ALU instructions. Modern x86 CPUs have 2-4 ALUs which are dispatched to in parallel 4-5 instructions wide, and these dispatches are aware of cache fetches and previous latencies in real time. VLIW can't compete here. VLIW made sense when main memory was as fast as CPU and all instructions shared the same latency. History hasn't been kind to these assumptions. I doubt we'll see another VLIW arch anytime soon. I accept the idea that x86 is a local minimum, but it's a deep, wide one. Itanium or other VLIW architectures like it were never deep enough to disrupt it.

xscott 7y ago
> In practice, all of your ALUs, including your extra ones, were waiting on cache fetches I think if anyone could get around memory bandwidth problems they would, but for some very interesting and useful algorithms, I can tell you way in advance exactly when I'll need each piece of memory. For these problems, VLIW/EPIC with prefetch instructions would be a win over all the speculation and cleverness. > Itanium or other VLIW architectures like it were never deep enough to disrupt it. History is what it is, but I'm just imagining an alternative timeline where all the effort spent making Pentium/AMD64 fast was pumped into Itanium instead, and compiler writers and language creators got to target an architecture that didn't act like a 64 bit PDP-11.
- zozbot234 7y ago
  Are these sorts of prefetch instructions widely supported in VLIW, though? AIUI, one of the "tricks" the Mill folks had to come up with as part of designing a generally-usable VLIW-like architecture, is making RAM accesses inherently "async", making it easy to statically-schedule other instructions in case the RAM access stalls.
- derefr 7y ago
  Rather than individual-memory-address prefetch instructions, how would you feel about sending a DMA program to a controller on-board a memory DIMM, that would then enable you to send short external commands to the memory that would be translated by the DMA program into custom “vector requests”, to which the memory could respond with long streams of fetch responses—shaped somewhat like the output of a CCD’s shift-register—where this stream of fetch responses would then entirely overwrite the calling CPU’s cache lines with the retrieved values?

yongjik 7y ago

I don't think x86 compatibility mattered. When it launched in 2001 it was supposed to replace HP's PA-RISC architecture which is totally different anyway. Sun and its SPARC processors were very much alive, Google was only three years old, and AWS was five years away - the idea that a massive array of cheap x86 processors will outperform enterprise-class servers simply hadn't occurred to most people yet. Of course, the joke is that cheap x86 processors did outperform Itanium (and every other architectures, eventually).

xscott 7y ago
> I don't think x86 compatibility mattered. I'll admit I had a limited worldview, but not running Excel as quickly seemed like the kind of criticisms I saw in the trade rags at the time. > the idea that a massive array of cheap x86 processors will outperform enterprise-class servers simply hadn't occurred to most people yet Oh, I don't know. There was a really common Slashdot cliche running around at that time: "Can you imagine a Beowulf cluster of these?"
- kragen 7y ago
  Yeah, it had clearly occurred to everyone on Slashdot. On the other hand, we liked to "imagine Beowulf clusters" of all kinds of recondite hardware. Elbrus 2000 is real power! HOT GRITS!
  - bloopernova 7y ago
    /. was another world, one that I miss sometimes. I'm probably viewing it through rose-tinted nostalgia, but I don't remember the vitriol and hatred that so many social sites are soaked in these days. The Mozilla open source announcement, the Microsoft anti-trust case, Linux exploding in popularity, it all felt like we were changing the world for the better.
    - AnimalMuppet 7y ago
      /. was great... and then it wasn't. The troll population went way up, the "first post" thing was just noise, and eventually I just quit going there. HN is also less than it used to be, but I think that the mods have kept it better than /. became - so far, at least.

gnufx 7y ago

That seems right on such important sorts of computation, disregarding other factors. On the history, actual HPC numbers for Itanium have appeared in the Infamous Annual Martyn Guest Presentation over the years. An example that came to hand from 15 years ago to compare with bald statements is is https://www.researchgate.net/profile/Martyn_Guest/publication/30416847_Performance_of_Various_Computers_in_Computational_Chemistry/links/0046352471d0d1cd54000000.pdf https://www.researchgate.net/profile/Martyn_Guest/publicatio... Regarding GPUs, Fujitsu may not agree (for Fugaku and spin-offs) depending on the value of "horsepower" relevant for HPC systems, even if an A64FX doesn't have the peak performance of a V100. They have form from the K Computer, and if they basically did it themselves again, there was presumably "co-design" for the hardware and software which may be relevant here; I haven't seen anything written about that, though.