[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
> 2011/1/7, Edmond Begumisa <>:
>> 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
>> 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
>> 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
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
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
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
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
> 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:
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions