Just a quick random thought.... There's a lot of attention to new parallel programming languages, APIs, messaging packages, interconnect architectures, and so on. All sorts of ways to make it easier for a programmer to express parallel code, and to have it map onto the hardware efficiently.
Being able to program in parallel is a hurdle. It's difficult to get over. I don't want to downplay the challenge of doing it, or the complexity of the work involved in developing a new programming language, etc. If we are to get any benefit at all from multiple cores (apart from running many independent programs simultaneously), we need to get over the hurdle.
But if we get over the hurdle -- what's on the other side? Unless the run time of the program is dominated by processing that can be done in a massively parallel manner, the serial component starts to dominate quickly, and then we get little gain from exponentially increasing numbers of cores. This is the hole we can fall into immediately.
We need to look a few steps ahead. If we clear the hurdle, then what?
DAC 2012: Mystical Confluence: ESL Hockey Stick and The Cup!
-
Another note from DAC 2012: In Gary Smith’s Sunday night pre-DAC talk, he
mentioned that in 2011, ESL tools took off – the famous Hockey Stick. See
his s...
12 years ago
No comments:
Post a Comment