4 ms·

Another problem, even in functional code, is that data dependencies tend to be linear. It's difficult to write code that can be automatically parallelized.

jules 14y ago
Actually the problem is a bit more complicated than that. It is often quite easy to write a program with a large degree of parallelism in its data dependencies. The problem is to actually implement an execution strategy with sufficiently low overhead that it speeds up execution. Communication overheads and poor memory locality often overwhelm any gains due to parallel execution.
- DanWaterworth 14y ago
  That's another problem, but writing code that can be parallelized is also non-trivial, especially if you are used to using lists excessively.
- tkellogg 14y ago
  Great points. I recommend actually reading the paper behind the blog post (http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf). I guarantee it'll blow your mind how well the system works. It's much more compete than you imagined.
  - mikhael 14y ago
    I second the call of bullshit. Though I've only skimmed the paper, I don't see any concrete performance numbers. I only see this: "The group has written sev- eral million lines of code, including: core libraries (includ- ing collections with polymorphism over element permis- sions and data-parallel operations when safe), a webserver, a high level optimizing compiler, and an MPEG decoder. These and other applications written in the source language are performance-competitive with established implementa- tions on standard benchmarks; we mention this not because our language design is focused on performance, but merely to point out that heavy use of reference immutability, includ- ing removing mutable static/global state, has not come at the cost of performance in the experience of the Microsoft team."
    - tkellogg 14y ago
      You forgot to read all the text you just copied: "we mention this not because our language design is focused on performance, but merely to point out that heavy use of reference immutability, ...has not come at the cost of performance in the experience of the Microsoft team." Stop trolling

jules 14y ago

Actually the problem is a bit more complicated than that. It is often quite easy to write a program with a large degree of parallelism in its data dependencies. The problem is to actually implement an execution strategy with sufficiently low overhead that it speeds up execution. Communication overheads and poor memory locality often overwhelm any gains due to parallel execution.

DanWaterworth 14y ago
That's another problem, but writing code that can be parallelized is also non-trivial, especially if you are used to using lists excessively.
tkellogg 14y ago
Great points. I recommend actually reading the paper behind the blog post (http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf http://research.microsoft.com/pubs/170528/msr-tr-2012-79.pdf). I guarantee it'll blow your mind how well the system works. It's much more compete than you imagined.
- mikhael 14y ago
  I second the call of bullshit. Though I've only skimmed the paper, I don't see any concrete performance numbers. I only see this: "The group has written sev- eral million lines of code, including: core libraries (includ- ing collections with polymorphism over element permis- sions and data-parallel operations when safe), a webserver, a high level optimizing compiler, and an MPEG decoder. These and other applications written in the source language are performance-competitive with established implementa- tions on standard benchmarks; we mention this not because our language design is focused on performance, but merely to point out that heavy use of reference immutability, includ- ing removing mutable static/global state, has not come at the cost of performance in the experience of the Microsoft team."
  - tkellogg 14y ago
    You forgot to read all the text you just copied: "we mention this not because our language design is focused on performance, but merely to point out that heavy use of reference immutability, ...has not come at the cost of performance in the experience of the Microsoft team." Stop trolling