4 ms·

Why do you think we need to increase individual clock speeds past their current limits?

baq 9y ago
due to Amdahl's law, it's always better to have a single faster processor than multiple slower ones. ...but do we really need faster processors? i don't know, but i'd like to have one :)
- chrisseaton 9y ago
  > due to Amdahl's law, it's always better to have a single faster processor than multiple slower ones This is not what Amdahl's law says. Amdahl's law gives you a theoretical maximum speedup given a program with a sequential component and a given number of processors. So as long as that speedup is higher than your faster processor is faster then it does make sense to have multiple slower processors than one faster one.
- rbanffy 9y ago
  It's easy to think we need faster processors when the architectures we use, both software and hardware, are incredibly inefficient. Any modern processor is much faster than the RAM its programs and data live on, hence the multiple levels of cache inside them. Multi-cores add the complexity of keeping the memory consistent. Multiple threads per core put additional pressure on caches while our OSs assume all processors see a unique and consistent memory image (which requires keeping caches consistent across cores). Our most common software doesn't run on GPUs before extensive changes. Only mobile platforms are exploring asymmetric multiprocessing with a single ISA now. I don't think we need faster single-thread performance. What I think we need is to adapt our software, which is designed to run on ridiculously fast copies of ancient personal computers, to run on computers that instead of mimicking a successful product of the 80s resemble more what we can do now. We need software that exploits the SIMD units (predicate bits that prevent branches are your friends there), that runs well in multiple cores and OSs that can deal with memory inconsistency between cores (maybe using write-through instructions for shared data and write-back for process-local stuff). We need software that doesn't need complicated instruction reordering or speculative execution.

baq 9y ago

due to Amdahl's law, it's always better to have a single faster processor than multiple slower ones. ...but do we really need faster processors? i don't know, but i'd like to have one :)

chrisseaton 9y ago
> due to Amdahl's law, it's always better to have a single faster processor than multiple slower ones This is not what Amdahl's law says. Amdahl's law gives you a theoretical maximum speedup given a program with a sequential component and a given number of processors. So as long as that speedup is higher than your faster processor is faster then it does make sense to have multiple slower processors than one faster one.
rbanffy 9y ago
It's easy to think we need faster processors when the architectures we use, both software and hardware, are incredibly inefficient. Any modern processor is much faster than the RAM its programs and data live on, hence the multiple levels of cache inside them. Multi-cores add the complexity of keeping the memory consistent. Multiple threads per core put additional pressure on caches while our OSs assume all processors see a unique and consistent memory image (which requires keeping caches consistent across cores). Our most common software doesn't run on GPUs before extensive changes. Only mobile platforms are exploring asymmetric multiprocessing with a single ISA now. I don't think we need faster single-thread performance. What I think we need is to adapt our software, which is designed to run on ridiculously fast copies of ancient personal computers, to run on computers that instead of mimicking a successful product of the 80s resemble more what we can do now. We need software that exploits the SIMD units (predicate bits that prevent branches are your friends there), that runs well in multiple cores and OSs that can deal with memory inconsistency between cores (maybe using write-through instructions for shared data and write-back for process-local stuff). We need software that doesn't need complicated instruction reordering or speculative execution.