3 ms·
Simpler Programming for Multicore Computers
- Locke1689 17y agoVery interesting. Here's the paper http://groups.csail.mit.edu/commit/papers/06/gordon-asplos06.pdf http://groups.csail.mit.edu/commit/papers/06/gordon-asplos06..., which is what you really want to read. From my brief perusal, it looks inventive, but maybe not practical. By that I mean that its (as it states in the name) a stream-oriented programming language. If you're calculating FFTs (and many people are, especially in high-performance computing), then this could be very useful. Essentially, your language would fit your coding model, which is much easier than adapting say, C, to the same task. The possible problems I see here are 1) I haven't actually seen a parallelization graph for even something simple like linear algebra vs. number of cores and 2) there are many cases in which I can see this as being just as complicated as threading/semaphores/whatever. If the application you're using does not lend itself to concise representation in the stream metaphor then this could lead to more problems than solutions. For two other "next-gen" languages that seek to yield an implicitly parallel solution, see Manticore (http://manticore.cs.uchicago.edu/ http://manticore.cs.uchicago.edu/ University of Chicago) and Data Parallel Haskell (http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell mostly University of New South Wales but Peyton-Jones is putting in some time as well).
- Locke1689 17y agoOK, so careful reading turns up this gem Our compiler achieves consistent and excellent parallelization of our benchmark suite to a 16-corearchitecture, with a mean speed up of 11.2x over sequential, single-core performance. Unfortunately, I still can't seem to find the standard Time vs. Cores graph.