[erlang-questions] Idle question
Richard O'Keefe
(the BlueGene machine at the University of Canterbury,
see http://www.bluefern.canterbury.ac.nz/
). What would you use it for? What science or
technology would it advance?
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Vik Olliver
> Suppose Erlang were available on BlueFern
> (the BlueGene machine at the University of Canterbury,
> see http://www.bluefern.canterbury.ac.nz/
> ). What would you use it for? What science or
> technology would it advance?
Protein & DNA packing - I guess that's what is was for, right? But I'd
aim for creating nanomachine components rather than purely biological
structures.
Once they're designed, they'll need simulating too. Nanoscale RepRap anyone?
Vik :v)
Richard O'Keefe
On Nov 24, 2009, at 11:13 AM, Vik Olliver wrote:
> On 24/11/09 Richard O'Keefe wrote:
>> Suppose Erlang were available on BlueFern
>> (the BlueGene machine at the University of Canterbury,
>> see http://www.bluefern.canterbury.ac.nz/
>> ). What would you use it for? What science or
>> technology would it advance?
>
> Protein & DNA packing - I guess that's what is was for, right? But I'd
> aim for creating nanomachine components rather than purely biological
> structures.
The page http://www.bluefern.canterbury.ac.nz/projects/index.shtml
shows what BlueFern is currently being used for. I note two
nanotechnology projects there already. (But no protein or DNA
packing.)
What would make >>> Erlang <<< a good language for Protein and DNA
packing or computational nanotechnology or birthweight prediction
&c rather than Fortran or C++ with ESSL and MPI or Stata or even R?
It struck me that here's a large machine on the same island as me,
160 cores for the p575 cluster, 4096 cores for the BlueGene, and
to be perfectly frank, most of the projects look like things where
Fortran 95 would be the programming language of choice, or possibly
Ada. There's one project where the main need wasn't so much the
number of cores as the amount of main memory.
One should not expect Erlang to do _everything_, but this was making
me reflect on the difference between highly *concurrent* computing
and high *performance* computing.
Vik Olliver
> What would make >>> Erlang <<< a good language for Protein and DNA
> packing or computational nanotechnology or birthweight prediction
> &c rather than Fortran or C++ with ESSL and MPI or Stata or even R?
I've not done it you understand, but it seems to me like Erlang would be
good for calculating the component part interactions for large molecules.
Vik :v)
Michael Truog
Joe Armstrong
> Suppose Erlang were available on BlueFern
> (the BlueGene machine at the University of Canterbury,
> see http://www.bluefern.canterbury.ac.nz/
> ). What would you use it for? What science or
> technology would it advance?
I'd write a general purpose management layer (middleware) for
distributing computations over the
cluster. If you want to do heavy numerical computations, you'll do
them in an imperative language.
I'd use Erlang as the glue for glueing togther components and for
monitoring the system as a whole.
I'd make an infrastructure that is language neutral, but based on
communicating components
and let Erlang manage the components - start them and stop them, move
them, give them resources etc.
I would allow the components to compete and evolve so the best
component for the job could be found.
I'd use something like UBF to constrain the messaging between components.
/Joe
Olivier BOUDEVILLE
We are currently making use of Erlang for some kind of distributed
discrete time-stepped simulations, and we were actually considering the
port of an Erlang VM on a Bluegene/P for 2010.
We are less in need for floating-point number-crunching abilities than for
a massive parallel execution that could take advantage of the vast amount
of total RAM that the Bluegene provides: for the large-scale simulations
we aim, with the Bluegene we might get an edge over classical clusters (if
still able to rely on a low-latency network).
I believe that Erlang is very relevant to develop (somewhat complex)
distributed algorithms, involving message reordering and massive
concurrency. This is true for time-stepped algorithms, and I guess still
truer for event-driven conservative or optimistic simulations, where
deadlock detection/avoidance and distributed rollback mechanisms would be
surely easier to develop in Erlang than, say, C or C++.
So there would be definitively an interest in such a port, and the outlook
of any joint effort/shared needs could help me promote the porting effort
internally.
On the technical side, the port of the Erlang VM to a Bluegene node could
be less complex than expected at first glance: unless I am mistaken, the
PowerPC architecture is supported by Erlang, a minimal GNU/Linux
environment should be available on each node, and the lack of multithread
support should not be a problem (thanks to green threads). The major issue
would probably be the network, knowing that by default not TCP/IP stack is
available on the Bluegene, as I understand. Options could be to switch to
a Bluegene-native carrier, or to make use of MPI for
internode-communications, or maybe to rely on any experimental TCP/IP
support that may already exist.
Finally, according to http://www.ece.iastate.edu/~crb002/cnr.html Ruby was
already ported successfully to the Bluegene; is there anything that Ruby
can do and that Erlang cannot?
Best regards,
Olivier Boudeville.
---------------------------
Olivier Boudeville
EDF R&D : 1, avenue du Général de Gaulle, 92140 Clamart, France
Département SINETICS, groupe ASICS (I2A), bureau B-226
Office : +33 1 47 65 59 58 / Mobile : +33 6 16 83 37 22 / Fax : +33 1 47
65 27 13
o...@cs.otago.ac.nz
Envoyé par : erlang-q...@erlang.org
23/11/2009 23:02
Objet
[erlang-questions] Idle question
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________
This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
French, Mike
Idle Thoughts of an Idle Fellow (and Erlang novice) ....
> -----Original Message-----
> > On 24/11/09 Richard O'Keefe wrote:
> >> Suppose Erlang were available on BlueFern
> >> (the BlueGene machine at the University of Canterbury,
> >> see http://www.bluefern.canterbury.ac.nz/ ).
> >> What would you use it for?
> >> What science or technology would it advance?
.....
Erlang should have a good headstart for parallel processing
because of the usual suspects: share nothing process isolation,
message passing and asynchronicity (as Jung would have called it,
had he been an Erlang hacker - Jungerl ?)
But Erlang is also bad for HPC because of:
- no dense numerical data structures with pointer arithmetic:
vectors, matrices, multidimensional arrays
- memory overhead for lists, hence also for strings,
so no dense character data structure with pointer arithmetic
(implement string processing over binaries ?!)
- no mutable in-place (zero-copy) data structures
even when isolated in a single process thread of control
- message copy overhead even when local (except large binaries)
- no control over process locality ?
So I conclude that dense numerical computation in Erlang
will always be slower than C, C++, Fortran, ... Fortress ?
I also conclude that if Erlang is just used for coordination of
compute processes implemented in other languages, then extra copies
required by Erlang message passing will always be slower than just
using MPI directly between the compute processes ?
So what is Erlang good for in the HPC arena ?
A suggestion would be to avoid problems that need tight computational
inner loops over multi-dimensional arrays, and look for problems requiring:
- complex decisions (conditionals in your loops)
- across uncorrelated pathways (no advantage for dense structures)
- over arbitrary graphs of data (communicating processes are graphs)
A place to start would be to look at the 13 Dwarfs (should be Dwarves!)
which are patterns of computation extracted from common HPC problems:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.pdf
Then follow the related architectural design process outlined here:
http://parlab.eecs.berkeley.edu/sites/all/parlab/files/Patterns-Keutzer.pdf
(best overall summary slide is 23/75)
and mark Erlang on its strengths and weaknesses
as you make decisions about HPC design patterns.
When you come across ... task decomposition, arbitrary task graph,
event-based, pipe and filter, graph algorithms, dynamic programming,
map-reduce, graph traversal, finite state machines, divide & conquer,
backtrack branch & bound, task parallelism, discrete event, pipeline,
master/worker, CSP, message passing .... then Erlang has potential.
Notice how Erlang is better 'above the line' in the Productivity Layer
rather than 'below the line' in the Efficiency Layer.
Of course, it would also be fun to speculate how Erlang could be
improved with dense multidimensional arrays, zero copy local messages,
mutation BIFs (like HiPE hacks), SIMD map and fold, etc.
... but maybe it wouldn't be Erlang any more.
Regards,
Mike
Thales UK Ltd (Wells) DISCLAIMER: The information contained in this e-mail
is confidential. It may also be legally privileged. It is intended only for
the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information contained in
this e-mail. Such unauthorised use may be unlawful. We may monitor all
e-mail communications through our networks. If you have received this e-mail
in error, please inform us immediately on sender's telephone number above
and delete it and all copies from your system. We accept no responsibility
for changes to any e-mail which occur after it has been sent. Attachments
to this e-mail may contain software viruses which could damage your system.
We therefore recommend you virus-check all attachments before opening.
Thales UK Ltd. Registered Office: 2 Dashwood Lang Road, The Bourne Business
Park, Addlestone, Weybridge, Surrey KT15 2NX Registered in England No.
868273