numbers seem less important considering the run times.

Just because this is a software not an English book.

Reproduced the lower node 0.11.10 performance on gentoo.

time node core_engine_benchmark.js

as author answered below comment, the performance gain/loss could be from switches hence the combination of latest v8/node

Clearly the blog posting focuses around the second item (as a biggest replacement reasoning) which is available on both new and old v8. I couldn't reproduce the same problem on i.e. spidermonkey cli but it's visible on node 0.10.26 / 0.11.13

What does that mean?

Your average is the average score for all of your posts, submissions. I have no idea what it means if it is blank.

Your best bet is probably to submit a bug report: https://github.com/HackerNews/HN It looks like kogir responds to bugs pretty quickly.

Please send problems with accounts to hn@ycombinator.com.

After the hearthbleed incident at least a title was expected.

"The company also gave him four free games, $50 (£30), and a year-long subscription to Xbox Live." .. wondering the titles!

"I spend most of my waking hours writing all sorts of crazy things in node, and I still can't think of any scenario in which using this makes sense."

> You are not alone. remember node.js team members were doing the same in the past but couldn't finish it.

Obviously there are many scenarios this could help.

Clearly, you don't know what you are talking about. LLVM can beat V8. As far as I understand, he put LLVM frontend intogether to see the results and it's not the part of the project yet.

I'm not doubting that it can beat V8, in a mature project with very significant programmer time behind it. But I find it very hard to believe that one weekend of fiddling with an LLVM javascript engine is enough to produce results better than V8, which has had the benefit of years of work from some of the smartest minds in the industry.

At what part I said that Its all done over a weekend?

from the post "..Last weekend I could finish the prototype and measure the initial performance of the solution.."

If you still understand that it's all finished over a weekend. No way.. I don't think it is easy to develop a LLVM frontend with those features over a weekend.

If you could have some details on LLVM, you wouldn't accuse me on something you miss read.

Because;

There is no such an LLVM JS engine. LLVM has its own IR and that prototype turns the JS codes into a wrapped LLVM IR.. As a result the final code functions at native level, so it is already fast.

For this reason, 20% or more performance difference because of LLVM actually shows how V8 is fast! It doesn't show the prototype is over a weekend or anything else..

and Lua .. how Unity3D uses javascript is also related.

I don't know the details but in my opinion a deamon thread like with the Java could work. Besides, I don't think V8 specifically designed for the server use.

If you implement a GC which runs on its own thread, doesn't pause the application, and achieves good overall performance on any real-world code, then it would be a terrific thing to mention in your big blog post announcing the system. We'd love to hear anything you'd like to say about it.

If you don't mention it, and if you also say numerous other things which give the impression that you may not have given the entire topic much thought, then even people who would otherwise prefer to be positive and supportive may struggle to take you seriously, and may react with frustration if you also make extraordinary claims.

My colleague told me the comments here.

I didn't mention clearly since it wasn't a big part of the picture. Dynamic Type part was a bigger problem! Right now I prefer a separate thread for GC but I have also couple of bad cases for this kind of garbage collection. I don't think there is a 'one perfect GC for every kind of usage'. But my focus is performance consistency. Sorry for passing it on my post. I added a side note saying (GC thread).

Thanks for responding. Here's one additional suggestion:

The benchmarks you posted are extremely microscopic and artificial. They are so small, it's possible that LLVM is able to optimize them in ways that are less likely to be possible in any real application. If that's true, then their results don't predict anything about what the results of any real applications might be, and so they read like exaggerated claims. Consequently, while such benchmarks are often useful for development, they're inappropriate for high-level blog posts like this one.

If you don't have any better benchmark numbers to post at this time, that's not necessarily a problem. If you don't post any numbers, people will understand that it's a prototype and you haven't gotten there yet. That's ok.

But by posting these numbers without caveat, you give the appearance of making exaggerated claims.

Considering the fact that nothing yet optimized on the prototype side, it's fair to have a such benchmark since the test cases are complicated enough for a prototype. Indeed V8 performs quite well. The project is under development and only time will show whether they are exaggerated or not.

Perhaps because they take those features for granted because it uses some GC provided by LLVM ?

(I don't know anything about LLVM support for GC, but I would be surprised if it comes with a GC that doesn't require to do something special in order to make it concurrent)

LLVM GC support has been fairly weak, however Apple has been working on using LLVM in JavaScriptCore (FTL project), which requires that, so it should be getting better. I have no idea if this project is related to that in any way.

There is some support for interfacing LLVM with a GC, but LLVM itself does not include a GC.