5 ms·

That's a great article. I do worry sometimes that something is up with CPU development, that we're tending towards more and more complicated designs with workf

That's a great article. I do worry sometimes that something is up with CPU development, that we're tending towards more and more complicated designs with workflows that are very hard to analyse and simulate even for the designers themselves, but the actual workload execution ability performance per core isn't shifting upwards all that much, and then weird mitigations have to be applied that reduce that execution ability in practice. Something makes me think that perhaps a different design paradigm should prevail, with particular attention paid to segregation of workloads and of core partitioning, perhaps an abandoning of hyperthreading and even to the extent of having 100% physical separation of cores and their caches. But I'm very much not an expert in the field. A little birdie inside of me every now and then wakes up and whispers 'is it a coincidence that these design paradigms are yielding so many vulnerabilities?'

timschmidt 5y ago
https://millcomputing.com/ https://millcomputing.com/ springs to mind.
- colejohnson66 5y ago
  The Mill architecture is vaporware. It’s been what? A decade? And there’s not even an FPGA demo yet? Not to mention that the whole idea of the Mill requires a “sufficiently smart compiler”. We tried VLIW (based on the same compiler ideals) with the Itanium and it was a major flop.
  - Lascaille 5y ago
    Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. The Itanium platform was totally unaffected by Spectre/Meltdown type attacks, you may note.
    - toast0 5y ago
      > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.
    - jcranmer 5y ago
      > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel invested heavily into Itanium, and the 90s started seeing the deaths of competing processor architectures in part because of how hyped up the Intel Itanium was getting. It was intended to be the 64-bit version of x86, hence the abbreviation IA-64. AMD was the one who created what we now know as x86-64, and my understanding is that Microsoft more or less forced Intel to implement AMD's x86-64 specification. In its later years (let's say by 2010, since that's the midpoint of Itanium's life as a shipping product, but I don't have any clear dates as to when the shift happens), it does seem to be that Intel was reluctant to continue supporting Itanium. But that was definitely not the case beforehand.
    - hajile 5y ago
      Intel, HP, etc invested over 10 billion dollars into Itanium (closer to 14-17 billion dollars today). For perspective, AMD's market cap in 2003 was around 5 billion. They could have built 20% of the US carrier fleet of the time with that much money. Ultimately, the compiler never materialized and I'm convinced they knew it wouldn't (but in the meantime, they almost killed all the RISC competition). The Halting problem means that at best you have heuristic optimizations that constantly fall through. The only way to solve these problems with a high degree of success is to analyze the code as it is running which is what other CPUs actually do. This is so true that later versions of Itanium (latest being released in 2017) were just VLIW wrappers around a rather traditional, speculative core.
      - timschmidt 5y ago
        Languages like Rust permit sufficient analysis at compile time to make architectures like mill and itanium shine. One of the reasons Rust is so exciting beyond the oft repeated memory and thread safety.
eternityforest 5y ago
Hyperthreading and the like seems to give a pretty big performance boost. And process separation is currently a bit irrelevant on desktop for most people who have single user systems and a browser that has their entire life stored in it. It's a bit concerning that we are not really making amazing progress in single threaded performance. I think we might not be going quite far enough with complex instructions, and maybe we need to be able to define out own with custom microcode or something. Like, a CPU that had just a few instructions, enough to bootstrap and that's it, and a very fast FPGA that could switch configuration quickly to make your own instructions. Right now it takes time to send stuff to the GPU. We need acceleration we can access in one instruction, so that normal compilers can generate it all behind the scenes. Or, alternately, modular pluggable acceleration. You could fit like 8 little MicroSD sized special purpose accelerators on a laptop MB. Maybe file serving can be hardware accelerated. Is there an actual reason you need a beefy server to serve a ton of media, or can CDN caching be optimized the way ethernet switches are, so you have a tiny credit card size device serving 10gbps on three watts?
- Lascaille 5y ago
  >Maybe file serving can be hardware accelerated Encryption aside a lot of file serving is accelerated. In Linux, apache has just called a kernel function (I forget what it's called, something unsurprisingly along the lines of socket_sendfile) to get data out on the wire, and that function itself is hardware accelerated by the network hardware through the large send offload v1 & v2 functions offered by the network card driver.
  - gpderetta 5y ago
    You are probably thinking of splice(2).
    - Lascaille 5y ago
      I was thinking of sendfile() but I see now it's become a wrapper around splice(). My knowledge is a little dated to say the least.
rob74 5y ago
If you apply your suggestion to existing x86 designs, you would get chips that are slower than current ones while needing more silicon for security features - so they would be slower and also more expensive just to mitigate some extremely-difficult-to-exploit vulnerabilities. I don't think anyone would actually buy those chips. Maybe they could be marketed for applications with higher security requirements, but that would make them a niche product and thus even more expensive. (also not an expert however)

timschmidt 5y ago

https://millcomputing.com/ https://millcomputing.com/ springs to mind.

colejohnson66 5y ago
The Mill architecture is vaporware. It’s been what? A decade? And there’s not even an FPGA demo yet? Not to mention that the whole idea of the Mill requires a “sufficiently smart compiler”. We tried VLIW (based on the same compiler ideals) with the Itanium and it was a major flop.
- Lascaille 5y ago
  Itanium had a decent service life and a reasonable install base. It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. The Itanium platform was totally unaffected by Spectre/Meltdown type attacks, you may note.
  - toast0 5y ago
    > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel didn't want to make 64-bit x86, but the market prefered amd64 over itanium.
  - jcranmer 5y ago
    > It didn't take off because of economies of scale and Intel not really wanting to introduce a big x86/x64 competitor. Intel invested heavily into Itanium, and the 90s started seeing the deaths of competing processor architectures in part because of how hyped up the Intel Itanium was getting. It was intended to be the 64-bit version of x86, hence the abbreviation IA-64. AMD was the one who created what we now know as x86-64, and my understanding is that Microsoft more or less forced Intel to implement AMD's x86-64 specification. In its later years (let's say by 2010, since that's the midpoint of Itanium's life as a shipping product, but I don't have any clear dates as to when the shift happens), it does seem to be that Intel was reluctant to continue supporting Itanium. But that was definitely not the case beforehand.
  - hajile 5y ago
    Intel, HP, etc invested over 10 billion dollars into Itanium (closer to 14-17 billion dollars today). For perspective, AMD's market cap in 2003 was around 5 billion. They could have built 20% of the US carrier fleet of the time with that much money. Ultimately, the compiler never materialized and I'm convinced they knew it wouldn't (but in the meantime, they almost killed all the RISC competition). The Halting problem means that at best you have heuristic optimizations that constantly fall through. The only way to solve these problems with a high degree of success is to analyze the code as it is running which is what other CPUs actually do. This is so true that later versions of Itanium (latest being released in 2017) were just VLIW wrappers around a rather traditional, speculative core.
    - timschmidt 5y ago
      Languages like Rust permit sufficient analysis at compile time to make architectures like mill and itanium shine. One of the reasons Rust is so exciting beyond the oft repeated memory and thread safety.

eternityforest 5y ago

Hyperthreading and the like seems to give a pretty big performance boost. And process separation is currently a bit irrelevant on desktop for most people who have single user systems and a browser that has their entire life stored in it. It's a bit concerning that we are not really making amazing progress in single threaded performance. I think we might not be going quite far enough with complex instructions, and maybe we need to be able to define out own with custom microcode or something. Like, a CPU that had just a few instructions, enough to bootstrap and that's it, and a very fast FPGA that could switch configuration quickly to make your own instructions. Right now it takes time to send stuff to the GPU. We need acceleration we can access in one instruction, so that normal compilers can generate it all behind the scenes. Or, alternately, modular pluggable acceleration. You could fit like 8 little MicroSD sized special purpose accelerators on a laptop MB. Maybe file serving can be hardware accelerated. Is there an actual reason you need a beefy server to serve a ton of media, or can CDN caching be optimized the way ethernet switches are, so you have a tiny credit card size device serving 10gbps on three watts?

Lascaille 5y ago
>Maybe file serving can be hardware accelerated Encryption aside a lot of file serving is accelerated. In Linux, apache has just called a kernel function (I forget what it's called, something unsurprisingly along the lines of socket_sendfile) to get data out on the wire, and that function itself is hardware accelerated by the network hardware through the large send offload v1 & v2 functions offered by the network card driver.
- gpderetta 5y ago
  You are probably thinking of splice(2).
  - Lascaille 5y ago
    I was thinking of sendfile() but I see now it's become a wrapper around splice(). My knowledge is a little dated to say the least.

rob74 5y ago

If you apply your suggestion to existing x86 designs, you would get chips that are slower than current ones while needing more silicon for security features - so they would be slower and also more expensive just to mitigate some extremely-difficult-to-exploit vulnerabilities. I don't think anyone would actually buy those chips. Maybe they could be marketed for applications with higher security requirements, but that would make them a niche product and thus even more expensive. (also not an expert however)