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

31–40 of 60 posts

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

#31

Post by Skinney »

jlouis wrote: post #16
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.

Do you have any links that gives recent information about the JIT? Would be interesting to read more.

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

#32

Post by white-flame »

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. It is hackable if you mash your data structure into a large byte binary, since large bins live on a shared heap, but it's a pain to deal with non-native representation for your data.

It's very obvious that Erlang is optimized for a particular usage model, and even when you're dealing with a number of functional parallel processes, it might still clash with what you're doing.

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

#33

Post by sargun »

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.…

I mean, you could always keep your large data structure in ETS?

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

#34

Post by white-flame »

sargun wrote: post #33
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.…

I mean, you could always keep your large data structure in ETS?

That's not very fast in comparison.

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

#35

Post by polack »

abalone wrote: post #29
jlouis wrote: post #26

Earlier quoted context omitted.

The TechEmpower Benchmarks measures the maximal number of requests per second you can churn through a server. They don't care for the number of connections, but simply pick the best result from trying different connection counts. Also, they don't really measure latency correct I think, because they make the mistake of "coordinated omission" (Look it up, Gil Tene, of Zing/Azul fame is its main discoverer). I was very…

I deleted my comment because I realize the benchmarks don't cover a 5 minute test. It's unproven whether the Java implementations need to in fact GC over that time. I'm skeptical though -- they probably reuse all their objects, and I think it would be interesting to prove that. Also, the benchmarks do in fact test all the way up to 16,384 simultaneous connections.[1] I bet if you published a test case that proves Jav…

> It's unproven whether the Java implementations need to in fact GC over that time. I'm skeptical though -- they probably reuse all their objects

Are you saying that it's common for java web-frameworks to automatically reuse objects and that they do not cause any GC?

> Also, the benchmarks do in fact test all the way up to 16,384 simultaneous connections.

Read jlouis comment once more. It's not that they don't try many connections at once, it's that they take the best result that they get. Big difference.

EDIT: Looking at the code for the Java Netty/JSON test shows that it does not reuse objects. The biggest takeaway from these tests is that it's hard to do performance testing...

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

#36

Post by mike_hearn »

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.

Why would you want your VM to implement time based pre-emption? That is the job of the kernel, which is very good at it.

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

#37

Post by polack »

abalone wrote: post #27
pron wrote: post #24

Earlier quoted context omitted.

> Erlang wins by a large margin because the JVM has to garbage collect and block everyone while doing so. Not even close (certainly not when using Quasar). Whether or not you have large GC pauses depends on how you use the heap. If you only allocate objects that live for the duration of the request (which can be enforced by your choice of JVM language) you get the same GC behavior as Erlang (only more general), and a…

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 ;)

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

#38

Post by phamilton »

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…

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 pools and Scala Parallel collections etc.. I've always appreciated the fact that while I won't get the most performance out of BEAM, there's very little I can do wrong that will break my application.

I'm going to have to spend some time with Quasar. If your claims hold up, then Clojure plus Quasar seems like fantastic platform.

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

#39

Post by rudiger »

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.…

If you need a multi-gigabyte, read-only, in-memory data structure with support for ad-hoc querying and concurrent reads... you probably should just use a SQL database.

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

#40

Post by areed »

sargun wrote: post #33
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.…

I mean, you could always keep your large data structure in ETS?

ETS: http://www.erlang.org/doc/man/ets.html
Post reply on HN