3 ms·

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 a

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.
deepnotderp 9y ago
Yay for asynchronous :D It's honestly criminal how little attention async gets. But absolutely disagree on massively parallel processors. What do you think your GPUs, TPUs/DPUs not to mention Tilera types are?
- imglorp 9y ago
  GPU, TPU, DPU, etc are not general purpose compute: they are highly specialized for a certain tasks. Not familiar with Tilera, but it looks like up to 100 cores? That's not what I mean by massive either. CM was massively parallel: 64,000 general purpose processors. I don't think we adequately explored its attributes. I bet we could make a decent emulation of a CM and its support tools now.
pjc50 9y ago
I think it's more the humans that aren't up to the task, or at least have not built enough conceptual infrastructure to make it feasible to program these things. A moderate number of people can grasp the imperative "do this then that" model, which CPUs strive so hard to maintain the appearance of despite speculative and out-of-order execution. Fewer people are comfortable with "functional" style programming. Other paradigms are relegated to corners. Multithreaded programming is still a bit of a black art. Graphics programming only manages parallelism because there's an implicit huge map of "do this to every pixel" around everything. The actual shader programming language .. is imperative, because that's what people understand.
kens 9y ago
> 4004 -> 8008 -> 8080 -> x86 The progression is more interesting than that: it's Datapoint 2200 -> 8008 -> 8080 -> x86. The Datapoint 2200 was a "programmable terminal" (really a desktop computer) that had a CPU made from TTL chips. They got Intel to make a MOS version of the processor, which was the 8008. (TI made a MOS processor for them too, beating Intel with the forgotten TMC 1795.) Because the Datapoint 2200 used serial shift-register memory, it needed to be little endian, and that's why the x86 is little endian. Also, the marketing names make 8008 sound like an 8-bit version of the 4004, but they are really unrelated. The 4004, for instance, wasn't even von Neumann. https://en.wikipedia.org/wiki/Datapoint_2200 https://en.wikipedia.org/wiki/Datapoint_2200

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.

deepnotderp 9y ago

Yay for asynchronous :D It's honestly criminal how little attention async gets. But absolutely disagree on massively parallel processors. What do you think your GPUs, TPUs/DPUs not to mention Tilera types are?

imglorp 9y ago
GPU, TPU, DPU, etc are not general purpose compute: they are highly specialized for a certain tasks. Not familiar with Tilera, but it looks like up to 100 cores? That's not what I mean by massive either. CM was massively parallel: 64,000 general purpose processors. I don't think we adequately explored its attributes. I bet we could make a decent emulation of a CM and its support tools now.

pjc50 9y ago

I think it's more the humans that aren't up to the task, or at least have not built enough conceptual infrastructure to make it feasible to program these things. A moderate number of people can grasp the imperative "do this then that" model, which CPUs strive so hard to maintain the appearance of despite speculative and out-of-order execution. Fewer people are comfortable with "functional" style programming. Other paradigms are relegated to corners. Multithreaded programming is still a bit of a black art. Graphics programming only manages parallelism because there's an implicit huge map of "do this to every pixel" around everything. The actual shader programming language .. is imperative, because that's what people understand.

kens 9y ago

> 4004 -> 8008 -> 8080 -> x86 The progression is more interesting than that: it's Datapoint 2200 -> 8008 -> 8080 -> x86. The Datapoint 2200 was a "programmable terminal" (really a desktop computer) that had a CPU made from TTL chips. They got Intel to make a MOS version of the processor, which was the 8008. (TI made a MOS processor for them too, beating Intel with the forgotten TMC 1795.) Because the Datapoint 2200 used serial shift-register memory, it needed to be little endian, and that's why the x86 is little endian. Also, the marketing names make 8008 sound like an 8-bit version of the 4004, but they are really unrelated. The 4004, for instance, wasn't even von Neumann. https://en.wikipedia.org/wiki/Datapoint_2200 https://en.wikipedia.org/wiki/Datapoint_2200