4 ms·

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,

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...
- andars 9y ago
  > more CPU vendors more risk averse Seeing how Itanium went, their risk aversion seems pretty wise. Itanium seems to satisfy most of your desires with its VLIW/EPIC architecture, which exposes much more to the compiler.
  - deepnotderp 9y ago
    The Itanic really doesn't seem fair as a reason to be un-innovative. It did okay in HPC and Bob Rau's untimely death helped hamper it.

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...

andars 9y ago
> more CPU vendors more risk averse Seeing how Itanium went, their risk aversion seems pretty wise. Itanium seems to satisfy most of your desires with its VLIW/EPIC architecture, which exposes much more to the compiler.
- deepnotderp 9y ago
  The Itanic really doesn't seem fair as a reason to be un-innovative. It did okay in HPC and Bob Rau's untimely death helped hamper it.