3 ms·
It think you are incorrect in your last statement. All functors are inherently parallelisable. This means that any map operation is parallelisable. Also as l
by mikekchar 10y ago
It think you are incorrect in your last statement. All functors are inherently parallelisable. This means that any map operation is parallelisable. Also as long as the operations are associative (which is a surprisingly large number of cases), your reduce operations will also be parallelisable. That means that any computation that can be represented by a map/reduce is usually fully parallelisable and always paralellisable in the map operation. The only operations that aren't paralellisable are those that depend on the previous values (and even then you can make judicious use of partial function application to cut down on the dependencies). Basically this is where you have effects where order matters and recursive calls.
I think the main reason we have difficulty imagining massively parallel computing systems is that we hold onto mutable state and imperative syntax. This pretty much forces us into a situation where order is significant. It seems to me that abandoning that idea is the key to freeing ourselves up, programming-wise. Personally, I don't find pure fp, or immutable OO that much harder than imperative. Different, for sure, but both have advantages and disadvantages.
- dagss 10y agoNo. As someone who has spent five years programming computing clusters, I have seen many problems that are fundamentally hard to parallelize. If it falls within mapreduce you are basically "done" no matter what language you use (no need to argue fp vs imperative) but very many interesting problems to solve doesn't. I am a big believer in FP too, but for other reasons.
- mikekchar 10y agoI can't edit my previous statement, but after spending more than a couple minutes thinking about it, I can see I was wrong. It's quite convenient to have downvotes to clue you in when you get things wrong, even if it is embarrassing ;-)