7 ms·

Intel and HP attempted to deliver what this paper advocates. They designed an entirely new processing element and compiler architecture that promised to delive

Intel and HP attempted to deliver what this paper advocates. They designed an entirely new processing element and compiler architecture that promised to deliver high performance with less complexity. It was called EPIC and manifested as Itanium. Billions of dollars and the best minds at the disposal of an industry wide consortium couldn't make it work; one year ago the last Itanium shipped. The market has spoken. You can run unmodified, compiled OS/360 code from the 1960s on a z15 machine built this year. The market values the tools and code it has invested in far more than any idealized computing model you care to speculate about. The flaws in contemporary CPUs that device manufacturers perpetrated on their customers for almost 20 years are not the fault of C and its users. They are the fault of reckless manufacturers that squandered their reputation in the name of performance and, ironically, helped perpetuate the lack of innovation in programming techniques called out in this paper.

daxfohl 7y ago
Though nowadays if AWS or Azure or GCP finds a way to run some proprietary database more efficiently using a new kind of language and cpu architecture, the scale there somewhat changes the playing field.
- sharpneli 7y ago
  Sure, if they find. The issue with Itanium was not that market didn’t care of superior performance. The issue was that Itanium is slow. Market didn’t care for theoretical beauty over actual performance. It is not the first time Intel does something similar. In the 80’s they tried to introduce an ”object oriented” processor. It was ridiculously slow and no-one cared about it.
  - aap_ 7y ago
    Not to forget the i860 and Pentium 4. Intel really has a great track record of total failures.
  - thereisnospork 7y ago
    I'm not in the field, but I'd wager we're due for a shift in the current software-hardware relationship. With the end of Moore's law continuing to improve practical computing performance will requisite making more efficient use of transistors. Or maybe processors will go 3D and we'll have a few decades of relative status quo - I'm hardly Nostradamus
  - daxfohl 7y ago
    Plus even at AWS scale, I imagine HW homogeneity of the fleet is more important than efficiency of a single application, unless it's insanely more efficient for a top 10 service. Homogeneity improves predictability, load balancing, operations, security, and all sorts of other things.
    - oconnor663 7y ago
      On the other hand, AWS offers AMD machines and ARM machines in addition to the typical Intel stuff. If there was some new architecture that offered a 50% speedup, and all you had to do was recompile your code, I assume they'd support it in a heartbeat.
      - ma2rten 7y ago
        They also have GPUs.
      - daxfohl 7y ago
        In the context of the article, the changes would by necessity be far more invasive than "recompile your code". The premise is that C cannot be an effective implementation language. A full rewrite would be required.
ngneer 7y ago
So true. The Spectre and Meltdown flaws have nothing to do with the abstract machine that a processor implements. You might as well claim that the vulnerabilities are the result of the ISA (which itself was born to smooth over differences among machines). Rather, these vulnerabilities are the case of a confused deputy. There is nothing to say you should not speculate, just do not do so across security boundaries leaving breadcrumbs for an adversary to discover.
campfireveteran 7y ago
Yeap. One of my roommates from college worked at HP during the Itanium development.. it was great on paper but customers didn't want it or need it. The bigger picture is throwing everything away every few model years isn't "innovation," it's planned-obsolescence consumerism and pointless churn. Turing completeness and standardization > whiz-bang over-engineering.
- kick 7y ago
  The bigger picture is throwing everything away every few model years isn't "innovation," it's planned-obsolescence consumerism x86* is a terrible architecture, though. The world would be a much better place without it. Turing completeness and standardization > whiz-bang over-engineering Turing completeness and standardization are fine, but there were and are better things to standardize on. "Something with a reasonable amount of thought going into it" is not "over-engineered." Claiming "planned-obsolescence" would be reasonable if people weren't going through all of this work to maintain fifty years of (near) compatibility with an architecture originally used in a calculator.
  - gpderetta 7y ago
    x86 is a terrible architecture. If we changed it overnight the world be an extremely marginally better place (if we ignore backward compatibility). In reality on large powerful machines the ISA matters very little. Where the ISA matter (low end mobile, embedded), x86 has never been a thing.
    - magduf 7y ago
      x86 is a lousy architecture, but x86-64 isn't as bad; at least it has a good number of registers unlike x86. It's easy to prove x86 is lousy by seeing its success in embedded and mobile devices: it hasn't had any, despite trying (Atom). ARM reigns supreme here. x86 manages to hold on because of 1) backwards compatibility with proprietary software (namely Windows), and 2) inertia. We don't really notice it that much because we've covered over it with abstraction layers: almost no one writes assembly code any more. We would be better off if we switched to something better, but we wouldn't notice it much; we might see a slight amount of power savings, and OS developers would be happier. But the benefits just aren't worth the costs. It's unfortunate, though: the major chipmakers should be able to just develop a nice, clean-sheet architecture which retains the good parts of x86 (like the PCIe bus and enumeration, things missing on ARM) and cleans up the bad things, and users shouldn't have to do anything other than make sure to select the Linux distro that matches that architecture. The presence of binary-only proprietary software that only works on x86(/64) is probably the biggest reason we're stuck with it: a competing CPU maker can't just come up with something new and have it "just work" (after getting their compiler changes merged into GCC and LLVM of course).
pjmlp 7y ago
Intel and HP only failed, because AMD exists and was allowed to design chips that provided an alternative to Itanium. Without AMD, the market would not have spoken anything.
- jashmatthews 7y ago
  You think Intel would have just stopped manufacturing x86 chips?
  - pjmlp 7y ago
    Intel would have been able to drive the market into Itanium, since x64 would not exist.
- haileris 7y ago
  this is not how economics works
  - pjmlp 7y ago
    Indeed, economics require competition, which only happened thanks to AMD x64 alternative.
- topspin 7y ago
  > AMD exists and was allowed to design What authority do you propose to gate who is and is not allowed to design semiconductors? The x86 ISA started at 8 bits, sharing design elements with an earlier 4 bit device. It was successfully extended first to 16 and then 32 bits. Extension to 64 bits was inevitable. The fact that a hungry competitor fulfilled this inevitability before the market forced Intel to do so is an interesting detail and little more. The fact that this obvious evolution was all that was necessary to wipe out Itanium is telling.
  - pjmlp 7y ago
    The authority of patents and license agreements that Intel had with AMD, partially forced by a court agreement, without them x64 would never happened in a legal way. Intel 80x86 architecture was successfully to 16 and then 32 bits, by Intel.
jokoon 7y ago
> the lack of innovation in programming techniques called out in this paper. What kind of innovation? Compiler optimizations? New language paradigms? Am I right to think computers should adopt a more parallel architecture and design, and to expand on techs like OpenCL and CUDA, and generalize those technique to everything done by a computer, because we've hit a frequency limit? We often see software being either sharded, distributed, load balanced, etc, but it seems that there is much more performance being possible if we start building chips that enforce the division of a task on the programmer. Of course it seems like it is a very big paradigm shift, which might be too expensive and complicated, but since bleeding edge techs like deep learning cannot be properly accomplished with traditional computers, I tend to believe the computer model of today is outdated.
- ThrowawayR2 7y ago
  > "Am I right to think computers should adopt a more parallel architecture and design, and to expand on techs like OpenCL and CUDA, and generalize those technique to everything done by a computer, because we've hit a frequency limit?" https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law "...Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors. For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times {\displaystyle \left({\dfrac {1}{1-p}}=20\right)}{\displaystyle \left({\dfrac {1}{1-p}}=20\right)}. For this reason, parallel computing with many processors is useful only for highly parallelizable programs..." So, in answer to your question, no.
  - dnautics 7y ago
    https://en.m.wikipedia.org/wiki/Gustafson%27s_law https://en.m.wikipedia.org/wiki/Gustafson%27s_law
commandlinefan 7y ago
> The market has spoken. The market “demands” cheap, turnkey, easily replaceable programmers who don’t really know what they’re doing, and justifies this with “I made a website last weekend, programming is easy, you’re just pretending its hard to keep out competition”. Until software engineering is treated as actual professional engineering, time, money and resources will continue to be wasted frivolously.
- deleted 7y ago
  [deleted]
- dpflan 7y ago
  Is there movement towards professionalizing software engineering? What factors are for and what are against? I like the idea of professionalizing but also understand it can be constraining to the labor market, but could increase “quality” of products?
  - pjmlp 7y ago
    Speaking for Portuguese market, it is not a movement, it already exists since about 30 years already. https://pt.wikipedia.org/wiki/Engenharia_Inform%C3%A1tica#Col%C3%A9gio_de_Engenharia_Inform%C3%A1tica_da_Ordem_dos_Engenheiros https://pt.wikipedia.org/wiki/Engenharia_Inform%C3%A1tica#Co... Quality of assurance of 5 year studies, with assessement of university study plans.
- burlesona 7y ago
  Having previously worked in a “professionalized” field (architecture) before a career change to software engineering - please no. Having a credentialing body that has to review and certify you just kills wages and innovation, and makes it take an outrageously long time to enter the field. But, more importantly, it will not prevent bad programmers from existing and shipping bad software. Further, software engineering most assuredly is treated as actual professional engineering in most of the industry. That there are many companies that don’t treat it that way just means there are a lot of poorly led or non-software companies out there, which is no different than any other field.
ip26 7y ago
They also built it upon the promise of a "sufficiently smart compiler" which never manifest, and ensured there was no second source to provide market competition.
api 7y ago
EPIC also had numerous problems. The most severe I think was that it exposed the innermost workings of the chip. That sounds like an awesome idea, but it's actually a major issue because once you expose something you freeze it in time forever. Pretty much all modern processors larger than in-order embedded cores are basically virtual machines implemented in hardware. The actual execution units are behind a sophisticated instruction decoder that schedules operations to achieve maximum instruction level parallelism and balance many other concerns including heat and power use in modern designs. The presence of this translation layer frees the innermost core of the chip to evolve with almost total freedom. Even if fundamental innovations were discovered like practical trinary logic or quantum acceleration of some kind, this could safely be kept behind the instruction decoder. EPIC on the other hand by exposing the core freezes it. I predict that if EPIC would have taken over eventually you'd have... drum roll... an instruction decoder for each EPIC "lane" or whatever that did exactly what today's instruction decoders do. It probably would have ended up evolving into a synchronous multithreaded vector processor with cores that look not unlike today's cores complete with pipelines and instruction schedulers and all the rest of that stuff. I can imagine one scenario where EPIC and other designs that show their guts could work, but it would require the cooperation of operating system vendors. (Stop laughing!) OSes could implement the instruction decoder layer in software, transpiling binaries from a standard bitcode like WASM, JVM bytecode, LLVM intermediate code, and/or even pre-existing instruction sets like X86 and ARM to the underlying instruction set of the processor core. Each new processor core would require what amounts to a driver that would look not unlike an LLVM code generator. Have fun getting OS vendors to do that. Another major problem would be that CPU vendors would be incentivized to distribute these things as opaque blobs, making it very hard for open source OSes to support new chip versions. It would be a bit like the ARM / mobile phone binary blob hell, which is one of the factors making it hard to ship open source phone OSes or make open phones. Keeping the instruction decoder on the silicon basically just avoids this whole shitshow. It lets the CPU vendors keep their innovations closed as they wish without imposing that closed-ness on the OS or apps. The final issue with kernel compilation is that the performance probably wouldn't be much better than what we get now. We'd trade the overhead of an instruction decoder in silicon for a lot of JIT or AOT compilation and caching in the OS kernel. The performance and power use hit might be just as large or larger.
dragontamer 7y ago
> Intel and HP attempted to deliver what this paper advocates. They designed an entirely new processing element and compiler architecture that promised to deliver high performance with less complexity. It was called EPIC and manifested as Itanium. Billions of dollars and the best minds at the disposal of an industry wide consortium couldn't make it work; one year ago the last Itanium shipped. The market has spoken. Because SIMD seems to be easier in practice when you actually need performance. Every high-performance application seems to dip into explicit SIMD-parallelism: H264 / H265 encoders, GPU-based deep learning... video game shaders and raytracing, etc. etc. All of which get more performance from SIMD than VLIW / EPIC. I think the market has spoken: if you are aiming for explicit instruction level parallelism, why not go for 32-way parallelism per clock tick (NVidia Volta or AMD RDNA architectures) instead of just 3 or 4 parallel assembly statements (aka a "bundle") that EPIC / VLIW Itanium can do? ---------- Another note: normal CPUs these days are approximately 6-way parallel. The Skylake i9-9900k can execute 6-uops per clock tick from the uop cache (ex: 2x Load instructions, 2x Additions, 1x XOR, 1x 512-bit SIMD statement). In addition to pipelines, reorder buffers, and other such tricks to "extract" more parallelism from instruction streams. EPIC / VLIW just happens to sit in an uncomfortable spot. Its "different enough" that it requires new compiler algorithms and new ways of thinking. But its not "dramatic enough" such that it creates huge parallelism like SIMD can easily represent. Back in the 90s and 00s, it was probably assumed that SIMD-compute was too hard to program, while traditional CPUs couldn't scale very easily. EPIC / VLIW was wrong on both counts. OpenCL and CUDA made SIMD far easier to program, while traditional CPUs became increasingly parallel. And that is the history IMO.

daxfohl 7y ago

Though nowadays if AWS or Azure or GCP finds a way to run some proprietary database more efficiently using a new kind of language and cpu architecture, the scale there somewhat changes the playing field.

sharpneli 7y ago
Sure, if they find. The issue with Itanium was not that market didn’t care of superior performance. The issue was that Itanium is slow. Market didn’t care for theoretical beauty over actual performance. It is not the first time Intel does something similar. In the 80’s they tried to introduce an ”object oriented” processor. It was ridiculously slow and no-one cared about it.
- aap_ 7y ago
  Not to forget the i860 and Pentium 4. Intel really has a great track record of total failures.
- thereisnospork 7y ago
  I'm not in the field, but I'd wager we're due for a shift in the current software-hardware relationship. With the end of Moore's law continuing to improve practical computing performance will requisite making more efficient use of transistors. Or maybe processors will go 3D and we'll have a few decades of relative status quo - I'm hardly Nostradamus
- daxfohl 7y ago
  Plus even at AWS scale, I imagine HW homogeneity of the fleet is more important than efficiency of a single application, unless it's insanely more efficient for a top 10 service. Homogeneity improves predictability, load balancing, operations, security, and all sorts of other things.
  - oconnor663 7y ago
    On the other hand, AWS offers AMD machines and ARM machines in addition to the typical Intel stuff. If there was some new architecture that offered a 50% speedup, and all you had to do was recompile your code, I assume they'd support it in a heartbeat.
    - ma2rten 7y ago
      They also have GPUs.
    - daxfohl 7y ago
      In the context of the article, the changes would by necessity be far more invasive than "recompile your code". The premise is that C cannot be an effective implementation language. A full rewrite would be required.

ngneer 7y ago

So true. The Spectre and Meltdown flaws have nothing to do with the abstract machine that a processor implements. You might as well claim that the vulnerabilities are the result of the ISA (which itself was born to smooth over differences among machines). Rather, these vulnerabilities are the case of a confused deputy. There is nothing to say you should not speculate, just do not do so across security boundaries leaving breadcrumbs for an adversary to discover.

campfireveteran 7y ago

Yeap. One of my roommates from college worked at HP during the Itanium development.. it was great on paper but customers didn't want it or need it. The bigger picture is throwing everything away every few model years isn't "innovation," it's planned-obsolescence consumerism and pointless churn. Turing completeness and standardization > whiz-bang over-engineering.

kick 7y ago
The bigger picture is throwing everything away every few model years isn't "innovation," it's planned-obsolescence consumerism x86* is a terrible architecture, though. The world would be a much better place without it. Turing completeness and standardization > whiz-bang over-engineering Turing completeness and standardization are fine, but there were and are better things to standardize on. "Something with a reasonable amount of thought going into it" is not "over-engineered." Claiming "planned-obsolescence" would be reasonable if people weren't going through all of this work to maintain fifty years of (near) compatibility with an architecture originally used in a calculator.
- gpderetta 7y ago
  x86 is a terrible architecture. If we changed it overnight the world be an extremely marginally better place (if we ignore backward compatibility). In reality on large powerful machines the ISA matters very little. Where the ISA matter (low end mobile, embedded), x86 has never been a thing.
  - magduf 7y ago
    x86 is a lousy architecture, but x86-64 isn't as bad; at least it has a good number of registers unlike x86. It's easy to prove x86 is lousy by seeing its success in embedded and mobile devices: it hasn't had any, despite trying (Atom). ARM reigns supreme here. x86 manages to hold on because of 1) backwards compatibility with proprietary software (namely Windows), and 2) inertia. We don't really notice it that much because we've covered over it with abstraction layers: almost no one writes assembly code any more. We would be better off if we switched to something better, but we wouldn't notice it much; we might see a slight amount of power savings, and OS developers would be happier. But the benefits just aren't worth the costs. It's unfortunate, though: the major chipmakers should be able to just develop a nice, clean-sheet architecture which retains the good parts of x86 (like the PCIe bus and enumeration, things missing on ARM) and cleans up the bad things, and users shouldn't have to do anything other than make sure to select the Linux distro that matches that architecture. The presence of binary-only proprietary software that only works on x86(/64) is probably the biggest reason we're stuck with it: a competing CPU maker can't just come up with something new and have it "just work" (after getting their compiler changes merged into GCC and LLVM of course).

pjmlp 7y ago

Intel and HP only failed, because AMD exists and was allowed to design chips that provided an alternative to Itanium. Without AMD, the market would not have spoken anything.

jashmatthews 7y ago
You think Intel would have just stopped manufacturing x86 chips?
- pjmlp 7y ago
  Intel would have been able to drive the market into Itanium, since x64 would not exist.
haileris 7y ago
this is not how economics works
- pjmlp 7y ago
  Indeed, economics require competition, which only happened thanks to AMD x64 alternative.
topspin 7y ago
> AMD exists and was allowed to design What authority do you propose to gate who is and is not allowed to design semiconductors? The x86 ISA started at 8 bits, sharing design elements with an earlier 4 bit device. It was successfully extended first to 16 and then 32 bits. Extension to 64 bits was inevitable. The fact that a hungry competitor fulfilled this inevitability before the market forced Intel to do so is an interesting detail and little more. The fact that this obvious evolution was all that was necessary to wipe out Itanium is telling.
- pjmlp 7y ago
  The authority of patents and license agreements that Intel had with AMD, partially forced by a court agreement, without them x64 would never happened in a legal way. Intel 80x86 architecture was successfully to 16 and then 32 bits, by Intel.

jokoon 7y ago

> the lack of innovation in programming techniques called out in this paper. What kind of innovation? Compiler optimizations? New language paradigms? Am I right to think computers should adopt a more parallel architecture and design, and to expand on techs like OpenCL and CUDA, and generalize those technique to everything done by a computer, because we've hit a frequency limit? We often see software being either sharded, distributed, load balanced, etc, but it seems that there is much more performance being possible if we start building chips that enforce the division of a task on the programmer. Of course it seems like it is a very big paradigm shift, which might be too expensive and complicated, but since bleeding edge techs like deep learning cannot be properly accomplished with traditional computers, I tend to believe the computer model of today is outdated.

ThrowawayR2 7y ago
> "Am I right to think computers should adopt a more parallel architecture and design, and to expand on techs like OpenCL and CUDA, and generalize those technique to everything done by a computer, because we've hit a frequency limit?" https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law "...Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors. For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour. Hence, the theoretical speedup is limited to at most 20 times {\displaystyle \left({\dfrac {1}{1-p}}=20\right)}{\displaystyle \left({\dfrac {1}{1-p}}=20\right)}. For this reason, parallel computing with many processors is useful only for highly parallelizable programs..." So, in answer to your question, no.
- dnautics 7y ago
  https://en.m.wikipedia.org/wiki/Gustafson%27s_law https://en.m.wikipedia.org/wiki/Gustafson%27s_law

commandlinefan 7y ago

> The market has spoken. The market “demands” cheap, turnkey, easily replaceable programmers who don’t really know what they’re doing, and justifies this with “I made a website last weekend, programming is easy, you’re just pretending its hard to keep out competition”. Until software engineering is treated as actual professional engineering, time, money and resources will continue to be wasted frivolously.

deleted 7y ago
[deleted]
dpflan 7y ago
Is there movement towards professionalizing software engineering? What factors are for and what are against? I like the idea of professionalizing but also understand it can be constraining to the labor market, but could increase “quality” of products?
- pjmlp 7y ago
  Speaking for Portuguese market, it is not a movement, it already exists since about 30 years already. https://pt.wikipedia.org/wiki/Engenharia_Inform%C3%A1tica#Col%C3%A9gio_de_Engenharia_Inform%C3%A1tica_da_Ordem_dos_Engenheiros https://pt.wikipedia.org/wiki/Engenharia_Inform%C3%A1tica#Co... Quality of assurance of 5 year studies, with assessement of university study plans.
burlesona 7y ago
Having previously worked in a “professionalized” field (architecture) before a career change to software engineering - please no. Having a credentialing body that has to review and certify you just kills wages and innovation, and makes it take an outrageously long time to enter the field. But, more importantly, it will not prevent bad programmers from existing and shipping bad software. Further, software engineering most assuredly is treated as actual professional engineering in most of the industry. That there are many companies that don’t treat it that way just means there are a lot of poorly led or non-software companies out there, which is no different than any other field.

ip26 7y ago

They also built it upon the promise of a "sufficiently smart compiler" which never manifest, and ensured there was no second source to provide market competition.

api 7y ago

EPIC also had numerous problems. The most severe I think was that it exposed the innermost workings of the chip. That sounds like an awesome idea, but it's actually a major issue because once you expose something you freeze it in time forever. Pretty much all modern processors larger than in-order embedded cores are basically virtual machines implemented in hardware. The actual execution units are behind a sophisticated instruction decoder that schedules operations to achieve maximum instruction level parallelism and balance many other concerns including heat and power use in modern designs. The presence of this translation layer frees the innermost core of the chip to evolve with almost total freedom. Even if fundamental innovations were discovered like practical trinary logic or quantum acceleration of some kind, this could safely be kept behind the instruction decoder. EPIC on the other hand by exposing the core freezes it. I predict that if EPIC would have taken over eventually you'd have... drum roll... an instruction decoder for each EPIC "lane" or whatever that did exactly what today's instruction decoders do. It probably would have ended up evolving into a synchronous multithreaded vector processor with cores that look not unlike today's cores complete with pipelines and instruction schedulers and all the rest of that stuff. I can imagine one scenario where EPIC and other designs that show their guts could work, but it would require the cooperation of operating system vendors. (Stop laughing!) OSes could implement the instruction decoder layer in software, transpiling binaries from a standard bitcode like WASM, JVM bytecode, LLVM intermediate code, and/or even pre-existing instruction sets like X86 and ARM to the underlying instruction set of the processor core. Each new processor core would require what amounts to a driver that would look not unlike an LLVM code generator. Have fun getting OS vendors to do that. Another major problem would be that CPU vendors would be incentivized to distribute these things as opaque blobs, making it very hard for open source OSes to support new chip versions. It would be a bit like the ARM / mobile phone binary blob hell, which is one of the factors making it hard to ship open source phone OSes or make open phones. Keeping the instruction decoder on the silicon basically just avoids this whole shitshow. It lets the CPU vendors keep their innovations closed as they wish without imposing that closed-ness on the OS or apps. The final issue with kernel compilation is that the performance probably wouldn't be much better than what we get now. We'd trade the overhead of an instruction decoder in silicon for a lot of JIT or AOT compilation and caching in the OS kernel. The performance and power use hit might be just as large or larger.

dragontamer 7y ago

> Intel and HP attempted to deliver what this paper advocates. They designed an entirely new processing element and compiler architecture that promised to deliver high performance with less complexity. It was called EPIC and manifested as Itanium. Billions of dollars and the best minds at the disposal of an industry wide consortium couldn't make it work; one year ago the last Itanium shipped. The market has spoken. Because SIMD seems to be easier in practice when you actually need performance. Every high-performance application seems to dip into explicit SIMD-parallelism: H264 / H265 encoders, GPU-based deep learning... video game shaders and raytracing, etc. etc. All of which get more performance from SIMD than VLIW / EPIC. I think the market has spoken: if you are aiming for explicit instruction level parallelism, why not go for 32-way parallelism per clock tick (NVidia Volta or AMD RDNA architectures) instead of just 3 or 4 parallel assembly statements (aka a "bundle") that EPIC / VLIW Itanium can do? ---------- Another note: normal CPUs these days are approximately 6-way parallel. The Skylake i9-9900k can execute 6-uops per clock tick from the uop cache (ex: 2x Load instructions, 2x Additions, 1x XOR, 1x 512-bit SIMD statement). In addition to pipelines, reorder buffers, and other such tricks to "extract" more parallelism from instruction streams. EPIC / VLIW just happens to sit in an uncomfortable spot. Its "different enough" that it requires new compiler algorithms and new ways of thinking. But its not "dramatic enough" such that it creates huge parallelism like SIMD can easily represent. Back in the 90s and 00s, it was probably assumed that SIMD-compute was too hard to program, while traditional CPUs couldn't scale very easily. EPIC / VLIW was wrong on both counts. OpenCL and CUDA made SIMD far easier to program, while traditional CPUs became increasingly parallel. And that is the history IMO.