[erlang-questions] Re: Erjang

[Jayson Vantuyl]

The deoptimization thing is definitely interesting to watch.  Here's a benchmark done by the JRuby guys (disclosure: I'm a shareholder and employee at their place of employment).

http://www.engineyard.com/blog/2009/j-is-for-jvm-why-the-j-in-jruby/

What I find fascinating is the little blip at iteration #6 where hotspot tries something that doesn't work, then reverses it.

Personally, I believe that functional languages are different enough that there are intelligent optimizations that are suitable for them at a high-level that are not suitable for optimization at the byte-code level (or suitable for other languages).  That said, I don't think it matters because:

1.  Those implementations are at such a high level that they would end up in the compiler anyway.
2.  Most of them involve matching patterns in a way that is computationally intractable (until I get my Quantum Compiler!).
3.  Nobody cares enough to put the resources into it that the JVM is getting.

As such, I think a JVM-targetted Erlang would be very nice, if the JVM can get as good at lightweight processes and scheduling as Erlang itself is.  One of the most striking things about Erlang for me was that almost all performance metrics are measured in microseconds--and anything larger would be inadequate.  Most other languages (barring assembly or kernel-level C) end up measuring in milliseconds--and then they do it by repeating the test 1000 times and dividing.  With Erlang it's possible to get microsecond measurements from a single run and feel pretty good about it.  Until I see this out of the JVM, I think that the Erlang VM is the way to go.

Even then, I don't see Ericsson embracing the JVM until you can say "Embedded Java" without eliciting laughter.  I suspect the horror of Java on phones has been bad enough that it will be a long time until that happens.

On Dec 8, 2009, at 9:58 AM, Tony Arcieri wrote:

> On Tue, Dec 8, 2009 at 10:47 AM, Johann Höchtl <johann.hoechtl@REDACTED>wrote:
> 
>> Given the trmendous work which has been done on Luajit2 and the vast
>> improvements speedwise, I wonder I sthg. a least mildly comparabel
>> could be done to the Beam VM. Is some work going on for HIPE or the VM
>> in general?
>> 
> 
> HiPE is nowhere close to the JVM's HotSpot in terms of the types of
> optimizations in can perform.
> 
> Among other things, the JVM's HotSpot can deoptimize.  HiPE cannot, and for
> this reason HiPE cannot inline across modules, as a code change would
> require the inliner to deoptimize whenever code change occurs.
> Deoptimization also allows HotSpot to try aggressive optimizations which may
> actually lead to performance regressions or no noticeable improvements, in
> which case it can deoptimize and try again.
> 
> -- 
> Tony Arcieri
> Medioh! A Kudelski Brand