Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ds.cs.ut.ee

Post reply on HN
Print view View original

11–20 of 60 posts

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

#11

Post by phamilton »

pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

Regarding the JVM as a strict superset, there are a few features I'm not sure fit that model.

Isolated garbage collection. Limiting GC to a single process/thread. It's my understanding that this is only possible with individual heaps, prohibiting shared memory. I see this as a polarizing tradeoff (with pros and cons). I don't think the JVM does this, and therefore isn't a superset.

Preemptive scheduling and soft real time. It's my understanding that Quasar bridges this gap by looking for natural points in execution to insert a pause/continue (oversimplified I'm sure). What are the guarantees? Erlang provides fairly strong guarantees about fair scheduling, making it very suitable for soft real-time systems. Would Quasar, for instance, pause a tight for loop if execution was running long? Or does it only pause on blocking operations like IO?

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

#12

Post by ams6110 »

leothekim wrote: post #8
ScootyPuff2000 wrote: post #5

This is a terrible paper. It barely made a point, and is riddled with distracting misspellings and grammatical errors.

It reads like it was written by an undergraduate for independent study credit, or as a lit review for a future non-doctoral thesis. Certainly no result here, just a survey.

To be fair, neither the title nor the abstract suggest that a result will be presented.

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

#13

Post by rubyrescue »

vezzy-fnord wrote: post #6
pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

whereas in Erlang (IIRC) ETS cause some issues with GC There isn't any at all for ETS: Note that there is no automatic garbage collection for tables. Even if there are no references to a table from any process, it will not automatically be destroyed unless the owner process terminates. It can be destroyed explicitly by using delete/1. The default owner is the process that created the table. Table ownership can be tra…

I've built dozens of Erlang apps and used ETS in every one. I've used Mnesia once, and it was not a pleasant experience. Most Erlang dev teams use ETS directly. It's possible to use Mnesia successfully but I see it far less often than ETS these days.

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

#14

Post by mwcampbell »

hendzen wrote: post #3

The content is quite interesting, but this paper could use some serious editing. There are typos throughout, and the tone is overly colloquial for an academic context. The paper could also use an evaluation section - e.g. implementing a solution to a well known problem like the Dining Philosophers in both languages and comparing both the code and runtime characteristics.

What's wrong with colloquial style? Perhaps the usual stuffy style of academic writing is a trapping to avoid, not something to imitate and perpetuate.

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

#15

Post by jlouis »

vezzy-fnord wrote: post #6
pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

whereas in Erlang (IIRC) ETS cause some issues with GC There isn't any at all for ETS: Note that there is no automatic garbage collection for tables. Even if there are no references to a table from any process, it will not automatically be destroyed unless the owner process terminates. It can be destroyed explicitly by using delete/1. The default owner is the process that created the table. Table ownership can be tra…

You will be using ETS directly way more often than you will be using Mnesia in many Erlang systems, so I wouldn't really say you'll use it rarely.

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

#16

Post by jlouis »

jfaucett wrote: post #9

This was an decent comparison / contrast. It did make me wonder how they're coming along with the BEAM jit these days, I found this from a while back: http://www.erlang-factory.com/euc2014/frej-drejhammar It also reminded me how much I wish there was an actual specification for BEAM, finding out the details of the how the bytecodes work is an arduous task compared to the JVM where everything is explicitly stated. IMH…

Frej's JIT is going strong! Maybe it will be present experimentally in the next Erlang release. But such things may change over time.

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

#17

Post by jlouis »

pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

Take the fastest webserver written for Java and for Erlang. Now run static requests around 2048 bytes, 10k connections, 3 req/s on each connection for 5 minutes. Measure the 99.9th percentile latency.

Erlang wins by a large margin because the JVM has to garbage collect and block everyone while doing so. This is not desirable in a soft-realtime system.

I'd definitely not order one as the strict superset of the other.

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

#18

Post by pjmlp »

jlouis wrote: post #17
pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

Take the fastest webserver written for Java and for Erlang. Now run static requests around 2048 bytes, 10k connections, 3 req/s on each connection for 5 minutes. Measure the 99.9th percentile latency. Erlang wins by a large margin because the JVM has to garbage collect and block everyone while doing so. This is not desirable in a soft-realtime system. I'd definitely not order one as the strict superset of the other.

Try that with Zing. The beauty of the JVM, is that by being a specification, there are lots of implementations to choose from.

Yet people seem to think OpenJDK is the only one.

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

#19

Post by pjmlp »

digitalzombie wrote: post #10
pron wrote: post #4

The report mentions Quasar (I'm its main author) and simply says, "instrumentation has many challenges that add complexity to the program instead of removing it." -- without mentioning why. I believe this is false. Quasar removes just as much complexity as Erlang does (Erlang's enforcement of immutability is orthogonal; indeed, if you use Quasar with Clojure you get that, too), but it is true that the instrumentation…

> I believe that the JVM is a strict superset of any Erlang VM. I don't get how JVM is a strict superset of Erlang VM when it doesn't have pre-emption. If BEAM set have preemptive scheduler as an element and JVM, IIRC, does not have such feature, then JVM is not a super set let alone a strict super set.

Any JVM implementation is free to choose how to do it.

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

#20

Post by dxhdr »

pjmlp wrote: post #18
jlouis wrote: post #17

Earlier quoted context omitted.

Take the fastest webserver written for Java and for Erlang. Now run static requests around 2048 bytes, 10k connections, 3 req/s on each connection for 5 minutes. Measure the 99.9th percentile latency. Erlang wins by a large margin because the JVM has to garbage collect and block everyone while doing so. This is not desirable in a soft-realtime system. I'd definitely not order one as the strict superset of the other.

Try that with Zing. The beauty of the JVM, is that by being a specification, there are lots of implementations to choose from. Yet people seem to think OpenJDK is the only one.

Sure I'll just fork over $8,000 and get started... The beauty of BEAM is that I don't have to know or worry about projects like Zing, BEAM "just works." (Another mark against Zing just because you brought it up -- where's the source code?)
Post reply on HN