<div dir="ltr">I discussed the problems with a general pmap in a presentation back in 2009.<div><br></div><div><a href="https://www.infoq.com/presentations/wiger-multicore-erlang">https://www.infoq.com/presentations/wiger-multicore-erlang</a><br></div><div><br></div><div>The purpose wasn't really to argue against a general pmap, but rather to use it as a simple example to illustrate the problems with treating erlang processes as 'fibers' rather than independent actors.</div><div><br></div><div>BR,</div><div>Ulf W</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-22 10:42 GMT+02:00 Ola Andersson A <span dir="ltr"><<a href="mailto:ola.a.andersson@ericsson.com" target="_blank">ola.a.andersson@ericsson.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reading the discussion about list:mapfind reminded me of a function I rediscovered recently.<br>
It's rpc:pmap/3 that was originally defined for use in a distributed environment, spreading out the processing over several nodes. It actually works on a single multicore node as well even though it wasn't designed for that purpose.<br>
With the limited tests I have done it seems to significantly outperform lists:map/2 and also scale reasonably well. The almost negligible cost of spawning erlang processes is still amazing.<br>
How about adding a lists:pmap/2 function, designed for multicore, in the lists module?<br>
/OLA.<br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>