<div dir="ltr"><div><div><div><div><div>There are many issues you need to address if you are going to add a "standard" pmap to your library. Some have already been mentioned like how much parallelism and are you going to preserve the list order, which I think is critical.<br><br></div>Another one is what to do when you get an error. There are some obvious alternatives:</div><div><br></div>- If you get an error crash all the processes and return an error pretty much in the same way map does<br></div>- Always return the full list but indicate which elements worked and which didn't, or maybe just return a default "error" value<br><br></div>But you could always do something for your specific case.<br><br></div>Robert<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 August 2017 at 13:31, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@wiger.net" target="_blank">ulf@wiger.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">https://www.infoq.com/<wbr>presentations/wiger-multicore-<wbr>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="HOEnZb"><div class="h5"><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><wbr>:<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" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div>