Hacker News new | past | comments | ask | show | jobs | submit login

Actually it's kind of funny how Node community are obsessed about benchmark and speed because Node is very slow on CPU and cannot even do parallelism properly.



That's completely incorrect. Well known cluster modules allows very easy parallelism at any level in your application. Plus Node is among the fastest interpreted languages around today -- coming close to the jvm in performance.


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.


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


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


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


I remember the dev of uws got some hate last year. Ppl were complaining that uws would only perform well on C++ stacks and be slow on Node. So I guess he simply wanted to prove them wrong.


IO-intensive (what this module would be used for) != CPU-intensive. When considering "pure" code in CPython, YARV or Perl, JavaScript easily out performs all of those, when thinking of dynamic languages which the Node community would be mostly comparing against. Obviously compiled and statically compiled languages are a different ball park in terms of both performance and culture.


Well isn't that a reason to compare against real competitors instead of showing off against the ones you can beat?


Yes definitely, just really pointing out that the Node community probably has more in common to those languages community and motivations than the C++, Java, Haskell community (just to pick some examples) for many differing reasons.


>because Node is very slow on CPU and cannot even do parallelism properly

Compared to what? Python? Ruby? PHP?

None of which can do "parallelism properly" and all of which are from 2 times to an order of magnitude slower than v8 (Node's engine).

Even Go can't do parallelism properly -- it's model is full of manual handling of deadlocks and races. Erlang, yes.


Could you mention what this is based on, please?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: