3 ms·

I've always wondered why the need for ghz, isn't mips what you're looking for. wouldn't a 50mhz 1000 core cpu do well with decent parallelism in a compiler? ho

I've always wondered why the need for ghz, isn't mips what you're looking for. wouldn't a 50mhz 1000 core cpu do well with decent parallelism in a compiler? how many cycles does the average method/function/procedure need anyway?

mox1 10y ago
The main problem is that generic parallelism is hard, and doesn't give you a straight X multiple speed up[1]. 1. https://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_law_and_Gustafson.27s_law https://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_...
chriswarbo 10y ago
The standard response is to quote Amdahl's Law https://en.wikipedia.org/wiki/Amdahl's_law https://en.wikipedia.org/wiki/Amdahl's_law If 90% of your runtime can be done in parallel, you still have to wait for that last 10%. You can hit this limit with 10 cores (1 processing the 10% that's serial, the other 9 processing the 90% in parallel). If you throw 1000 cores at the problem, you'll have 999 cores processing the 90% in parallel, each performing 0.09% of the workload, but you'll still have 1 core doing the 10% that's serial. Those 999 cores will be idle for 99% of the time, waiting for that last core to finish. The counter-argument is Gustafson's Law https://en.wikipedia.org/wiki/Gustafson%27s_law https://en.wikipedia.org/wiki/Gustafson%27s_law This says that people don't choose a particular task, then wait for a computer to do it. Instead, the choice of which task to perform depends on what the computer can manage. Hence the user of a 1000 core machine will choose to do different tasks than the user of a 10 core machine, or a 1 core machine. Whilst Gustafson's Law is clear from experience (a PlayStation 4 isn't used to run Pacman really fast), Amdahl's Law is the one that's relevant for compilers: a "sufficiently smart compiler" can alter your code in all sorts of ways, but the resulting executable must still perform the same task (otherwise it's a bug!). There might be an approach based on e.g. writing an abstract specification and deriving a program which is suitable for the given hardware, but that's a long way off (for non-trivial tasks, at least).

mox1 10y ago

The main problem is that generic parallelism is hard, and doesn't give you a straight X multiple speed up[1]. 1. https://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_law_and_Gustafson.27s_law https://en.wikipedia.org/wiki/Parallel_computing#Amdahl.27s_...

chriswarbo 10y ago

The standard response is to quote Amdahl's Law https://en.wikipedia.org/wiki/Amdahl's_law https://en.wikipedia.org/wiki/Amdahl's_law If 90% of your runtime can be done in parallel, you still have to wait for that last 10%. You can hit this limit with 10 cores (1 processing the 10% that's serial, the other 9 processing the 90% in parallel). If you throw 1000 cores at the problem, you'll have 999 cores processing the 90% in parallel, each performing 0.09% of the workload, but you'll still have 1 core doing the 10% that's serial. Those 999 cores will be idle for 99% of the time, waiting for that last core to finish. The counter-argument is Gustafson's Law https://en.wikipedia.org/wiki/Gustafson%27s_law https://en.wikipedia.org/wiki/Gustafson%27s_law This says that people don't choose a particular task, then wait for a computer to do it. Instead, the choice of which task to perform depends on what the computer can manage. Hence the user of a 1000 core machine will choose to do different tasks than the user of a 10 core machine, or a 1 core machine. Whilst Gustafson's Law is clear from experience (a PlayStation 4 isn't used to run Pacman really fast), Amdahl's Law is the one that's relevant for compilers: a "sufficiently smart compiler" can alter your code in all sorts of ways, but the resulting executable must still perform the same task (otherwise it's a bug!). There might be an approach based on e.g. writing an abstract specification and deriving a program which is suitable for the given hardware, but that's a long way off (for non-trivial tasks, at least).