3 ms·
A great read. Just a couple of things that jumped out at me: “In functional languages automatic analysis of functions and finding good candidates for concurren
by evincarofautumn 15y ago
A great read. Just a couple of things that jumped out at me:
“In functional languages automatic analysis of functions and finding good candidates for concurrent execution is as trivial as automatic inlining!”
It isn’t exactly trivial. If you can evaluate anything concurrently, then you still have to figure out what’s worth the overhead of spinning up a thread to run concurrently. And many operations are inherently sequential even if they aren’t imperative or side-effectful—parsing, for example. Still, the gist is that concurrency is easiest in a pure language and a functional style, and I have no bones to pick with that.
“…infinite data structures, something that's much more complicated in a strict language.”
Infinite structures are still pretty easy to construct in strict languages. For example, you can use ranges of the sort in D’s std.range library, as described in Alexandrescu’s “Iterators Must Go!” talk.
- fusiongyro 15y agoOf course benchmarking is essential, but the Control.Parallel library can decouple expressions to run in parallel (called sparks) from threads, and manages the whole shebang for you. You more-or-less say x `pseq` y and it will try to evaluate them in separate threads if possible. The RTS statistics will tell you how many sparks got "converted" to run on another CPU and whatnot, so you can compare and see if you actually got an improvement, but it is a bit easier than spinning up dedicated threads, assuming you're parallelizing pure computations. For true concurrency, you still need to deal with threads.