[erlang-questions] Keeping massive concurrency when interfacing with C

[Joe Armstrong]

On Mon, Oct 3, 2011 at 3:44 AM, John Smith <emailregaccount@REDACTED> wrote:
> Thanks for the reply, Kresten!
>
> I definitely would not be doing any disk I/O in the C code. It would
> be intense number crunching, so it would be CPU (and perhaps memory)
> bound. Everything I've read states Erlang is not good at number
> brunching (Cesarini mentions this in his "Erlang Programming" book) so

This may not be true - I wrote some crypto stuff in Erlang with bignums
and it turned out to be faster than some C I had. I guess this was because
I could write a more advance algorithm than in C - but I never
investigated why. I would expect small fixed types and array type algorithms
to be faster in C, but not necessarily bignum computations.

Also bear in mind that the C and Erlang will not be solving the same problem
In C you might have to protect the code from buffer overflow attacks
but In Erlang this would not be necessary. Also Erlang is slower *by design*
to allow for code-changes on-the-fly which C cannot do.

So saying Erlang is "not good at number crunching" is only a first
approximation to the truth ... true for most things, but not a universal truth
for which you have to read the small print ...


> I'm considering writing the code to do that in C.

Just curious - what type of "intense number crunching?" - there are
different types of number crunching - things like digital image
processing involve identical computations on a grid - so could be done
on a GPU - other operations may or may not be suitable to a GPU. If
the CPU demands are very-variable upping the number of cores and
changing to a Tilera might help.

The time and memory properties of the C are also interesting - do the
C tasks always take the same time/memory or are they highly variable?
This can effect the scheduling strategy - you might get CPU or memory
starvation.

Although number crunching might be faster in C than Erlang the round-trip
times become important if you do relatively little work in C. You might spend
more time in communication than the time you save in being faster in C.

I'd start by making a pure Erlang solution and then measuring to see where
the problems are - Guessing where the time goes is notoriously difficult - even
if the the pure Erlang solution is not fast enough the code can provide
a useful reference implementation to start with and should be up-and-running
quicker than if you start coding NIFS etc.

Virtually every time I've had a program that was too slow, and I've guessed
where the problem was I've been wrong - so I'd build a reference
implementation first then measure - then optimize.

Cheers

/Joe


> If I call a NIF, only the particular scheduler that manages that
> Erlang process would be blocked and no other scheduler, right? So for
> example, if I have a CPU with eight cores, and an Erlang scheduler
> thread is running on each core, and say the third scheduler is
> executing an Erlang process that calls a NIF (and so blocks), only
> that scheduler would be blocked until the NIF finishes executing,
> correct?
>
> I'm debating which solution would be better. Erlang would be slower at
> number crunching, but is extremely efficient at managing concurrent
> executing processes, meaning each would gradually make progress every
> X units of time since they'll all get a turn to execute. But I wonder
> if having a single process execute NIF code until it finishes (and so
> all the processes managed by a single scheduler execute serially)
> would be faster than implementing it all in Erlang and having
> processes execute concurrently within a single scheduler (albeit the
> code would be slower to execute). There would be less overhead of
> Erlang process context switching (although admittedly that isn't much
> to begin with) and the C code would be faster at number crunching. I
> suppose there's only one way to find out! :)
>
> I was also thinking about writing the number crunching code in some
> other language than C, such as OCaml. OCaml has a reputation for being
> as fast as C, yet not nearly as low-level. Maybe that would be a good
> fit with Erlang.
>
> Example benchmarks:
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=hipe&lang2=gpp
>
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ocaml
>
> The Erlang benchmark was using HiPE as well.
>
> Thanks for the suggestion!
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>