Re:C Is Not a Low-level Language (2018)
by dragontamer on Friday December 27, 2019 @02:49PM
(#21893936)
> 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.
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.