3 ms·
I heard this too but in my exploration of functional programming I found little to back this up. Automatically deciding whether it's worth running a given funct
by svachalek 14y ago
I heard this too but in my exploration of functional programming I found little to back this up. Automatically deciding whether it's worth running a given function on a different processor or not (i.e. whether the overhead is greater or less than the savings on the wall clock) is not so much different than the halting problem and many implementations either don't try it or don't do it well. Also, every practical functional program needs to deal with the real world, whether it's in a "pure" (Haskell) form or not, and one way or another this introduces ordering constraints that work against parallelization.
- spikels 14y agoI guess I was thinking that the functional language's compiler/interpreter would deal with spreading the work across the cores when appropriate. For example if a billion item data structure is feed into some function, say a map that reformats a string, it would be sent to as many cores as were available to simultaneously process a portion of the data then recombine the results (kinda like how Hadoop works). Obviously this is not trivial but certainly seems easier than either doing this automatically in a language with side effects or manually programming the multi-core logic. None of the languages I've uses can do anything like this but I thought Haskell and some of the new generation of languages were headed that way.