Is Erlang a Holy Grail for the multi-core/parallel developer? Doug Eadline begins to build his case.
This week I am going to climb back on my parallel programming soap box and make a proclamation.
If you recall, I had started a discussion on
declarative programming methods. Compared to “procedural” or imperative programming (C, Fortran, Perl, etc.), the declarative approach focuses more on the “what” instead of the “how.” HTML is good example of this idea. When you create HTML, you telling the browser “what” to you want on the screen, the how is up to the browser. Because I have not told your computer how to render the information you can choose to view it using any number of browsers including a text based browser like lynx or elinks.
When one writes an procedural program (C, Fortran, Perl, etc.) you are “closer to the hardware” and farther away from your problem. When you add MPI, OpenMPI, or Pthreads you have moved closer to the hardware and further away from the problem at hand. The programmer has more to manage which also means more opportunities for bugs, but that is another issue.
These additional parallel responsibilities are why procedural parallel computing is harder than sequential computing. It is why machine code is harder than a high level language. And, finally, it is why we are facing a bit of a crises in the age of multi-core.
In my previous column, I mentioned the
X = X + 1 or multiple assignment issue. Procedural languages allow multiple assignment and thus create “state” as the program runs. Managing shared state across multiple processors (either multi-core or cluster) is what makes parallel programming difficult to write and debug (and, it also cannot guarantee portability and efficiency in your code). Declarative languages, on the other hand, only allow single assignment and thus do not create “state” as the program runs. Single assignment does not allow a procedural loop structure, but can be handled with optimized recursion.
In the world of declarative languages there are three families. The first is logic based languages like Prolog. A second family is constraint based languages like OZ. The third and most active area is functional languages like Erlang, Haskell, and even Lisp. There are others to be sure.
One of my goals has been to try and find a workable functional language for parallel computing. Note that I do not necessarily state HPC parallel computing. Instead, I have been searching for a language in which I want to invest my time. My goal is to get a good understanding of the functional paradigm and how it can help move me away form the multi-core or cluster and closer to my application. I could continue to use some of the procedural methods, but I long for the elegance and flexibility of a well written declarative code.
As I mentioned, I consider learning any new language a big investment and I have anguished over the right choice. I also did not want to continue complaining about parallel programming issues as the multi-cores are here and I want to jump in the pond. So without any further discussion, my choice is Erlang. Gulp.
There are many of you out there that assume I have lost the last remaining marble rolling around in my empty head. Perhaps, but hear me out then decide. I want to go on record with the following opening statement: I do not think there is one best programing language for every problem or domain. I do not even know if Erlang is the best choice for multi-core, let alone cluster computing. As for HPC (i.e. number crunching) I don’t have high expectations. I do believe Erlang represents a clean high level way to code for multi-core and is worth exploring. I also chose Erlang for a number of other non-technical success factors that I consider as important as the technical implementation.
- Open Source: Erlang is freely available under the EPL license. EPL is a derivative work of the Mozilla Public License (MPL). It contains terms which differ from MPL, mainly in terms of jurisdiction. As a battle scarred HPC geek, if I am going to invest my time, I am not going to go down a proprietary path. I have seen too many discarded “secret good ideas” along progress road.
- Community: Erlang has community and history. Development started in the early 1990′s and continues today. There is an active community and company that supports development (Ericsson). There is a large contingent of Erlang users.
- Industrial Strength: Erlang is used in a production environment and is not a research project. It is an essential part of Ericsson’s telecommunications systems and has found use in many other companies.
- Paid Support: There is professional support available for Erlang.
- Open Support: There is plenty of open support in the form of a book, tutorials, on-line papers, code examples, and even some impressive projects.
Astute readers will notice I did not include any of the Erlang’s cool features, like a simple concurrency model based on Erlang processes (not OS processes), fault tolerance, hot code fixes, simple communication syntax, high level functional language, built in database, etc. Of particular note is Erlang’s concurrency model. It is based on creating and managing processes which communicate using message passing instead of shared variables (i.e. shared state), There is no need for locks and other such state management mechanisms. Processes can live on a single core, multi-core, or spread across a cluster.
Over the next several months, I’ll be bringing more Erlang goodness by way of example. I’m still a novice, so in the spirit of utterly useless blogging, you will get the real “hands on” version and be able able to avoid all those well thought out tutorials and books. I have made my stand and it is Erlang (for now). Of course, you can expect me to keep a keen eye on other HPC/multi-core/programming issues. The whole GPU thing fascinates me as does the programming methods used for these single node PCU (Parallel Computing Units). And, as soon as that latest and greatest programming breakthrough hits, I’m on that bandwagon. Well, that is if it can get past my success factor list.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62