[erlang-questions] Ideas for a new Erlang

Sven-Olof Nystr|m svenolof@REDACTED
Wed Jun 25 17:27:23 CEST 2008


 > From: "Christian S" <chsu79@REDACTED>
 > > I have written down some thoughts and ideas on the future development
 > > of Erlang.
 > 
 > This is fresh air compared to the constant complaints that only
 > contain description of what people do not want (without the
 > suggested replacements).

Thanks.

 >
 > >  - an alternative to Erlang's selective receive
 > 
 > I have not been following the discussions around problems related
 > to very long message queues, why people get into the situation and
 > such. But to me the problem of slow selective receive on large
 > mailboxes suggests not to get into that situation to begin with,
 > not to optimize so it doesn't hurt as much. :)

True. But selective receive seems almost to be designed to create that
problem.

 > A single process can only process the mailbox
 > sequentially. Ideally, if you got a bottleneck there, throw more
 > processes at it (i.e. cpu cores), make it scale!

:-) ?

Searching the mailbox in parallel? Note that we still need to
determine which message is the first in the mailbox that
matches. Also, if we can do without selective receive, this is a
problem that does not need to be solved.


 > Another reflection is what the implementation of gen_server:call
 > using channels would look like. The current one-time-monitor used
 > now looks very similar to a one-time channel that is used for the
 > synchronous reply. Almost as if one would want a monitor that is
 > "messageable/receiveable".

As far as I can see, there would not be any problems implementing
gen_server using channels. Of course, this is an example that is worth
some attention.


 > When it comes to making changes to the Erlang syntax, I think those creating
 > automatic refactoring tools should review it and steer in a way that make
 > their job easier, allowing us all to get better automatic refactoring tools.

Yes, I forgot to mention that. Tools that work with Erlang source
certainly become harder to write when the language is complex. 

 > The worst(?) that can happen is that we get a lisp syntax. :)

Coming up with a syntax that is even more confusing to newbies than
the current one? :-)


 > > > - a mini-language to allow the efficent implementation of
 > > >   low-level algorithms

 > > This is very interesting. I do not understand it fully.  

Perhaps because it is not fully defined :-)

 > But it is very interesting.  You had me at compiling down to the
 > Cell processor SPEs.

See the white paper for more details.


 > With a language like this, then common-lisp like macros are even more
 > interesting. My experience with performance at SIMD parallelism is that
 > only 20% is being able to perform the SIMD operations, and the remaining
 > 80% work is in managing memory accesses so data already in cache lines
 > are efficiently used while it is still there.
 >
 > Applying approaches such as
 > http://en.wikipedia.org/wiki/Loop_nest_optimization aid here, and
 > then it is nice to parameterize various block-sizes for the
 > specific model and generation of the cpu used. When sqeezing mips
 > out of a cpu everything is game.  C++ programmers typically use
 > their templates to parameterize this.

Precisely the sort of thing I had in mind.

 > I can imagine code wanting to generate and compile these small
 > number-crunchers at runtime for the conditions of the specific task
 > at hand.

Certainly a workable approach. Of course, a compiler could produce
different versions of a routine depending on the size of input and
other conditions, so this does not need to be visible to the
programmer. OTOH, doing the same trade-offs in an application (and
recompile compute-intensive code) could also work.


Sven-Olof



More information about the erlang-questions mailing list