4 ms·
As far as the practical value of an auto-parallelizing compiler goes, I'd like to see it before I believe it. I've got no doubt that the compiler is pulling it
by bunderbunder 14y ago
As far as the practical value of an auto-parallelizing compiler goes, I'd like to see it before I believe it. I've got no doubt that the compiler is pulling it off. But with how young the technology is, I'd be downright amazed if they've got something that can reliably outdo what a knowledgeable human can manage with a reasonable amount of effort. Not that I wouldn't like to see things get to that point.
For now, though, what's really interesting to me is the idea of language-level support for managing mutability. I agree with the author that that's something that both functional and imperative languages have generally fail to provide much help with. And I think there really is a need for language-level support for it. It's always possible to pass in a mutable subtype or a non-pure function as an argument to a procedure at run-time. So without some way to say, "This parameter requires pure arguments," it may not even be possible for a programmer to verify that a module can, e.g., cope with concurrency in code that uses any degree of inversion of control.
- spectre 14y agoA programmer is always capable of writing better parallel code then such a compiler but writing safe and correct parallel code is beyond the skills of many programmers. A good analogy is that a good programmer can hand write assembly that out performs compiled code but that is too hard for most programmers to achieve. There is some interesting research into languages that explicitly control mutability and object reachability (A set of objects don't need to be immutable if we can guarantee that only one thread has access to them). http://ecs.victoria.ac.nz/foswiki/pub/Main/TechnicalReportSeries/ECSTR12-18.pdf http://ecs.victoria.ac.nz/foswiki/pub/Main/TechnicalReportSe...