[erlang-questions] FPGA coming around the corner

Fri Jan 7 07:44:59 CET 2011

On Fri, 07 Jan 2011 16:04:23 +1100, Michael Turner  
<michael.eugene.turner@REDACTED> wrote:

> "... 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.

(Assuming this is true) It's kind of the point! The fact that you don't  
have to do much to get the speed up with the parallelised Erlang program!  
That using your scale, the same speed up is obtained by...

a) Running the parallelised Erlang program on multi-core with little  
change & no savage optimisation, versus
b) Savagely optimising the single core C/C++/Java, OR
c) beating both by parallelising the C/C++/Java code on multi-core and  
loosing your mind in the process (again, assuming the code in question  
runs sequentially faster in these languages)

> 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.

But that's precisely what these advocates are warning their audiences  
about! That the *legacy apps and code will have to be re-written* in order  
to be parallelised for multi-core. That's what the panic is about. That  
these programs and libraries will need to be carefully re-coded using lots  
of threads, concurrent data structures and unfamiliar paradigms like  
"transactional boosting."

The Herlihy's are effectively saying: "You will need to re-write you're  
apps and libs in order for your users not to complain that things are  
slower, and here's a bunch of tools you can use that we *hope* will make  
it a little easier. But it will still be pretty hard."

My issue is that these tools really suck! May as well just re-write the  
damn thing in Erlang :)

> 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
>>
>>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/