7 ms·

Please, let's not design and implement a hundred different architectures now. It's hard to keep track of Intel bugs alone already. The whole Von-Neumann system

Please, let's not design and implement a hundred different architectures now. It's hard to keep track of Intel bugs alone already. The whole Von-Neumann system architecture is way too old for today's problems. We need heterogeneous systems. There needs to be a discussion on fundamental issues regarding which architectures are fit for what purposes.

tanilama 9y ago
> The whole Von-Neumann system architecture is way too old for today's problems. Why?
- dschuetz 9y ago
  Because instructions and data share the same memory space in general? Potentially, in such a system architecture any bug or bad implementation might lead to memory leaks from the whole memory range.
- sparkie 9y ago
  Amdahl's law. The von Neumann bottleneck continues to get bigger and bigger with each iteration. We can do far more calculations in the same amount of time on a chip, due to the increasing number of transistors we can fit on them, and also improvements in the internal designs (superscalar architectures, etc). The speed of memory access however, has only been increasing at marginal rates in comparison, and now we have increasing contention for execution units in the processor to access it as we increase the number of distinct cores. Caching, prefetching, etc. have partially helped to mitigate some of the problems, but only as far as you can avoid cache misses (common in object oriented code, due to frequent pointer dereferencing). We're still at the stage, with all these technologies, that the VNB is what's preventing us from doing more in the same amount of time. Writing high-performance code is also difficult as often the hardware specializations are inaccessible to a programmer, and he has to rely on the compiler/microassembler to do the right thing. Often this means designing code in ways to suit the CPU (eg, vectorizing all your data), rather than to suit the programmers (eg, OOP). We should really be aiming towards NUMA, many-core processors with high-speed message passing between cores, and a programming model which suits development over that kind of architecture (eg, the Actor model).
imglorp 9y ago
I think it is time to talk about new directions because we're still STUCK HARD in a rut begun in 1971 for general purpose compute. 4004 -> 8008 -> 8080 -> x86 and here we remain. Requirements and tech have both changed vastly since then. We've made some minor widening, into RISC, GPUs, and VLIW, plus we're just now looking into many cores, now that atomic physics is starting to push back on minimum feature sizes. Two areas that have not been remotely explored are asynchronous design and massively parallel (think Connection Machine). In both cases, the compilers and tools were not up to the task, but perhaps we're ready to give both another try.
- dschuetz 9y ago
  I think that there have been discussions, but everyone being on this one-big-complex-cpu-doing-everything train over the years made companies pursue financial goals rather than security. You cannot have a complex and secure CPU. That would be too expensive, so it's not a question of will-it-work, rather will-it-sell.
  - imglorp 9y ago
    Yeah, security is still not a profit feature.
- jcranmer 9y ago
  That's a rather closed view of history. Vector processors were the norm in supercomputers until the early 2000s, when they were killed off by general purpose CPUs like SPARC and POWER. Intel itself has made two big bets on alternative architectures--Itanium (essentially VLIW) and Xeon Phi (CMP gone insane), the former of which failed miserably, and the latter of which appears to be quietly dying. One of the major problems with developing alternative highly-parallel architectures is that most algorithms, particularly as they are written in source code today, simply aren't parallelizable. There's only so much ILP that can be extracted, and data parallelism isn't achievable without very heavy annotation of source code. Getting high data parallelism (as GPGPU does) is sometimes possible with algorithmic rewrites, but you're talking about rewriting several portions of your code to make that happen. That's the reason NVidia is successful--they've got an offload model, so you only need to rewrite the kernels that need parallelism, and they've got the proprietary lock-in on CUDA since no one wants to rewrite that code several times. But even then, there are classes of code that can't be run on GPGPUs very well because you just don't have the necessary data parallelism.
madez 9y ago
I think we need more architectures in wide use because a monoculture is bad for many reasons. One reason not so often mentioned is that it's then harder to distribute proprietary binaries.
- analognoise 9y ago
  If you make a living writing software, that sounds like an argument against more architectures.
  - LukeShu 9y ago
    Plenty of people make a living writing FOSS.
    - analognoise 9y ago
      There are exceptions, but the vast majority of commercial software is not FOSS. If anything, with a few shining examples, I've been totally underwhelmed by FOSS.
      - madez 9y ago
        Because governments don't back FOSS like they should.
        analognoise 9y ago
        Wait, what? Why should governments step in to back FOSS? The city of Munich tried to switch to Linux. They just announced the plan to switch back to Windows - presumably they were underwhelmed too.
        loup-vaillant 9y ago
        I bet path dependence has something to say about that. Try to force people to use Dvorak keyboards at work. Even though that layout is demonstrably better (more comfortable and easier to learn), people are already used to Qwerty, still have a Qwerty keyboard at home, and would generally resist change. Switching to GNU/Linux triggers similar problem: different GUI, still Windows at home, IT has to re-learn everything… Oh, and drivers. These aren't GNU/Linux's fault, but they still tend to underwhelm users. I, mean, seriously: ever tried to have your grandma use LibreOffice? The number one problem won't come from bugs. It won't even come from its inability to read such and such Microsoft Word document. It will come from her inability to "save as .doc" or "save as .pdf" so other people can read the document (and even if she could, it's still a hassle). Network effects are not LibreOffice's fault, but they still tend to underwhelm users.
baybal2 9y ago
>We need heterogeneous systems. If you are to develop a CPU with an ISA level security proof, you need a homogenous system. Something like a simplest MCU with few registers and hardwired instructions, no pipeline or OOOE, and flat memory that can be 100% mathematically verificated.
- mpweiher 9y ago
  The Transputer T800 was formally verified. It would also be a great candidate vor hardware isolation, with different processes running on different CPUs, linked via the Transputer's hardware channels. https://www.cs.bris.ac.uk/~dave/transputer.html https://www.cs.bris.ac.uk/~dave/transputer.html UPDATE: T800 had 250K transistors, Skylake has 1-2 billion, so you could fit around 4K-8K T800s on the same kind of die.
- dschuetz 9y ago
  So you are talking about a special purpose processor solely for the purpose of being 100% deterministic? It'll be slow, but potentially more secure than its general purpose counterparts. Which of both would be more reliable security-wise? If you put both in a single system respecting the purposes, a heterogeneous system is the result.
  - baybal2 9y ago
    You will still get something very different from HSA's understanding of heterogeneous design or secure enclave processors (although those ones come closer to the idea). The thing that is approaching it the most is a smartcard CPU. Flat X-i-P rom, cacheless, embedded mram or fram, <100 instructions, full register state determinism.
mpweiher 9y ago
> let's not design and implement a hundred different architectures ... > We need heterogeneous systems. The first seems to be a call for fewer, the second for more architectures. Which is it?
- dschuetz 9y ago
  Rather less the same system architecture reiterated in different cpu architecture implementations (AMD, Intel), and more special purpose processors for a heterogeneous/hybrid system architecture following certain standards.

tanilama 9y ago

> The whole Von-Neumann system architecture is way too old for today's problems. Why?

dschuetz 9y ago
Because instructions and data share the same memory space in general? Potentially, in such a system architecture any bug or bad implementation might lead to memory leaks from the whole memory range.
sparkie 9y ago
Amdahl's law. The von Neumann bottleneck continues to get bigger and bigger with each iteration. We can do far more calculations in the same amount of time on a chip, due to the increasing number of transistors we can fit on them, and also improvements in the internal designs (superscalar architectures, etc). The speed of memory access however, has only been increasing at marginal rates in comparison, and now we have increasing contention for execution units in the processor to access it as we increase the number of distinct cores. Caching, prefetching, etc. have partially helped to mitigate some of the problems, but only as far as you can avoid cache misses (common in object oriented code, due to frequent pointer dereferencing). We're still at the stage, with all these technologies, that the VNB is what's preventing us from doing more in the same amount of time. Writing high-performance code is also difficult as often the hardware specializations are inaccessible to a programmer, and he has to rely on the compiler/microassembler to do the right thing. Often this means designing code in ways to suit the CPU (eg, vectorizing all your data), rather than to suit the programmers (eg, OOP). We should really be aiming towards NUMA, many-core processors with high-speed message passing between cores, and a programming model which suits development over that kind of architecture (eg, the Actor model).

imglorp 9y ago

I think it is time to talk about new directions because we're still STUCK HARD in a rut begun in 1971 for general purpose compute. 4004 -> 8008 -> 8080 -> x86 and here we remain. Requirements and tech have both changed vastly since then. We've made some minor widening, into RISC, GPUs, and VLIW, plus we're just now looking into many cores, now that atomic physics is starting to push back on minimum feature sizes. Two areas that have not been remotely explored are asynchronous design and massively parallel (think Connection Machine). In both cases, the compilers and tools were not up to the task, but perhaps we're ready to give both another try.

dschuetz 9y ago
I think that there have been discussions, but everyone being on this one-big-complex-cpu-doing-everything train over the years made companies pursue financial goals rather than security. You cannot have a complex and secure CPU. That would be too expensive, so it's not a question of will-it-work, rather will-it-sell.
- imglorp 9y ago
  Yeah, security is still not a profit feature.
jcranmer 9y ago
That's a rather closed view of history. Vector processors were the norm in supercomputers until the early 2000s, when they were killed off by general purpose CPUs like SPARC and POWER. Intel itself has made two big bets on alternative architectures--Itanium (essentially VLIW) and Xeon Phi (CMP gone insane), the former of which failed miserably, and the latter of which appears to be quietly dying. One of the major problems with developing alternative highly-parallel architectures is that most algorithms, particularly as they are written in source code today, simply aren't parallelizable. There's only so much ILP that can be extracted, and data parallelism isn't achievable without very heavy annotation of source code. Getting high data parallelism (as GPGPU does) is sometimes possible with algorithmic rewrites, but you're talking about rewriting several portions of your code to make that happen. That's the reason NVidia is successful--they've got an offload model, so you only need to rewrite the kernels that need parallelism, and they've got the proprietary lock-in on CUDA since no one wants to rewrite that code several times. But even then, there are classes of code that can't be run on GPGPUs very well because you just don't have the necessary data parallelism.

madez 9y ago

I think we need more architectures in wide use because a monoculture is bad for many reasons. One reason not so often mentioned is that it's then harder to distribute proprietary binaries.

analognoise 9y ago
If you make a living writing software, that sounds like an argument against more architectures.
- LukeShu 9y ago
  Plenty of people make a living writing FOSS.
  - analognoise 9y ago
    There are exceptions, but the vast majority of commercial software is not FOSS. If anything, with a few shining examples, I've been totally underwhelmed by FOSS.
    - madez 9y ago
      Because governments don't back FOSS like they should.
      - analognoise 9y ago
        Wait, what? Why should governments step in to back FOSS? The city of Munich tried to switch to Linux. They just announced the plan to switch back to Windows - presumably they were underwhelmed too.
        loup-vaillant 9y ago
        I bet path dependence has something to say about that. Try to force people to use Dvorak keyboards at work. Even though that layout is demonstrably better (more comfortable and easier to learn), people are already used to Qwerty, still have a Qwerty keyboard at home, and would generally resist change. Switching to GNU/Linux triggers similar problem: different GUI, still Windows at home, IT has to re-learn everything… Oh, and drivers. These aren't GNU/Linux's fault, but they still tend to underwhelm users. I, mean, seriously: ever tried to have your grandma use LibreOffice? The number one problem won't come from bugs. It won't even come from its inability to read such and such Microsoft Word document. It will come from her inability to "save as .doc" or "save as .pdf" so other people can read the document (and even if she could, it's still a hassle). Network effects are not LibreOffice's fault, but they still tend to underwhelm users.

baybal2 9y ago

>We need heterogeneous systems. If you are to develop a CPU with an ISA level security proof, you need a homogenous system. Something like a simplest MCU with few registers and hardwired instructions, no pipeline or OOOE, and flat memory that can be 100% mathematically verificated.

mpweiher 9y ago
The Transputer T800 was formally verified. It would also be a great candidate vor hardware isolation, with different processes running on different CPUs, linked via the Transputer's hardware channels. https://www.cs.bris.ac.uk/~dave/transputer.html https://www.cs.bris.ac.uk/~dave/transputer.html UPDATE: T800 had 250K transistors, Skylake has 1-2 billion, so you could fit around 4K-8K T800s on the same kind of die.
dschuetz 9y ago
So you are talking about a special purpose processor solely for the purpose of being 100% deterministic? It'll be slow, but potentially more secure than its general purpose counterparts. Which of both would be more reliable security-wise? If you put both in a single system respecting the purposes, a heterogeneous system is the result.
- baybal2 9y ago
  You will still get something very different from HSA's understanding of heterogeneous design or secure enclave processors (although those ones come closer to the idea). The thing that is approaching it the most is a smartcard CPU. Flat X-i-P rom, cacheless, embedded mram or fram, <100 instructions, full register state determinism.

mpweiher 9y ago

> let's not design and implement a hundred different architectures ... > We need heterogeneous systems. The first seems to be a call for fewer, the second for more architectures. Which is it?

dschuetz 9y ago
Rather less the same system architecture reiterated in different cpu architecture implementations (AMD, Intel), and more special purpose processors for a heterogeneous/hybrid system architecture following certain standards.