12 ms·

Maybe it is time to rethink how computers are built? For example, that the kernel is running on a dedicated cpu, with dedicated cache and memory.

by zaxomi 9y ago

meuk 9y ago
I agree, the single, superfast CPU model is outdated. It's a shame that multiprocessor programming is hard (or is it? It might also just be a vicious circle: 'not many people do MPP because the facilities suck because not many people do MPP').
- gaius 9y ago
  Look at the way the Amiga did it. The CPU was effectively a peripheral for the system controller known as Agnus. https://en.m.wikipedia.org/wiki/MOS_Technology_Agnus https://en.m.wikipedia.org/wiki/MOS_Technology_Agnus
  - walkingolof 9y ago
    Thats what the north/southbridge does, off-loading the CPU from all sorts of tasks (even if some of the tasks moved into the CPU die since the classic definition of north/southbridge was set)
- jcranmer 9y ago
  I could right now give you a CPU with a 100,000 ALUs on it. Your CPU with ~4 ALUs is probably going to beat it in performance, because you can easily keep all of your ALUs constantly fed with data, but I'm going to struggle to keep all 100,000 ALUs fed. We have some idea of how to do massively-parallel programming. That is, after all, what a supercomputer is. But one of the things we've found is that communication doesn't scale. For very low core counts, you can hook up each core to talk to every other one at the same latency--basically, O(N)-degree topology. For slightly higher core counts, you can keep it a hypercube, which is O(lg N) degree. But when you start thinking about a few hundred cores, you end up with a mesh, which is O(1)-degree. What that means is you struggle to scale problems that have very high communication costs compared to computation. Matrix multiplication is wonderful--you're doing O(N^1.5) computations for each data, so communication goes down as size goes up [1]. But a BFS graph traversal is horrible, because your communication costs go up if average degree is more than O(1). [1] This is why the TOP500 benchmark is to some degree bullshit. It's measuring performance on applications that are fundamentally computation-bound, not communication bound, so it tends to penalize machines that focus on improving communication bandwidth, which is often helpful for many HPC applications.
masklinn 9y ago
Beyond even that you could imagine erlang-model hardware, with lots of independent µCPU with their own completely private memory communicating via message-passing (CM-style? I don't really know what programming model the Connection Machine used).
- dboreham 9y ago
  Like this: https://en.m.wikipedia.org/wiki/Transputer https://en.m.wikipedia.org/wiki/Transputer
  - masklinn 9y ago
    To an extent. That seems way more coalesced that what I'm talking about, the page seems to talk about low tens of chips as the normal ceiling, with some exceptional cases in the low hundreds. Even the later "fat processor" (RISC) Connection Machines had several hundreds of CPU (the earlier models had tens of thousands of single-bit processors)
walkingolof 9y ago
I think the problem have more to do with software, CPU's are just built to meet the demands. Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO
- masklinn 9y ago
  > I think the problem have more to do with software, CPU's are just built to meet the demands. > Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO These are not recent developments, chip makers could have opted not to use them and software developers would have done otherwise. The hardware is developed to make the existing software faster, but the software is also developed to run well on the current hardware.
  - walkingolof 9y ago
    There was those who tried, for example Inmos with the Transputer, which was _the_ next big thing for a couple of years in the 80's, but unfortunately it never got any traction. https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
- fmap 9y ago
  I think the problems have more to do with economics. Creating new modern CPUs requires a lot of capital investment, making CPU vendors more risk averse. That's why modern CPUs by and large are not built to meet the demands of future software - they're built to meet the demands of Excel 97 (exaggerating slightly for effect). The programming interface of a modern x86 CPU is best thought of as a virtual machine with a JIT. The JIT performs some optimizations to make old code run more in parallel without the need for recompilation. This is a terrible model for compilers and programmers, since it makes optimizations hit or miss, and of course it's why we're in this whole spectre/meltdown mess at the moment. If we switched to a more reasonable programming model which actually met the needs of software (fine grained interprocessor communication without going through central memory, many more registers, actual software access to pipelines, caches, etc.) then it would make a lot of old software run slower (through emulation), but new software could finally make better use of your hardware...
mtgx 9y ago
That would be nice, but how about we at least start at not loading third-party drivers from the kernel?

Maybe it is time to rethink how computers are built? For example, that the kernel is running on a dedicated cpu, with dedicated cache and memory.

by zaxomi 9y ago

Maybe it is time to rethink how computers are built? For example, that the kernel is running on a dedicated cpu, with dedicated cache and memory.

meuk 9y ago

I agree, the single, superfast CPU model is outdated. It's a shame that multiprocessor programming is hard (or is it? It might also just be a vicious circle: 'not many people do MPP because the facilities suck because not many people do MPP').

gaius 9y ago
Look at the way the Amiga did it. The CPU was effectively a peripheral for the system controller known as Agnus. https://en.m.wikipedia.org/wiki/MOS_Technology_Agnus https://en.m.wikipedia.org/wiki/MOS_Technology_Agnus
- walkingolof 9y ago
  Thats what the north/southbridge does, off-loading the CPU from all sorts of tasks (even if some of the tasks moved into the CPU die since the classic definition of north/southbridge was set)
jcranmer 9y ago
I could right now give you a CPU with a 100,000 ALUs on it. Your CPU with ~4 ALUs is probably going to beat it in performance, because you can easily keep all of your ALUs constantly fed with data, but I'm going to struggle to keep all 100,000 ALUs fed. We have some idea of how to do massively-parallel programming. That is, after all, what a supercomputer is. But one of the things we've found is that communication doesn't scale. For very low core counts, you can hook up each core to talk to every other one at the same latency--basically, O(N)-degree topology. For slightly higher core counts, you can keep it a hypercube, which is O(lg N) degree. But when you start thinking about a few hundred cores, you end up with a mesh, which is O(1)-degree. What that means is you struggle to scale problems that have very high communication costs compared to computation. Matrix multiplication is wonderful--you're doing O(N^1.5) computations for each data, so communication goes down as size goes up [1]. But a BFS graph traversal is horrible, because your communication costs go up if average degree is more than O(1). [1] This is why the TOP500 benchmark is to some degree bullshit. It's measuring performance on applications that are fundamentally computation-bound, not communication bound, so it tends to penalize machines that focus on improving communication bandwidth, which is often helpful for many HPC applications.

masklinn 9y ago

Beyond even that you could imagine erlang-model hardware, with lots of independent µCPU with their own completely private memory communicating via message-passing (CM-style? I don't really know what programming model the Connection Machine used).

dboreham 9y ago
Like this: https://en.m.wikipedia.org/wiki/Transputer https://en.m.wikipedia.org/wiki/Transputer
- masklinn 9y ago
  To an extent. That seems way more coalesced that what I'm talking about, the page seems to talk about low tens of chips as the normal ceiling, with some exceptional cases in the low hundreds. Even the later "fat processor" (RISC) Connection Machines had several hundreds of CPU (the earlier models had tens of thousands of single-bit processors)

walkingolof 9y ago

I think the problem have more to do with software, CPU's are just built to meet the demands. Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO

masklinn 9y ago
> I think the problem have more to do with software, CPU's are just built to meet the demands. > Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO These are not recent developments, chip makers could have opted not to use them and software developers would have done otherwise. The hardware is developed to make the existing software faster, but the software is also developed to run well on the current hardware.
- walkingolof 9y ago
  There was those who tried, for example Inmos with the Transputer, which was _the_ next big thing for a couple of years in the 80's, but unfortunately it never got any traction. https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
fmap 9y ago
I think the problems have more to do with economics. Creating new modern CPUs requires a lot of capital investment, making CPU vendors more risk averse. That's why modern CPUs by and large are not built to meet the demands of future software - they're built to meet the demands of Excel 97 (exaggerating slightly for effect). The programming interface of a modern x86 CPU is best thought of as a virtual machine with a JIT. The JIT performs some optimizations to make old code run more in parallel without the need for recompilation. This is a terrible model for compilers and programmers, since it makes optimizations hit or miss, and of course it's why we're in this whole spectre/meltdown mess at the moment. If we switched to a more reasonable programming model which actually met the needs of software (fine grained interprocessor communication without going through central memory, many more registers, actual software access to pipelines, caches, etc.) then it would make a lot of old software run slower (through emulation), but new software could finally make better use of your hardware...

mtgx 9y ago

That would be nice, but how about we at least start at not loading third-party drivers from the kernel?