Comparison of Erlang Runtime System and Java Virtual Machine [pdf] • Hacker News Board

Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]

#11

Post by haglin » Fri, Jun 29, 2018, 11:14 PM UTC

It may be worth mentioning that project Loom [1][2] aims to add continuations and lightweight threading to Java. It is lead by Ron Pressler, the author of the Quasar library mentioned in the paper.

Also, JDK 11 (Hotspot) comes with a new concurrent non-generational garbage collector (ZGC) [3] that has an average pause time of 1 ms [4]. It is still an experimental feature, but that will most likely change over time.

[1] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.htm...

[2] http://openjdk.java.net/projects/loom/

[3] http://openjdk.java.net/jeps/333

[4] https://youtu.be/tShc0dyFtgw?t=4m58s

Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]

#12

Post by hsienmaneja » Sat, Jun 30, 2018, 1:58 AM UTC

Isn’t beam still slow for computations? I envisioned doing something with NIF’s, rustler and rust to break out anything computationally intensive.

Perhaps jvm is still a better purpose tool due to this.

Re: Comparison of Erlang Runtime System and Java Virtual Machine [pdf]

#13

Post by pjmlp » Sat, Jun 30, 2018, 1:22 PM UTC

Const-me wrote: post #7

dgllghr wrote: post #3

I never used a JVM language before the JIT compiler, so I have no personal experience with the speedup it introduced. But if Lua (and LuaJIT) are any indication, I am super excited for BEAMJIT. For BEAMJIT, I can imagine that the same work will take a different number of reductions before and after the JIT compiler has modified the code. Are there going to be any scheduling issues that will arise because of these red…

> I never used a JVM language before the JIT compiler, so I have no personal experience with the speedup it introduced Speedup in runtime, slowdown on startup. Early versions of Android (before 2.2 i.e. before 2010) used Dalvik JVM that interpreted the byte code. BTW, apparently google still can’t decide what’s the best way. After couple of years, in 2013-14, Google threw away the JIT and introduced another JVM, with…

The AOT compiler introduced with ART wasn't a clever decision.

When Microsoft introduced AOT compilation from Singularity into Windows 8, the compilation was done at the store, with dynamic linking done on-device.

Windows 10 UWP brought full static compilation on the store via .NET Native.

Google instead decided to do AOT compilation on the devices, which meant users had to wait several minutes, or even hours after major updates took place.

So with 7.0 they backtracked, using a quick interpreter written in Assembly, followed with a JIT doing PGO, which then took the overall information to feed into the AOT compiler, only called when the device is resting.

Updates trigger the process from the beginning.

Now with P, they will be sending PGO metada back to the store and share it between devices at installation time.

Yet, WP devices with AOT compilation at the store always felt faster as comparable Android class models.