[erlang-questions] FPGA coming around the corner

Sat Jan 8 16:01:00 CET 2011

On Sat, 08 Jan 2011 05:27:07 +1100, Attila Rajmund Nohl  
<attila.r.nohl@REDACTED> wrote:

> 2011/1/7, Edmond Begumisa <ebegumisa@REDACTED>:
>> On Fri, 07 Jan 2011 22:58:50 +1100, Attila Rajmund Nohl
> [...]
>>> Erlang is not a "silver bullet for multicore".
>>
>> I don't think it is either! My point was parallelising parallel-able  
>> code
>> is much much easier in Erlang than some of the options being offered up
>> for the same purpose in other programming environments. It's as though  
>> the
>> Erlang team has done most of the heavy lifting regarding SMP for you so
>> you don't have to go looking at "transactional boosting."
>
> In a previous project I was working on, we had a C++ server
> implementing some CORBA functions. Some stub code had to be generated
> from the IDLs, then our code had to inherit from these generated
> classes. The orber run all requests in a separate thread - essentially
> we got parallelism for free (i.e. no extra programming necessary).
>

[NOTE: I've never used CORBA but I have done plenty of MS (D)COM and  
Mozilla XPCOM, so maybe the following is due to mis-interpretation of your  
statement]

Firstly, Multi OS Threads =/= (SMP) Parallelism. There is a big difference  
between apparent concurrency (what your code looks like) and true  
concurrency (what the machine is doing.) This is largely what the SMP  
advocacy is about. After you've got your code running on separate OS  
threads in C++/Java/etc, the next step -- ensuring the threads can  
*actually* do significant work in parallel on SMP -- is *usually*  
non-trivial. What Herlihy and hardware people are saying is that a lot of  
programmers are not aware that this next step is non-trivial or the  
subtitles involved in getting it right and their research is about making  
that next step easier.

Secondly, the advantage I was describing here with Erlang is the ability  
to take some sequential chunk of code, like using the previous example of  
calculating a 300 Pythagorean triples, and then parallelise it (in code)  
by calculating each triple on a different process, then letting Erlang  
figure out how to actually run it in parallel on SMP. And the fact that  
when doing so, the code hardly changes. This is powerful. I haven't found  
another environment that offers me that as cleanly as Erlang.

In contrast, from my experience, converting ST code to MT in C++ normally  
involves a lot of re-writing and careful planning. Compared to Erlang,  
it's harder in many languages to look at a piece of code and say: "let me  
modify this to do each little bit of the work on separate threads then  
combine the result." You can attempt to do things concurrently in Erlang  
that you probably wouldn't attempt in C++ therefore greatly increasing the  
opportunities of parallelising (I think it's partly to do with Erlang's  
functional nature, partly the quantity and speed at which processes can be  
created, and partly to do with share-nothing concurrency.) And it's even  
harder in C++ to say: "now let me try and get better use of my cores on  
SMP," IMO, Erlang is much better at that.

> We also had a Thread class, so when something had to run in the
> background, the code was put in a separate class that inherited from
> this Thread class and we just had to call it's start function. This is
> not unlike what I had to do in Erlang when I write a new gen_server...
>

In your thread class, what would you do when you wanted the objects to  
interact the way gen_servers interact?

The *traditional* approach to this is shared state and inevitably thread  
synchronisation (you don't have to do this, but sharing state being the  
point of using threads rather than processes, it's the typical way.) This  
is where things get wonky with OS threads and where Erlang processes are  
very different.

Having no shared state for your gen_server means you're *not likely* to  
have to do much to get them to do a good chunk of their work in true  
parallel on an SMP machine (the VM will take care of where things are  
scheduled and any locking that needs to be done if any -- it's none of  
your business). Many OS threads sharing state makes taking advantage of  
multiple cores significantly harder -- things you probably haven't thought  
about become your business. You're likely to have to re-write your code  
replacing standard data structures with concurrent versions so that you  
don't have to lock them and some other adaptations to get things to  
interleave better on SMP. Erlang doesn't place such heavy burdens on you.

> In my experience parallelism does not differentiate Erlang from other
> languages.

That's interesting... my experience is the very opposite, at least in  
terms of "common mindsets". A lot of the paradigms and mindsets popular in  
other languages (e.g. threads accessing the same data structures with  
mutexes/rwlocks) don't lend themselves to parallelism. As Herlihy says, if  
these mindsets don't change then programmers who think in these terms  
won't be able to take advantage of increasing parallelism and *might* even  
suffer from the decreasing sequential clock speeds (though there's  
excessive panic about that last bit IMO).

In contrast, the mindsets popular in Erlang lend themselves nicely to  
parallelism (like share nothing and message-passing.) This is probably  
because it's a concurrent language. Concurrency is a first-class concept  
in Erlang. This is a HUGE differentiation for me. I always found working  
with threads in C/C++ to be contrived. It felt like a tacked-on  
after-thought...

http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html

Concurrency and parallelism is the *reason* I chose to learn Erlang. I was  
working on version 3 of a distributed lock manager and a MT Server then  
one day thought: "No, no, no. This just won't do. I'm too old for  
maintaining this insanity. My brain can't operate at that clock-rate  
anymore. There must be a better way."

Everything else was secondary. For me, the hot-code swapping, tracing, and  
other goodies you describe below were more of a pleasant surprise. I was  
attracted precisely to the differentiated concurrency and parallelism  
Erlang provides. I find it interesting that also coming from MT C++, you  
were not. Maybe there's more to CORBA than I've always thought :)

- Edmond -

> At first glance the message passing seems to be radically
> different to function calling, but I very very very rarely use the !
> operator, 99.99% of the cases it is hidden behind a gen_server or
> gen_fsm:call.
>
> What makes Erlang different from other languages is its VM. Hot code
> loading makes compile&test cycles blazingly fast - you don't even have
> to restart the application to test the changes! Not to mention that
> the live system can be patched (useful for the many 9s reliability). I
> think the real productivity gains from Erlang come from this fact, it
> doesn't have to do anything with the language.
>
> The ability to connect to live systems and poke around their internals
> helps debugging greatly. I've just spent half an hour investigating a
> deadlock situation (which turned out to be not a deadlock after all,
> just a slow TCP stack) using erlang:process_info, sys:get_status and
> friends to get the state of the system. It is much harder to do on a
> C++ software with e.g. gdb (especially when there's no gdb at the live
> system for security reasons). I don't know the scriptability of gdb,
> but in the Erlang shell you can write - well, Erlang programs, which
> is dead useful if you need to find 1 process out of 100s.
>
> ________________________________________________________________
> 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/