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

41–50 of 60 posts

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

#41

Post by dschiptsov »

pron wrote: post #23
phamilton wrote: post #11

Earlier quoted context omitted.

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…

> It's my understanding that this is only possible with individual heaps, prohibiting shared memory. Yes, but the only advantage is a simpler GC algorithm. HotSpot's GCs are so advanced (let alone HotSpot descendents like Zing) that they give you similar behavior even without isolation, and they include collection of shared data structures, too. > Would Quasar, for instance, pause a tight for loop if execution was ru…

You cannot give "similar behavior" of lock-free, share-nothing data-structures with locking-concurrent ones.

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

#42

Post by foopants »

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.

One reason we like to use erlang is it weeds out stupid people. People who say things like up the JVM is a 'strict superset' of the BEAM.

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

#43

Post by vtuulos »

white-flame wrote: post #32

I was working with Erlang for about 2 years in a multi-language environment, and we based our networking messaging infrastructure on top of the Erlang protocol. It's still there, but we're migrating from it. One major thing that turned me off of the language for our particular project was that there was no way to have a large read-only data structure in RAM and sic a bunch of parallel threads to analyze or search it.…

DiscoDB does exactly what you described: It memory maps a large read-only data structure in RAM. It has an Erlang binding based on NIFs.

http://discodb.readthedocs.org/en/latest/

https://github.com/discoproject/discodb

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

#44

Post by abalone »

polack wrote: post #37
abalone wrote: post #27

Earlier quoted context omitted.

The TechEmpower Web Framework Benchmarks score Java 5X faster than Erlang at a simple JSON test. (There's an even simpler plaintext test but no one was implemented it for Erlang.) However it's worth nothing the test only runs for 15 seconds. It might be an interesting addition to run it for 10 minutes and measure 99.9% latency, as jlouis proposes, and prove one of you correct. https://www.techempower.com/benchmarks/#…

It also shows that Erlang is 15X faster than Java (depending on what framework you compare) and that the Java Netty/JSON test has 8X more code than the Erlang Cowboy/JSON counterpart ;)

>It also shows that Erlang is 15X faster than Java

That's nonsense. jlouis challenged us to "Take the fastest webserver written for Java and for Erlang", not the slowest ones. And that's exactly what the TechEmpower benchmarks do and they give Java a ~500% advantage.

As for codesize, if you don't like netty then the very next ranked result is servlet3-cass which delivers nearly the same performance -- again, approx 5X faster than the fastest Erlang impl -- in just a few lines of code. Surely you were aware of this when you wrote that comment.

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

#45

Post by white-flame »

vtuulos wrote: post #43
white-flame wrote: post #32

I was working with Erlang for about 2 years in a multi-language environment, and we based our networking messaging infrastructure on top of the Erlang protocol. It's still there, but we're migrating from it. One major thing that turned me off of the language for our particular project was that there was no way to have a large read-only data structure in RAM and sic a bunch of parallel threads to analyze or search it.…

DiscoDB does exactly what you described: It memory maps a large read-only data structure in RAM. It has an Erlang binding based on NIFs. http://discodb.readthedocs.org/en/latest/ https://github.com/discoproject/discodb

That's not the type of interface you'd want to build algorithms on which are constantly and deeply traversing data object links, if any type of performance is required.

Same thing as with ETS or SQL.

Implementing traversal-heavy algorithms across a large in-RAM data network does not require external tools, and is not helped either in performance or simplicity by decoupling direct pointer-based linkages into hash keys, and speaking to external interfaces. At least not for the work we were doing.

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

#46

Post by pron »

dschiptsov wrote: post #41
pron wrote: post #23

Earlier quoted context omitted.

> It's my understanding that this is only possible with individual heaps, prohibiting shared memory. Yes, but the only advantage is a simpler GC algorithm. HotSpot's GCs are so advanced (let alone HotSpot descendents like Zing) that they give you similar behavior even without isolation, and they include collection of shared data structures, too. > Would Quasar, for instance, pause a tight for loop if execution was ru…

You cannot give "similar behavior" of lock-free, share-nothing data-structures with locking-concurrent ones.

The JDK has some of the best implementations of lock-free data structures anywhere, and they are actually all implemented in Java (the JVM exposes direct access to memory fences and CAS). You really never have to drop down to C unless you want to interface with some OS-specific code.

The JVM is simply much more general-purpose. Just like your machine and OS themselves can support Erlang, so can the JVM.

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

#47

Post by pron »

phamilton wrote: post #38
pron wrote: post #23

Earlier quoted context omitted.

> It's my understanding that this is only possible with individual heaps, prohibiting shared memory. Yes, but the only advantage is a simpler GC algorithm. HotSpot's GCs are so advanced (let alone HotSpot descendents like Zing) that they give you similar behavior even without isolation, and they include collection of shared data structures, too. > Would Quasar, for instance, pause a tight for loop if execution was ru…

I'm skeptical that Hotspots GC can provide the same behavior, but I'm not familiar enough to challenge that claim. My skepticism arises from most JVM benchmarks around latency (for example, a webserver) having a significant standard deviation, which I had always attributed to an overly broad GC. I have a chip on my shoulder about limited concurrency abstractions. I've been burned too many times by Akka and thread poo…

The Clojure bindings for Quasar are called Pulsar[1], and I believe that the guarantees made by Clojure are exactly what you're looking for.

[1]: https://github.com/puniverse/pulsar

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

#48

Post by poolik »

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…

Hi! I'm the author of the paper referenced by this post and let me start off by saying that you're right in that the paper didn't do justice to Quasar. I kindly apologies for this. I actually did want to revise that section before submitting, but as usual, the deadline came first and that section remained in my opinion one of the most "hand-wavy" ones.

Mostly the comment about "adding complexity", comes from my own biased experience of working with bytecode instrumentation. I work on the JRebel team @ZeroTurnaround and as you can imagine, we have to do quite a bit of instrumentation to get this nice reloading behaviour. Though as Murphy's law states, if something can go wrong it will and if something goes wrong after instrumentation then debugging it will not be a pleasant task. Which of course doesn't mean that it can't work nicely eventually, proven by our large number of happy customers.

Quasar's own documentation states that "If you forget to mark a method as suspendable ... you will encounter some strange errors. These will usually take the form of non-sensical ClassCastExceptions, NullPointerExceptions, or SuspendExecution being thrown". I think forgetting something is a very human thing to do and when you've got a large codebase then debugging such exceptions is what I meant by "adding complexity". But again this was only a speculation.

Regarding the other comment about shared mutable state, then of course it isn't necessarily required and I did write in the summary that "Java and the JVM provide enough tools to retrofit any concurrency model out there, but retrofitting anything won’t be the same as taking it into the initial design", which I do think still holds and I believe is one of the reasons why using libraries like Quasar won't be a trouble free experience, at least not until it's somewhat built into the JVM.

Though I won't even try to claim to know the ultimate truth and I'm always grateful to have someone correct me when I'm wrong. I appreciate your efforts in trying to make the JVM a better/more versatile platform with Quasar. I think that any such bold undertaking will only benefit the ecosystem in the long run.

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

#49

Post by pron »

poolik wrote: post #48
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…

Hi! I'm the author of the paper referenced by this post and let me start off by saying that you're right in that the paper didn't do justice to Quasar. I kindly apologies for this. I actually did want to revise that section before submitting, but as usual, the deadline came first and that section remained in my opinion one of the most "hand-wavy" ones. Mostly the comment about " adding complexity ", comes from my own…

Quasar's instrumentation is much less intrusive than JRebel's: no fields are added and no state changes tracked. There are only minor additions to the actual execution bytecode (again, no class-layout changes) that capture the stack. Those errors mentioned in the documentation (we should change that) are now automatically analyzed and tell you exactly where you've forgotten to annotate a method. Finally, with the changes in Java 9, instrumentation will become completely transparent, and require no manual annotation on the part of the user whatsoever.

> Java and the JVM provide enough tools to retrofit any concurrency model out there, but retrofitting anything won’t be the same as taking it into the initial design

The concurrency model requires no retrofitting. It is simply a strict superset of Erlang's. The computer and OS also support a full shared-memory concurrency model, yet it can be restricted -- not retrofitted -- to run languages like Erlang or Rust, with a more restricted model. Same goes for the JVM. It has a general-purpose shared heap, but any language may restrict its use. No retrofitting is required. Quasar doesn't impose any further restrictions (that's not its job -- simply to provide fibers), but a language like Clojure certainly does. Clojure is no less safer than Erlang. The implication is that an Erlang running on the JVM requires no C code to implement something like ETS, but the underlying JVM semantics are no more foreign to Erlang than the underlying machine semantics, and vice-versa: Erlang is no more foreign to the JVM than to the hardware. Erlang simply places restrictions on their use, and they both provide lower-level abstractions.

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

#50

Post by pron »

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.

Quasar does preemptive scheduling, and even used to have time-slice based preemption. The latter was taken out as it proved to provide no benefit whatsoever, because processes that benefit from time-slice preemption are better off using the kernel's scheduler anyway, and the JVM gives them that option. Erlang has to do it because it only exposes a single scheduler. That's is still a strict subset of the JVM's capabilities.
Post reply on HN