Hacker News new | ask | show | jobs
by cliffbean 4509 days ago
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.

2 comments

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.