Hi there. Beeing rather new to the realm of Haskell and functional programming, I&#39;ve been reading about &quot;how is easier it is to parallelize code in a purely functional language&quot; (am I right saying that ?).<br>
<br>My knowledge of parallelization is also very weak, but I&#39;ve been thinking about this and I have a question. Let&#39;s say we take a small piece of code, like the quicksort algorithm.<br><br>&gt; qsort [] = []<br>&gt; qsort (x:xs) = qsort lesser ++ [x] ++ qsort greater
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where lesser = filter (&lt;x) xs<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; greater = filter (&gt;=x) xs<br><br>(actually I didn&#39;t test this code, this is just for the example)<br><br>Here, computing &quot;lesser&quot; and &quot;greater&quot; are two disjoint actions - we don&#39;t need the result from one to compute the other, and haskell does not allow one to alter data so that would change the behaviour of the other. So I guess those could be run in parallel.
<br><br>Would it be fairly simple to automatically determine parts of code that can be run in parallel, and parts that cannot (at least in non-monadic code) ?<br><br>So the final question is : if it is possible to automatically define segments of code that can be run in parallel, is [insert compiler name here] compiling this code as a one thread thing, or as a multithreaded version ?
<br><br>I guess on single processor machines, it is more efficient to do it as a single thread - but with those &quot;many-cores&quot; processors that are coming, it probably won&#39;t be true anymore.<br><br>Sorry if this post is blowing off open doors (I guess this doesn&#39;t mean anything in english but it sounds cool) ...
<br><br>Regards<br><br>Thomas Girod<br><br><br>