4 ms·

Here's a comprehensive list of every time the "magic compiler will make our CPU competitive"-approach worked out:

dleslie 5y ago
ICC When Intel shipped a compiler that artificially, and purposefully, crippled performance of resulting binaries when run on an AMD CPU. Not what you had in mind, but that dirty trick compiler did give Intel an advantage.
- incrudible 5y ago
  > Not what you had in mind, but that dirty trick compiler did give Intel and advantage. You can only pull off that trick if you already effectively own the market. Otherwise nobody would use your compiler, at least not exclusively.
  - rbanffy 5y ago
    There were dozens of incidents of compilers that looked for known benchmark code and optimized the hell out of those cases. At the time I remember some debate as to whether it was "fair", on one side people saying it was not, on the other people saying that they actually improved benchmark-like code.
- spijdar 5y ago
  While ICC did do AMD processors dirty by intentionally disabling optimizations that they (technically) supported in a clearly subversive move, this "worked" much better as a tactic because ICC did legitimately produce better code for Intel CPUs than either MSVC or GCC, and can still produce better optimizations. At least years ago, if you really wanted to rice up your system on Gentoo, you'd combine ICC with -O3 and get a small but measurable performance bump.
  - gnufx 5y ago
    The Intel compiler(s) -- I don't know whether ifort and icc are really distinct -- may produce better code than GCC, and vice versa. The bottom line I got for a set of Fortran benchmarks on SKX was essentially a tie with options as similar as I could make them. (It's a set that seemed to be used for marketing proprietary compilers.) If icc is as reliable as ifort, I wouldn't want to build my OS with it.
fulafel 5y ago
It has somewhat worked out for GPUs, if you phrase it more charitably (eg "our chip needs specialized compilers and programming languages to perfom well, but will pay off well enough that a critical mass of developers will use them"). Not that GPUs and their proprietary fragmented & buggy tooling are that nice for developers even now, 15-20 years into the attempt, and the vast majority of apps still don't bother with it. And of course the whole GPGPU thing was just riding on the wing of gaming for most of its existence so had a really long artificial runway.
Animats 5y ago
Yes. This has been tried before. A lot. It's straightforward to put a lot of loosely coupled compute units on a single chip, or at least a single box. The question is, then what? - ILLIAC 4 (64-cpu mainframe, 1970s): "A matrix multiply is a master's thesis, a matrix inversion is a PhD thesis, and a compiler may be beyond the power of the human mind". - Connection Machine. (SIMD in lockstep, which just wasn't that useful.) - NCube (I tried using one of those, 64 CPUs in an array, each with local memory, message passing hardware. It was donated to Stanford because some oil company couldn't find a use for it. Someone got a chess program going, which works as a distributed search problem. - The Cell CPU in the Playstation. (Not enough memory per CPU to do much locally, and slow access to main memory. Tied up the entire staff of Sony Computer Entertainment America for years trying to figure out a way to make it useful.) - Itanium. (I went to a talk once by the compiler group from HP. Optimal instruction ordering for the thing seemed to be NP-hard, without easy approximate solutions.) Those are just the major ones that made it to production. But then came GPUs, which do useful things with a lot of loosely coupled compute units on a single chip. GPUs have turned out to be useful for a reasonable range of compute-heavy tasks other than graphics. They're good for neural nets, which are a simple inner loop with massive parallelism and not too much data sharing. So there may now be a market in this space for architectures which failed at "general purpose computing".
- notacoward 5y ago
  Also Multiflow and more recently Convey. http://www.multiflowthebook.com/ http://www.multiflowthebook.com/ https://www.dmagazine.com/publications/d-ceo/2012/december/convey-computer-old-guard-tackles-big-data/ https://www.dmagazine.com/publications/d-ceo/2012/december/c... Multiflow definitely reached production. I even worked at a company that contracted to write some software for them (though I personally wasn't involved). They were not a total flop, but obviously not a stellar long-term success either. I'm not sure if Convey actually reached production, but their approach seems much more similar to what Ascenium is trying to do.
- incrudible 5y ago
  > The Cell CPU in the Playstation. (Not enough memory per CPU to do much locally, and slow access to main memory. Tied up the entire staff of Sony Computer Entertainment America for years trying to figure out a way to make it useful.) At least towards EOL, developers did figure out what to use it for, like using the massive readback performance on the SRAM for tiled deferred shading: https://de.slideshare.net/DICEStudio/spubased-deferred-shading-in-battlefield-3-for-playstation-3 https://de.slideshare.net/DICEStudio/spubased-deferred-shadi... Good luck teaching that trick to your magic compiler.
dragontamer 5y ago
NVidia's CUDA into PTX into SASS is pretty darn good. The SASS assembly on NVidia's instruction set seems to be manually creating read/write barriers at the assembly program level instead of leaving it up to the decoder. PTX exists as the intermediate step before SASS for a reason: all of that read/write barrier placement is extremely complicated. CUDA cheats by making the programmer do a significant amount of the heavy lifting: the programmer needs to write in an implicitly parallel style. But once written in that manner, the compiler / computer can execute the code in parallel. The biggest win for NVidia was convincing enough programmers to change paradigms and write code differently.

ICC When Intel shipped a compiler that artificially, and purposefully, crippled performance of resulting binaries when run on an AMD CPU. Not what you had in mind, but that dirty trick compiler did give Intel an advantage.

incrudible 5y ago
> Not what you had in mind, but that dirty trick compiler did give Intel and advantage. You can only pull off that trick if you already effectively own the market. Otherwise nobody would use your compiler, at least not exclusively.
- rbanffy 5y ago
  There were dozens of incidents of compilers that looked for known benchmark code and optimized the hell out of those cases. At the time I remember some debate as to whether it was "fair", on one side people saying it was not, on the other people saying that they actually improved benchmark-like code.
spijdar 5y ago
While ICC did do AMD processors dirty by intentionally disabling optimizations that they (technically) supported in a clearly subversive move, this "worked" much better as a tactic because ICC did legitimately produce better code for Intel CPUs than either MSVC or GCC, and can still produce better optimizations. At least years ago, if you really wanted to rice up your system on Gentoo, you'd combine ICC with -O3 and get a small but measurable performance bump.
- gnufx 5y ago
  The Intel compiler(s) -- I don't know whether ifort and icc are really distinct -- may produce better code than GCC, and vice versa. The bottom line I got for a set of Fortran benchmarks on SKX was essentially a tie with options as similar as I could make them. (It's a set that seemed to be used for marketing proprietary compilers.) If icc is as reliable as ifort, I wouldn't want to build my OS with it.

fulafel 5y ago

It has somewhat worked out for GPUs, if you phrase it more charitably (eg "our chip needs specialized compilers and programming languages to perfom well, but will pay off well enough that a critical mass of developers will use them"). Not that GPUs and their proprietary fragmented & buggy tooling are that nice for developers even now, 15-20 years into the attempt, and the vast majority of apps still don't bother with it. And of course the whole GPGPU thing was just riding on the wing of gaming for most of its existence so had a really long artificial runway.

Animats 5y ago

Yes. This has been tried before. A lot. It's straightforward to put a lot of loosely coupled compute units on a single chip, or at least a single box. The question is, then what? - ILLIAC 4 (64-cpu mainframe, 1970s): "A matrix multiply is a master's thesis, a matrix inversion is a PhD thesis, and a compiler may be beyond the power of the human mind". - Connection Machine. (SIMD in lockstep, which just wasn't that useful.) - NCube (I tried using one of those, 64 CPUs in an array, each with local memory, message passing hardware. It was donated to Stanford because some oil company couldn't find a use for it. Someone got a chess program going, which works as a distributed search problem. - The Cell CPU in the Playstation. (Not enough memory per CPU to do much locally, and slow access to main memory. Tied up the entire staff of Sony Computer Entertainment America for years trying to figure out a way to make it useful.) - Itanium. (I went to a talk once by the compiler group from HP. Optimal instruction ordering for the thing seemed to be NP-hard, without easy approximate solutions.) Those are just the major ones that made it to production. But then came GPUs, which do useful things with a lot of loosely coupled compute units on a single chip. GPUs have turned out to be useful for a reasonable range of compute-heavy tasks other than graphics. They're good for neural nets, which are a simple inner loop with massive parallelism and not too much data sharing. So there may now be a market in this space for architectures which failed at "general purpose computing".

notacoward 5y ago
Also Multiflow and more recently Convey. http://www.multiflowthebook.com/ http://www.multiflowthebook.com/ https://www.dmagazine.com/publications/d-ceo/2012/december/convey-computer-old-guard-tackles-big-data/ https://www.dmagazine.com/publications/d-ceo/2012/december/c... Multiflow definitely reached production. I even worked at a company that contracted to write some software for them (though I personally wasn't involved). They were not a total flop, but obviously not a stellar long-term success either. I'm not sure if Convey actually reached production, but their approach seems much more similar to what Ascenium is trying to do.
incrudible 5y ago
> The Cell CPU in the Playstation. (Not enough memory per CPU to do much locally, and slow access to main memory. Tied up the entire staff of Sony Computer Entertainment America for years trying to figure out a way to make it useful.) At least towards EOL, developers did figure out what to use it for, like using the massive readback performance on the SRAM for tiled deferred shading: https://de.slideshare.net/DICEStudio/spubased-deferred-shading-in-battlefield-3-for-playstation-3 https://de.slideshare.net/DICEStudio/spubased-deferred-shadi... Good luck teaching that trick to your magic compiler.

dragontamer 5y ago

NVidia's CUDA into PTX into SASS is pretty darn good. The SASS assembly on NVidia's instruction set seems to be manually creating read/write barriers at the assembly program level instead of leaving it up to the decoder. PTX exists as the intermediate step before SASS for a reason: all of that read/write barrier placement is extremely complicated. CUDA cheats by making the programmer do a significant amount of the heavy lifting: the programmer needs to write in an implicitly parallel style. But once written in that manner, the compiler / computer can execute the code in parallel. The biggest win for NVidia was convincing enough programmers to change paradigms and write code differently.