Erlang-ALE efficiency

[Robert Virding]

Has anyone done any serious tests on the Raspberry Pi to compare the speed of using erlang-ale compared to doing NIFs which use memory mapping. Not just "raw" speed but also latency?

Robert

[Frank Hunleth]

Hi Robert,

I've never done a latency comparison. I had only seen gpio
toggles/second benchmarks when I worked on erlang-ale and that's been
some time ago.

While you didn't ask this, I have reservations about going down the
memory mapping route based on both working with erlang-ale and
contributing several fixes back to the project. The first is
maintenance. The gpio and other hardware isn't exactly trivial to
initialize or use, and it changes on every platform. Even the
Raspberry Pi 1 and 2 are different enough to require changes. For
example, erlang-ale contained PWM code that worked via poking at
memory through /dev/mem. That code only worked on the original
Raspberry Pis and eventually was removed since it didn't seem like
anyone wanted to maintain it.

If you're just interested in performance and latency, I think that you
have to consider specific use cases rather than generic gpio. An
absurd example would be if you were interested in driving a display
via gpio's. In theory, if you could twiddle bits fast enough and with
low enough latency (ignoring electrical interface issues), you could
drive a display via Erlang. That doesn't make sense though, since
there's specialized hardware and Linux drivers available that do a
better job and offload the work from the main CPU. It's the same with
almost every other device that I can think of. For example if you're
sampling an ADC or an IMU, there are realtime deadlines involved or
you'll miss samples. Some of these devices can send quite a bit of
data. Linux has a driver framework called IIO that collects samples
(completely in kernel and sometimes using DMA), buffers the samples to
apps, and supports a large selection of devices. I shouldn't pick on
Erlang, though, since I have the same argument for preferring specific
Linux kernel drivers when I write userland C code too.

In my work with erlang-ale and in C, I pretty much only use the
generic GPIO interface for enabling/disabling hardware peripherals,
status LEDs (although the Linux LED class driver is more convenient),
buttons (if I can't hook them up to the gpio-keys driver), and reading
simple status indicators. The generic I2C and SPI interfaces I mostly
use for device configuration. It is rare for me to use them for data
collection unless it's something like a temperature sensor or a
battery status check that I only check intermittently. None of those
examples need much performance, so optimizing erlang-ale wasn't all
that important to me. I used to be of the opinion that changing
erlang-ale to a NIF wasn't worth any risk to destabilizing the Erlang
VM. The code, now, seems so benign that I'm less concerned now. There
is possibly a security concern since accessing hardware via a NIF
would mean that the whole Erlang VM would need elevated privileges to
manipulate hw via the Linux class interface or open /dev/mem, right?

Apologies for the long email that doesn't help you at all with your
question. My hope is that if anyone has energy to make Erlang work
better with hardware I/O, that they put that towards integrating with
the major Linux I/O subsystems (like IIO or any of the higher level
class drivers) or maintaining a multiplatform serial driver rather
than spending a lot of time making gpio access as fast as possible. In
my opinion, that work would be more useful, perform better, and be
more maintainable in the long run.

Regards,
Frank

[Stuart Thackray]

Think Frank said it well.

I did have problems when erlang ale was doing system logs (https://github.com/esl/erlang_ale/commit/029dfcc90059ec80e8b3df424d44d1f26c8daa2b); it was on the original pi (lot less powerful). Otherwise my basic interactions have had no issues with speed/latency. 

Regards,

Stuart