34 ms·

Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar m

Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar memory footprint with any kind of GC'd language, and if the GC happens to be a stop the world GC, you're likely to see pauses in the browser that will irritate the user. Before the inevitable "memory is cheap" argument is made, I'd rather have my client app be a good neighbor. Having a GC'd process on a client munch through memory like it's infinite is just bad manners and makes some bad assumptions. (On the flip side, a GC'd process that tries to be a good neighbor by freeing memory aggressively becomes a bad neighbor in terms of CPU time, which has additional consequences in terms of battery life.) The JVM, for example, tends to only run its GC when it needs to. It is a horrible neighbor in this respect because it just takes all the memory it needs and only runs its GC when it really, really has to. This is one of the reasons it's relatively fast, but as a consequence puts a lot of pressure on the system. In such a scenario it's possible other processes will OOM and be killed, or the system will start swapping memory pages, or other processes will have to run their GC more aggressively (as V8 does in low memory conditions) which puts even more pressure on the system. All this adds up to very selfish apps that bog down a system and can become virtually unusable. These selfish apps are also unsuitable for use in poorer parts of the world where incomes are lower and additional memory is potentially unaffordable. I think it's probably okay to take the attitude that memory is cheap when you control the environment and you're paying for the memory, but in any other circumstance, shipping software that gluttonously gobbles memory is probably unacceptable and the #1 reason why C++ makes good sense as a language choice for writing a browser.

asveikau 13y ago
I found this whole discussion irritating because not a single person mentioned that with the memory demands of a web browser that you might not want GC. You can say all this BS about momentum but in my mind avoiding GC is probably the best and most relevant reason in 2013. Thank you for mentioning it. Shows how dependent on GC a large part of the community of developers have become - they are incapable of imagining a world without it. (PS: I am amused when people mention that being 20-50% slower is described as fixing the performance gap.)
- marpalmin 13y ago
  I see your point, but even if you avoid GC you have other alternatives nowadays.
  - kintamanimatt 13y ago
    Such as?
    - yareally 13y ago
      Probably referring to reference counting, but that's not exactly a new idea. Still makes for a performance hit using reference counting all over the place.
      - kintamanimatt 13y ago
        I hope not! Reference counting is horrible in terms of CPU time!
        aktau 13y ago
        Citation?
        kintamanimatt 13y ago
        There is no a priori reason to think that it isn't horrible in terms of CPU time. Anything that has to do more work just to manage memory is going to consume cycles, and usually a lot of them. In simple utility programs it might not be observable but in larger applications with more objects, or on slower hardware (phones, for example) the cost is palpable. > We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing, and that in combination, our optimizations are able to completely eliminate that overhead. This brings the performance of reference counting on par with that of a well tuned mark-sweep collector. [-3] Even the best tuned mark and sweep GCs are a drag on performance. > Reference counting is expensive - every time you manipulate pointers to an object you need to update and check the reference count. Pointer manipulation is frequent, so this slows your program and bloats the code size of compiled code. [-2] > "Unfortunately, reference counting is expensive in both time and space". [-1] Also, the slide entitled "Why reference counting is slow" in some recent lecture notes go into some detail. [0] [-3] http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2... [-2] http://ocaml.org/tutorials/garbage_collection.html http://ocaml.org/tutorials/garbage_collection.html [-1] http://www.rtsj.org/RTJPP/errata.html http://www.rtsj.org/RTJPP/errata.html [0] http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/GC.pdf http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/G...
specialist 13y ago
you're not going to have a similar memory footprint with any kind of GC'd language Cost of GC doesn't bother me. Java's basic overhead for all data structures does. Class String is a mistake. Better to have string scalars compiled down to char[], avoiding the class wrapper. Massive overuse of HashMaps by most frameworks is huge drag too. Using typed collections (vs generics) like Trove helps quite a bit. Our study group had a really good session on optimizing memory usage. Sorry, I can't quickly find the slidedeck we used. I used jamm to profile various strategies. Super fun. I recently saw something in the newsfeed about JVM and optimal memory usage. Bit packing, word boundaries, ordering, etc. (It's more low level than I typically work, so I didn't bookmark it, sorry.)
- eropple 13y ago
  > Cost of GC doesn't bother me. I generally work on the JVM and I do enjoy it, but if you're looking for rock-solid 60fps-all-day-every-day, the cost of GC without question should bother you a great deal. I would never implement a browser in a managed language and I would do everything in my power to avoid gating rendering on the completion of execution of its scripting system for similar reasons.
  - rossjudson 13y ago
    JVM != GC, although it is one of the best implementations out there. Rock-solid FPS doesn't preclude GC. What it requires is a separate rendering layer that isn't subject to any GC pauses (or a game-like rendering loop that's always on time). The managed code manipulates the declarative level of the animations, and the low level handles the frame-by-frame details. On relatively small heap sizes (under a GB) GC on recent PC hardware usually fits into the equivalent of a single frame -- under 30 milliseconds. Concurrent collectors would rarely need anything more than that, and wouldn't stop the world in any case. The question here is, can you build a stable high performance rendering system on the JVM? If not, what would you have to change to be able to do that? Correctly constructed you wouldn't have to change much. And JMonkeyEngine shows you can do a lot with what's there right now. There are some excellent discussions on its site on the topic of GC.
rossjudson 13y ago
I was probably a little too JVM-centric in my post. What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. You're right about memory, but you're wrong when you propose C++ as a solution. C++ doesn't solve any of the problems you outlined. You can implement a solution to those problems in C++. A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). What you're really deciding is whether you want to solve those problems in a VM, or solve them at the application level. Garbage collectors give you two things -- a reliability backstop, and (when you take pointers away) increased security. The behavior of GC is something that can be tuned (often dynamically) for a particular environment.
- Arelius 13y ago
  > What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. Actually, many modern GCs are still "stop the world" including many generational GCs. the alternative generally has overhead elsewhere that hurts performance. GC has a lot of tradeoffs. > A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). Sure, but it sure is a lot easier in C++ since the entire infrastructure doesn't assume GC is operating. I don't even know a way to reliably allocate a temporary object in Java that won't trigger GC I could guess some things that would probably cause the optimizer to allocate it on the stack, but that precludes having the temporary lifetime outlive the stack. (It must however be said, I'm not really a Java programmer) > Garbage collectors give you two things -- ... and (when you take pointers away) increased security. As you just said, increased security is from taking pointers away, which is completely orthogonal to GC.
  - rbehrends 13y ago
    > As you just said, increased security is from taking pointers away, which is completely orthogonal to GC. That's not what he said. Removing pointer arithmetic [1] is part of getting memory safety, but not the entire story. Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. [1] You cannot actually eliminate pointers entirely; you can disguise them, but if you want a dynamic heap and not just static memory, you need to be able to reference memory within the heap. When people talk about eliminating pointers, they generally mean unsafe C-style pointers.

asveikau 13y ago

I found this whole discussion irritating because not a single person mentioned that with the memory demands of a web browser that you might not want GC. You can say all this BS about momentum but in my mind avoiding GC is probably the best and most relevant reason in 2013. Thank you for mentioning it. Shows how dependent on GC a large part of the community of developers have become - they are incapable of imagining a world without it. (PS: I am amused when people mention that being 20-50% slower is described as fixing the performance gap.)

marpalmin 13y ago
I see your point, but even if you avoid GC you have other alternatives nowadays.
- kintamanimatt 13y ago
  Such as?
  - yareally 13y ago
    Probably referring to reference counting, but that's not exactly a new idea. Still makes for a performance hit using reference counting all over the place.
    - kintamanimatt 13y ago
      I hope not! Reference counting is horrible in terms of CPU time!
      - aktau 13y ago
        Citation?
        kintamanimatt 13y ago
        There is no a priori reason to think that it isn't horrible in terms of CPU time. Anything that has to do more work just to manage memory is going to consume cycles, and usually a lot of them. In simple utility programs it might not be observable but in larger applications with more objects, or on slower hardware (phones, for example) the cost is palpable. > We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing, and that in combination, our optimizations are able to completely eliminate that overhead. This brings the performance of reference counting on par with that of a well tuned mark-sweep collector. [-3] Even the best tuned mark and sweep GCs are a drag on performance. > Reference counting is expensive - every time you manipulate pointers to an object you need to update and check the reference count. Pointer manipulation is frequent, so this slows your program and bloats the code size of compiled code. [-2] > "Unfortunately, reference counting is expensive in both time and space". [-1] Also, the slide entitled "Why reference counting is slow" in some recent lecture notes go into some detail. [0] [-3] http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2... [-2] http://ocaml.org/tutorials/garbage_collection.html http://ocaml.org/tutorials/garbage_collection.html [-1] http://www.rtsj.org/RTJPP/errata.html http://www.rtsj.org/RTJPP/errata.html [0] http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/GC.pdf http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/G...

specialist 13y ago

you're not going to have a similar memory footprint with any kind of GC'd language Cost of GC doesn't bother me. Java's basic overhead for all data structures does. Class String is a mistake. Better to have string scalars compiled down to char[], avoiding the class wrapper. Massive overuse of HashMaps by most frameworks is huge drag too. Using typed collections (vs generics) like Trove helps quite a bit. Our study group had a really good session on optimizing memory usage. Sorry, I can't quickly find the slidedeck we used. I used jamm to profile various strategies. Super fun. I recently saw something in the newsfeed about JVM and optimal memory usage. Bit packing, word boundaries, ordering, etc. (It's more low level than I typically work, so I didn't bookmark it, sorry.)

eropple 13y ago
> Cost of GC doesn't bother me. I generally work on the JVM and I do enjoy it, but if you're looking for rock-solid 60fps-all-day-every-day, the cost of GC without question should bother you a great deal. I would never implement a browser in a managed language and I would do everything in my power to avoid gating rendering on the completion of execution of its scripting system for similar reasons.
- rossjudson 13y ago
  JVM != GC, although it is one of the best implementations out there. Rock-solid FPS doesn't preclude GC. What it requires is a separate rendering layer that isn't subject to any GC pauses (or a game-like rendering loop that's always on time). The managed code manipulates the declarative level of the animations, and the low level handles the frame-by-frame details. On relatively small heap sizes (under a GB) GC on recent PC hardware usually fits into the equivalent of a single frame -- under 30 milliseconds. Concurrent collectors would rarely need anything more than that, and wouldn't stop the world in any case. The question here is, can you build a stable high performance rendering system on the JVM? If not, what would you have to change to be able to do that? Correctly constructed you wouldn't have to change much. And JMonkeyEngine shows you can do a lot with what's there right now. There are some excellent discussions on its site on the topic of GC.

rossjudson 13y ago

I was probably a little too JVM-centric in my post. What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. You're right about memory, but you're wrong when you propose C++ as a solution. C++ doesn't solve any of the problems you outlined. You can implement a solution to those problems in C++. A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). What you're really deciding is whether you want to solve those problems in a VM, or solve them at the application level. Garbage collectors give you two things -- a reliability backstop, and (when you take pointers away) increased security. The behavior of GC is something that can be tuned (often dynamically) for a particular environment.

Arelius 13y ago
> What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. Actually, many modern GCs are still "stop the world" including many generational GCs. the alternative generally has overhead elsewhere that hurts performance. GC has a lot of tradeoffs. > A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). Sure, but it sure is a lot easier in C++ since the entire infrastructure doesn't assume GC is operating. I don't even know a way to reliably allocate a temporary object in Java that won't trigger GC I could guess some things that would probably cause the optimizer to allocate it on the stack, but that precludes having the temporary lifetime outlive the stack. (It must however be said, I'm not really a Java programmer) > Garbage collectors give you two things -- ... and (when you take pointers away) increased security. As you just said, increased security is from taking pointers away, which is completely orthogonal to GC.
- rbehrends 13y ago
  > As you just said, increased security is from taking pointers away, which is completely orthogonal to GC. That's not what he said. Removing pointer arithmetic [1] is part of getting memory safety, but not the entire story. Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. [1] You cannot actually eliminate pointers entirely; you can disguise them, but if you want a dynamic heap and not just static memory, you need to be able to reference memory within the heap. When people talk about eliminating pointers, they generally mean unsafe C-style pointers.