Getting locks and sharing: was RE: Getting concurrency

ke.han ke.han@REDACTED
Wed Jun 15 17:24:20 CEST 2005


I did about a year of research on alternative languages before settling 
in on erlang for my current project.  For this particular project, 
single cpu nodes works just fine.  If I want more cpus, I can add more 
nodes with no need for replication of data/mnesia between the nodes. 
However, for many projects I've done in the past, I would have to 
specially architect the erlang solution to use distribution to make use 
of more CPU power.  For most people investigating use of erlang, this 
architecture deviation to accommodate erlang will be too much 
considering they're already putting themselves at risk by choosing a 
niche language.

I other words, the Bray blog post that instigated this thread says:
	"if I understand Erlang correctly, it abjures the use of global data, 
which simplifies the problems immensely. I’ve done a lot of concurrent 
work, and my biggest programming wins have been all about a bunch of 
threads running around a big shared data structure."

With a multi-CPU single node erlang, you get the best of both worlds: 
you get the clean erlang programming model _and_ enabling multiple-CPUs 
access to the same big "shared" data.  The only downside from doing this 
the "Bray way" is you have to buy more RAM for your server due to the 
erlang "process encapsulation" approach to accessing data.

So, can we hear from experts that had hands-on experience with the 
mult-CPU erlang project??  What needs to be done to resurrect such a 
project?

thanks, ke han


Vance Shipley wrote:
> On Wed, Jun 15, 2005 at 08:18:36AM -0500, James Hague wrote:
> }  
> }  I agree.  With AMD and Intel both pushing multiple cores on one chip,
> }  this looks like the time to resurrect the multi-CPU Erlang research. 
> }  I fully expect that *all* desktops will have multiple CPUs within the
> 
> I'm convinced that the next ten years will see huge advances in 
> parallelism.  Sun's Niagra 32 way chip will ship soon.  IBM et. al.
> have their cell processor.  The low hanging fruit in performance
> gains is in adding parallel execution paths.  I'm not talking dual
> CPU here but dozens or hundreds.  Today's software industry isn't
> ready for that. 
> 
> It is inevitable that there will be a ground swell of interest in 
> concurrency oriented programming languages.  On the one hand I think
> Erlang stands a chance of gaining serious mind share.  On the other
> hand the single threaded emulator will be seen as making the whole
> point moot.
> 
> If Erlang doesn't deliver the goods new COPL language(s) will arise
> to solve the problem.  That may well be a good thing but it would 
> be a shame to see Erlang be passed by entirely.
> 
> Maybe what we need in the short term is a wrapper application which
> takes care of creating nodes, binding them to virtual processors and
> generally making distribution transparent.
> 
> 	-Vance
> 




More information about the erlang-questions mailing list