5 ms·

This blog post is either spectacularly naive, or ridiculously over-hyped, or both. "Consistent performance. (not like the V8 engine pausing the whole applicati

This blog post is either spectacularly naive, or ridiculously over-hyped, or both. "Consistent performance. (not like the V8 engine pausing the whole application for GC)" Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.

lohan 13y ago
So you are okay with having the server process is not responding for ten seconds? Come on!
- mbreese 13y ago
  Be serious. It's not a question of the process not responding for 10 seconds. If the same code in V8 is causing a pause to deal with GC, then the LLVM compiled code must be doing something different to handle the memory. Is it using a different GC? Is it running on a different thread? Is it just sucking up memory without freeing it? These are all things that need to be known before getting too excited about the speed of LLVM compiled Javascript.
  - moisy 13y ago
    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.
    - cliffbean 13y 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.
      - ithkuil 13y ago
        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)
        azakai 13y ago
        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.
        cliffbean 13y ago
        There is some support for interfacing LLVM with a GC, but LLVM itself does not include a GC.
      - obastemur 13y ago
        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).
        cliffbean 13y ago
        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.
azakai 13y ago
The article says it uses a GC thread. So perhaps it does fully concurrent GC, with no main-thread pauses whatsoever. Your skepticism is very justified, however - I would like to see the various existing GC benchmarks and GC latency benchmarks working with no pauses, to believe this.

lohan 13y ago

So you are okay with having the server process is not responding for ten seconds? Come on!

mbreese 13y ago
Be serious. It's not a question of the process not responding for 10 seconds. If the same code in V8 is causing a pause to deal with GC, then the LLVM compiled code must be doing something different to handle the memory. Is it using a different GC? Is it running on a different thread? Is it just sucking up memory without freeing it? These are all things that need to be known before getting too excited about the speed of LLVM compiled Javascript.
- moisy 13y ago
  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.
  - cliffbean 13y 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.
    - ithkuil 13y ago
      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)
      - azakai 13y ago
        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.
      - cliffbean 13y ago
        There is some support for interfacing LLVM with a GC, but LLVM itself does not include a GC.
    - obastemur 13y ago
      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).
      - cliffbean 13y ago
        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.

azakai 13y ago

The article says it uses a GC thread. So perhaps it does fully concurrent GC, with no main-thread pauses whatsoever. Your skepticism is very justified, however - I would like to see the various existing GC benchmarks and GC latency benchmarks working with no pauses, to believe this.