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

Erlang Doesn’t Fit The JVM

weblog.hypotheticalabs.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Erlang Doesn’t Fit The JVM

#41

Post by mahmud »

jwinter wrote: post #19
ori_b wrote: post #16

Earlier quoted context omitted.

How many of them fit idiomatically into the language you choose to use on the JVM?

Clojure does a good job of introducing new idioms specifically for Java support. From their docs: (doto (new java.util.HashMap) (.put "a" 1) (.put "b" 2)) (.. System (getProperties) (get "os.name"))

iteration and getting system setting stuff are so generic you might as well implement it yourself or write a thin wrapper (in this case iterating over entries in a hash table and getting the OS name)

IMO, a good chunk of the java libraries are there to overcome java deficiencies, and don't produce anything grand on their own for other languages.

Re: Erlang Doesn’t Fit The JVM

#42

Post by nraynaud »

stcredzero wrote: post #34
nraynaud wrote: post #17

Earlier quoted context omitted.

smalltalk is generaly slow, and it has the same calling system as ruby. in smalltalk, methods with the same name don't exist. every method on a object has an unique selector. The selector plays exactly the same role as the signature in java there is no difference on this aspect.

smalltalk is generaly (sic) slow In what context? I've seen implementations of block encryption in Smalltalk that ran 3% faster than a DLL written in C! You wouldn't want to do heavy numerical integration utilizing lots of double precision floating point in Smalltalk, but for a lot of the sort of programming I do, several of the available Smalltalks are very snappy and responsive.

No, if I say "generaly" I don't give context, sorry. Don't answer to a rule of the thumb with anecdote.

More specificaly, on the same algorithm:

It's generaly slower than C/C++ (because of the method calls and the tagged arthmetics), unless you use the GC against the staticaly compiled code and slow allocator, but you need special cases. C/C++ "generaly" have faster method call.

It has few chances to be faster than java/.net who have the static types to get longer monomorphic specialization chains appart from corner cases, and generaly better GCs. And those can do deoptimization if the profile change, it's been a long time I left smalltalk, but the last time I checked VisualWorks couldn't.

Re: Erlang Doesn’t Fit The JVM

#43

Post by jules »

glymor wrote: post #6

Erlang's VM is unmatched scaling above 16+ cores (for example process migration http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-desig... ) this is something that the java vm hasn't even begun to look at.

Is Erlang with 16 cores faster than Java with 4?

Re: Erlang Doesn’t Fit The JVM

#44

Post by jerf »

johnm wrote: post #27

If you want a VM that's totally geared towards "dynamic languages" you should definitely check out Parrot ( http://www.parrot.org/ ).

Erlang isn't a dynamic language in the sense that Parrot is optimized for, either. Erlang-on-Parrot wouldn't be able to use any other libraries developed for the Parrot ecosystem as they would depend on mutable languages any better than it already can (it would still have to go through the Erlang ports), eliminating a major reason to go to a given VM, and the Parrot VM optimizes a lot of cases that Erlang doesn't care about while missing out on many it does.

Erlang's data structures are not manifestly typed, but in most other ways it is a static language.

Re: Erlang Doesn’t Fit The JVM

#45

Post by stcredzero »

nraynaud wrote: post #42
stcredzero wrote: post #34

Earlier quoted context omitted.

smalltalk is generaly (sic) slow In what context? I've seen implementations of block encryption in Smalltalk that ran 3% faster than a DLL written in C! You wouldn't want to do heavy numerical integration utilizing lots of double precision floating point in Smalltalk, but for a lot of the sort of programming I do, several of the available Smalltalks are very snappy and responsive.

No, if I say "generaly" I don't give context, sorry. Don't answer to a rule of the thumb with anecdote. More specificaly, on the same algorithm : It's generaly slower than C/C++ (because of the method calls and the tagged arthmetics), unless you use the GC against the staticaly compiled code and slow allocator, but you need special cases. C/C++ "generaly" have faster method call. It has few chances to be faster than…

In 11 years of Smalltalk IT consulting, I have never run up against the message send being a performance issue. For me, it's accessing the disk, the database, middleware, poor design with regards to network latency, or poor algorithm design.

Re: Erlang Doesn’t Fit The JVM

#46

Post by akeefer »

nraynaud wrote: post #13

first class closures are not a JVM problem, but a language problem. Moreover, closures (lexical closures) exists in java itself: an annonymous inner class captures (well, on demand, for perf reasons) all the lexical terms visible at the point of use. the tail call is a bytecode security problem. Looks like this problem has been solved and will be merged.

Anonymous inner classes aren't really closures in the more traditional sense, since they require that the captured variables be final; that makes them more restricted than closures generally are in other programming languages. That might not be a problem for Erlang given its write-once variables, but it is a problem for other languages.

We've been working on generating JVM bytecode for our in-house language, which does support a less-restricted version of closures, and we work around that by wrapping closed variables in one-element arrays, though you have to do for both the initial declaration and on every reference to that variable, even outside the closure, which gets really annoying when the closed variable is something passed onto the stack as a function argument, and probably in other cases I'm not thinking about right now. It's definitely workable, it's just messy and incurs more overhead than is ideal.

Re: Erlang Doesn’t Fit The JVM

#47

Post by akeefer »

noss wrote: post #5

Isn't LLVM a more interesting universal machine to target anyway?

I don't know too much about LLVM, but the JVM has a ton of advantages: it's pretty much universally available on all platforms, it uses a fairly trivial set of instructions that make learning the instruction set and using it fairly easy, there's a ton of information out there about it covering everything from GC algorithms to VM flags to bytecode instructions and memory models, and both the Sun and IBM versions have been heavily optimized over the years. It might not be the best fit for every language, but it's a pretty impressive platform to build a language on.

Re: Erlang Doesn’t Fit The JVM

#48

Post by nraynaud »

stcredzero wrote: post #45
nraynaud wrote: post #42

Earlier quoted context omitted.

No, if I say "generaly" I don't give context, sorry. Don't answer to a rule of the thumb with anecdote. More specificaly, on the same algorithm : It's generaly slower than C/C++ (because of the method calls and the tagged arthmetics), unless you use the GC against the staticaly compiled code and slow allocator, but you need special cases. C/C++ "generaly" have faster method call. It has few chances to be faster than…

In 11 years of Smalltalk IT consulting, I have never run up against the message send being a performance issue. For me, it's accessing the disk, the database, middleware, poor design with regards to network latency, or poor algorithm design.

I take your message, and change the "Smalltalk" by any other language, and I get a generic excuse for any language.

You can take a prominent ruby website, they will never admit ruby is slow, they cache everything everywhere to do the trick and then blame the algorithm too. Where on a JVM/.net platform the guys could recompute the same stuff 300/s without even needing to think about it, and still having the IO as a bottleneck. The same algorithm would'nt even be necessary in the first place.

BUT there are actually great differences in execution speed (or memory consumption) in languages for the same algorithm.

When your language pales in the benchmark, then you have various choices : - dismiss the bench as not "real life" - rewrite the algorithm to bank on the strength of your language (for smalltalk I would bet on the GC) - count the lines of code (readability is not an objective metric so you can kill it for free). "Yeah but mine is more maintainable". - admit that this is one weakness of your language and learn other languages for the day you'll need them.

I'm not dismissing your experience (far from it, actually I tend to like "slow languages" too). I've worked with smalltalk and some friend did crazy stuff with it performance wise, I did crazy stuff in java too.

But - smalltalk have a slow message dispatch time - ruby have slow message dispatch and no real GC - java have too big memory footprint and is too verbose - O'caml and haskell have unreadable type error messages when you play with inference. And they are statically compiled. - etc.

perfection doesn't exist, live with it.

Re: Erlang Doesn’t Fit The JVM

#49

Post by johnbender »

Why would you even bother doing this in the first place. Erlang's VM is one the things that makes it interesting, Not the syntax.

The only reason I can see is the OTP libraries, but then again, why not just use the Erlang VM as you get so much great stuff for Actor based concurrency out of it.

Post reply on HN