[erlang-questions] FPGA coming around the corner

[Michael Turner]

"... They all sound panic-stricken and suggest there is currently no
complete viable solution out-there yet to programming for the multi-core age
that don't burden the programmer. These are some very smart people. But when
I saw these videos recently I thought "Have they not heard of Erlang? If not
why not?"

If you're overridingly concerned with fault-tolerance and ease of scaling on
multi-core systems, and starting with a clean slate, Erlang makes a lot of
sense.  But that's not the focus of the "panicked" people mentioned here.
 Their interest is in raw performance, and perhaps also very much raw
performance for legacy systems written in more mainstream languages that
people would like to see parallelized.

Erlang's not bad with respect to speed, but it's not great either:
distributing an Erlang program over 5-10 cores might give you the same
speedup you could get on a *single* core in C/C++/Java simply by optimizing
your code savagely.  And requiring programmers to rewrite legacy apps in a
new language with unfamiliar paradigms -- well, it might be good in the long
run, but in the long run, we're all dead, and there's an awful lot of
working, useful code out there.  As pointed out in a recent thread touching
on the raison d'etre for NIFs in Erlang, NIFs are less about making Erlang
code fast and more about interfacing with all the useful stuff people have
been writing and debugging for decades.  And why not?  OTP is large, a great
toolbox, but outside its core strengths, it only scratches the surface of
what people might want to do in software.

Most of these "panic-stricken" people have probably heard of Erlang -- it
just doesn't necessarily solve their problems.  Maybe nothing can.  But
there's been great progress with tools that help model and debug concurrency
in legacy apps, and that's probably going to continue.   They aren't out of
rope yet.  Face it: successful software technologies take a long time to
die.  Whenever you log onto your bank's website, it's virtually guaranteed
that the part of the delay involves cranking up some virtual machine
environment to run some crufty old accounting package written 30 years ago
in COBOL.

-michael turner



On Fri, Jan 7, 2011 at 1:40 PM, Edmond Begumisa <ebegumisa@REDACTED
> wrote:

> If the time is to come, then surely this is the *right time* for the
>> Erlang/OTP 'product' to step up and meet the challenges and mindset that
>> bind us daily owing to the chosen OO style forced onto us by C++/Java.
>>
>
> On a related note: I'm curious -- why is it that many seem unaware of
> Erlang's advantages with multi-core? Even vocal MP experts that are
> advocating for the change in mindset you describe and the need for
> programmers to be aware of the disconnect and quickly adapt -- these
> advocates don't sound like they're aware of Erlang (at least they don't
> mention Erlang in their talks).
>
> A blog post recently alerted me to a talk Maurice Herlihy gave back in 2007
> entitled "Taking Concurrency Seriously: New Directions in Multiprocessor
> Synchronization."
>
> http://www.stanford.edu/class/ee380/Abstracts/070502.html
>
> http://ee380.stanford.edu/cgi-bin/videologger.php?target=070509-ee380-300.asx
>
> To quote him "... Computer architecture is about to undergo, if not another
> revolution, then a vigorous shaking-up. The major chip manufacturers have,
> for the time being, simply given up trying to make processors run faster...
> As a result, system designers and software engineers can no longer rely on
> increasing clock speed to hide software bloat. Instead, they must somehow
> learn to make effective use of increasing parallelism. This adaptation will
> not be easy. Conventional synchronization techniques based on locks and
> conditions are unlikely to be effective in such a demanding environment..."
>
> He then goes on the show some pretty fancy Java code illustrating
> concurrent data structures and a concept he calls "transactional boosting"
> in an attempt to deal with the disconnect without burdening the programmer
> "too much."
>
> There are a number of more recent talks on that Standford page with the
> same tone...
>
> http://www.stanford.edu/class/ee380/previous.html
>
> They all sound panic-stricken and suggest there is currently no complete
> viable solution out-there yet to programming for the multi-core age that
> don't burden the programmer. These are some very smart people. But when I
> saw these videos recently I thought "Have they not heard of Erlang? If not
> why not?"
>
> - Edmond -
>
>
> On Fri, 07 Jan 2011 13:41:14 +1100, Steve Davis <
> steven.charles.davis@REDACTED> wrote:
>
>
>> A very interesting article... and all the more interesting because it
>> lines up with Joe's predictions.
>>
>>
>> http://www.kurzweilai.net/scientists-squeeze-more-than-1000-cores-onto-computer-chip
>>
>>  > “FPGAs are not used within standard computers because they are fairly
>>  > difficult to program, but their processing power is huge while their
>>  > energy consumption is very small because they are so much quicker, so
>>  > they are also a greener option,” said researcher Dr. Wim
>>  > Vanderbauwhede.
>>
>>  > While most computers sold today now contain more than one processing
>>  > core, which allows them to carry out different processes
>>  > simultaneously, traditional multi-core processors must share access
>>  > to one memory source, which slows the system down. The scientists in
>>  > this research were able to make the processor faster by giving each
>>  > core a certain amount of dedicated memory.
>>
>> If the time is to come, then surely this is the *right time* for the
>> Erlang/OTP 'product' to step up and meet the challenges and mindset that
>> bind us daily owing to the chosen OO style forced onto us by C++/Java.
>>
>> /s
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>