[erlang-questions] FPGA coming around the corner

Fri Jan 7 13:56:50 CET 2011

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

If that's the case (I haven't delved much into the sources you're citing),
then the real problem here is that these people are panic-mongers.  Legacy
apps are typically written for, and running on, hardware that's 5-10 years
old or older.  Even with Moore's Law running out of steam, the users of
these legacy apps have been getting free speedups every time they retired
old hardware and moved their system to something newer.  And if it was fast
enough 5-10 years ago, it's much more than fast enough now, and on cheaper
hardware to boot.  If it hadn't been fast enough then, or had required
prohibitively expensive hardware, it would have been rejected by its users
back then, and it wouldn't be today's legacy app.

The assumption seems to be that everything must be parallelized for
multi-core.  I fail to see why.

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

At any given time, almost every piece of software sucks and seems it ought
to be rewritten, preferably in a more appropriate language.  (Even I
daydream of how certain C++ features, used judiciously, would go a long way
toward cleaning up the BEAM VM code.)  Dwell on this perennial truth enough,
and you will go insane, guaranteed.

Oh well, as long as this is all really about impotent complaining, let me
jump right in with my own impotent complaint: it drives me crazy that I have
to type a $ in front of every variable name in PHP.  I was doing that in
BASIC in 1971, back when there was some excuse for parsers being stupid.
 What's the excuse now?!  In fact, it drives me crazy that I have to deal
with PHP at all.  But, you know, if I want to hack on skins for MediaWiki (I
do, at least this week, perhaps sanity will return next week), that's what I
have to live with.  The weight of history is great, people and production
software systems and computer languages change only rather slowly, and half
the people out there who are hectoring others about the need for dramatic
change are in fact only trying to sell you something you don't necessarily
need.  What else is new?

-michael turner

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

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