[erlang-questions] FPGA coming around the corner

[Jesper Louis Andersen]

On Sat, Jan 8, 2011 at 17:35, Edmond Begumisa
<ebegumisa@REDACTED> wrote:
> Two statements stood out for me here...
>
> 1. "…Established [languages] concentrate on primary differentiator - SPEED…"
>
> This probably explains what the panic is about in other language camps. The
> worry that the speed differentiator is being threatened. That programs might
> run slower unless big adaptations are made to programming for SMP. Hmmmm...
> maybe this is a sign!

I have this notion that I call the computational gaps. Suppose a
sequential C program is 10 times faster than a sequential Erlang
program. Now, assume near-perfect speedup is possible for the program
(it is embarrassingly parallel). The gap is then 10, as if we had 10
cores, we could run as fast as the C program. If we had 100 cores, we
would be 10 times faster. If we had 1000 cores, 100 times faster and
so on.

The CPUs today are much faster than the memory. Even for the L1 cache
hits, there is an overhead. Essentially, there is not always a reason
to make the CPU run faster - as the extra cycles is used by doing
nothing but waiting on main memory. This gives you a credit of
essentially free instructions before the next memory load can be
satisfied. This is another example of a computational gap.

A third one can be had by waiting on disk or network. While we are
waiting and have nothing else to do, we could use the cycles for
something else. Another gap.

The speed argument is disrupted by gaps. In the SMP case, the
disruption happens because of parallelism. In the second and third
cases, the gap occurs and disrupts due to concurrency as well: If we
can schedule another operation while waiting, the final throughput of
our work will be a lot better. Some of the gaps are driven mostly by
hardware (e.g. SMP) and some are driven mostly by the complexity needs
of software (the concurrency need).

> 2. "…My criteria: [destructive] technology must
>   - Have disadvantages
>   - Be mostly ignored by recent PLD and POPL conferences*
>   - Alleviate real problems…"

It looks like POPL has mostly ignored the problem for some years, so
we are set for that one.

We are also set for the disadvantages: Erlang is not known for its
blazing numerical computational speed when a brute force method is the
fastest. Interestingly it often does not matter. Partially due to the
gaps I presume.


-- 
J.