[erlang-questions] Parallel Shootout & a style question
Richard A. O'Keefe
ok@REDACTED
Wed Sep 3 01:49:17 CEST 2008
On 2 Sep 2008, at 8:21 pm, Ulf Wiger (TN/EAB) wrote:
> However, if the library functions perform a lightweight
> check and pick the parallel version only if SMP is enabled,
> we're not talking 10%.
Seems to me that the "lightest weight" way to do this is at
load time. Suppose there is a directory D where the loader
looks for BEAM files. Then give it two subdirectories
D/SMP/ for SMP-optimised versions
D/UNI/ for uniprocessor-optimised versions
D/ for code that doesn't care.
An SMP-enabled loader looking for x.beam first looks for
D/SMP/x.beam then D/x.beam; an SML-disabled one looks first
for D/UNI/x.beam then D/x.beam.
Come to think of it, this is pretty much how Solaris handles
the 64-bit -vs- 32-bit libraries issue, use the same name but
look in different directories.
However, I must say that I have a hard time believing in any
of this for Erlang. We should not be looking for ways to cope
with an overhead of 10% but for ways to reduce it to the point
where it isn't worth our time fussing about it.
>
>
> erlang:system_info(smp_support) -> boolean()
>
> seems to hit the spot.
But what does "SMP" mean? Do we really expect that the
performance tradeoffs will be *exactly* the same for
dual-core Pentiums, dual quad-core Pentiums, SPARC T3s,
Tilera processors, ... all sorts of machines with varying
inter-cpu costs and above all different memory subsystems?
> Perhaps an alias, like smp() -> boolean() could ease
> the strain on our eyes and prevent carpal-tunnel
> syndrome:
>
> map(F, L) when smp() -> pmap(F, L);
> map(F, L) ->
> [F(X) || X <- L].
But if
- F sends or receives messages, or
- F reads or writes the process dictionary, or
- other things I'm sure you can imagine
these two have DIFFERENT SEMANTICS. The decision
between them is not a matter of whether SMP is
supported or not, but of what the programmer
*means*. In cases where the two compute the same
result, the right choice might well depend on what
*other* parallelism is happening.
More information about the erlang-questions
mailing list