[erlang-questions] Parallel Shootout & a style question

Richard A. O'Keefe <>
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