2 ms·

Yeah, but other than some specialised tasks, most code will never be written to be massively multi-threaded. This is an incredibly difficult endeavour and for m

by hristov 17y ago

Yeah, but other than some specialised tasks, most code will never be written to be massively multi-threaded. This is an incredibly difficult endeavour and for many tasks it may be downright impossible. This the Itanium thinking all over again -- lets make a CPU for which code is incredibly hard to write for, and the programmers will come because our CPU is so nifty. I think Intel have learned their lessons and are now making CPUs according to code people are already writing and not according to something that may happen in the future. And it is usually worth it to spend a lot of silicon to speed up a single pipeline because programmers do not have time and resources for the incredibly difficult task of efficiently splitting their code into 100 threads. As PG said, the most important resource to be optimised nowadays is not speed of execution, but programmer time.

jules 17y ago
Luckily the world seems to be so that the things that have to be fast also happen to be relatively easy to parallelize (most tasks using huge data sets, rendering, matrix operations, ...). What are applications that have to be fast but are not easy to parallelize?
Daniel_Newby 17y ago
I disagree that parallelization is abnormally difficult. We just don't yet have the tools to help. It is like trying to do objected oriented programming back in the assembly language days: to be avoided except where absolutely necessary. With appropriate library support, many personal computing tasks are amenable to map-reduce approaches. Can you think of any highly serial desktop apps? All I come up with is certain spreadsheets, and the final step of assigning page breaks during document pagination. What killed Itanium was Intel's childish obsession with clock rate and single-threaded performance. It turned out that back end software was limited by off-chip bandwidth and had already been forced to parallelize at any cost, while front end software was slowed down by trivially parallelizable graphics and signal processing. Itanium is an excellent solution, just to the wrong problem.

by hristov 17y ago

jules 17y ago

Luckily the world seems to be so that the things that have to be fast also happen to be relatively easy to parallelize (most tasks using huge data sets, rendering, matrix operations, ...). What are applications that have to be fast but are not easy to parallelize?

Daniel_Newby 17y ago

I disagree that parallelization is abnormally difficult. We just don't yet have the tools to help. It is like trying to do objected oriented programming back in the assembly language days: to be avoided except where absolutely necessary. With appropriate library support, many personal computing tasks are amenable to map-reduce approaches. Can you think of any highly serial desktop apps? All I come up with is certain spreadsheets, and the final step of assigning page breaks during document pagination. What killed Itanium was Intel's childish obsession with clock rate and single-threaded performance. It turned out that back end software was limited by off-chip bandwidth and had already been forced to parallelize at any cost, while front end software was slowed down by trivially parallelizable graphics and signal processing. Itanium is an excellent solution, just to the wrong problem.