[erlang-questions] Parallel Shootout & a style question
Tue Sep 2 11:08:21 CEST 2008
I'm not sure if it is good idea at all. If F function is very cheap and
result or parameter is large (copy of it is more expensive in comparison to
F expense) parallel version of pmap can be slower than serial version even
many cores is used. Developer should be able control size of parallelized
bunch and switch off parallel process fully. For example pmap(fun(X) ->
[0|X] end, [lists:seq(1,1000000)]) is really bad idea and I will not be
happy if lists:map will be changed to pmap automatically at default ;-)
On Tue, Sep 2, 2008 at 10:21 AM, Ulf Wiger (TN/EAB)
> Mats Cronqvist skrev:
> > Gleb Peregud wrote:
> >> Maybe it is good idea to include something like
> >> http://code.google.com/p/plists/ into Erlang/OTP? It will probably
> >> introduce more less tuned software created by developers, but it
> >> will make programming multi-core systems much more easier and fun
> >> for beginners.
> > in an ideal world, all the basic OTP libs should be rewritten to be
> > parallel. who gives an expletive if it's 10% slower on a single core
> > machine?
> Radical, but you have a point.
> Before Robert reminds me, I might as well admit that I
> scolded him severely for rewriting lists:map/2 as a
> list comprehension, back in those days when LCs were
> slower. Sorry Robert (but I was right ;-)
> I am pretty sure that 10% means a lot to some people
> out there.
> However, if the library functions perform a lightweight
> check and pick the parallel version only if SMP is enabled,
> we're not talking 10%.
> erlang:system_info(smp_support) -> boolean()
> seems to hit the spot.
> Perhaps an alias, like smp() -> boolean() could ease
> the strain on our eyes and prevent carpal-tunnel
> map(F, L) when smp() -> pmap(F, L);
> map(F, L) ->
> [F(X) || X <- L].
> Ulf W
> erlang-questions mailing list
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions