Hacker News new | ask | show | jobs
by sanjayts 3423 days ago
I am awfully wary of these statements which paint languages like Python (via PyPy), Javascript (via Node) as very close competitors of the JVM. Once the JIT engine kicks in, on "real" workloads, JVM beats the lights out of these carefully tuned interpreted languages on a CPU intensive workload.
1 comments
coldtea 3423 days ago
>Once the JIT engine kicks in, on "real" workloads, JVM beats the lights out of these carefully tuned interpreted languages on a CPU intensive workload.

For one, JS is also JITed. Second we have video players and other tasks done on native JS, which would be impossibly slow on say Python.

Second, JS can also be compiled -- there's asm.js and WebAssembly coming down the road.

So, yes, it might be slower than the JVM, but not that slower for most practical purposes.

link
sanjayts 3422 days ago
> For one, JS is also JITed

But not all JITs are equal; that's like putting Brainfuck in the mix because it has a JIT. It is worth noting that JVM JIT has years of research behind it and being statically typed only adds to he benefits.

> So, yes, it might be slower than the JVM, but not that slower for most practical purposes.

Sure, my point is that the "not that slower" varies on lot depending on the kind of computation would run and having a notion that these dynamic languages are fast enough just perpetuates the misunderstanding that there exists free lunch...

link
coldtea 3422 days ago
>It is worth noting that JVM JIT has years of research

I hear that a lot and it's a moot point. It's not like the same research is not available to those doing the JS JITs. Unless we're talking about patents, techniques for faster JITing are widely known, and get propagated to newer languages and runtimes all the time.

And in fact, even the people are usually the same (e.g. people that started the initial fast JITs in the days of Smalltalk, then went to JVM, and now work on V8).

>Sure, my point is that the "not that slower" varies on lot depending on the kind of computation would run and having a notion that these dynamic languages are fast enough just perpetuates the misunderstanding that there exists free lunch...

Well, certainly fast enough for web apps, where we have been using 10x slower languages with no JITs and huge overheads.

link