6 ms·

I think the relevant bit is that we're seeing this without GC which makes it applicable to a whole set of problems that weren't previously relevant(which is als

I think the relevant bit is that we're seeing this without GC which makes it applicable to a whole set of problems that weren't previously relevant(which is also why I think Rust is so interesting). Yeah, we get it that functional languages came first, but rather than looking down on C++ why not celebrate that functional constructs are making it into places where they haven't been before.

rwmj 11y ago
What are the problems where GC can't be used? I'm going to guess very tiny embedded systems and hard real time. What are the places where C++ is being used? Unfortunately a lot more than those, resulting in expensive, unreliable, insecure software.
- marshray 11y ago
  'hard real time' -> multimedia and action games
  - unwind 11y ago
    Not sure what you mean by that arrow, but if you're implying those things on the right are examples of hard real-time, I disagree. In hard real-time systems, there's generally the idea that if scheduling fails, things will break and/or property (or, worse, people) will be damaged. Think of things like industrial high-torque motor control and avionics.
    - mpweiher 11y ago
      Also, hard real-time systems often don't have to be particularly fast. They are just not allowed to ever be late.
      - AnimalMuppet 11y ago
        This. "The right answer, too late, is wrong."
        mpweiher 11y ago
        And it doesn't matter if you got the right answer 100 times faster than needed 99 times if you are late once.
    - marshray 11y ago
      Physical property damage isn't a requirement of the definition of 'hard real time', it's just that common examples are often given that way. If deadlines are missed in multimedia applications the product isn't meeting its stated and implied requirements. The consequences may be different, but a television that drops perceptible video frames is just as 'defective' (from an engineering point of view) as an industrial control system which drops motor control signals.
- Guvante 11y ago
  To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. There is at least work towards making controlled GC pauses a possibility.
  - pron 11y ago
    > random multi-millisecond pauses break everything Then either use a GC that doesn't have multi-millisecond pauses, or make sure your "plain" GC doesn't. Both approaches are used very commonly.
    - Guvante 11y ago
      It is hard to have a discussion about GC's in the super abstract because object pools are better than GC's and even malloc. Without additional details about what the implementation will look like it is impossible to know the best memory allocation mechanism is. I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. I did not say that GC's are incompatible with soft-realtime systems.
      - pron 11y ago
        > because object pools are better than GC's Object pools and GCs do different things, and you can have object pools in both GCed environments as in manually-managed ones, and they'd work equally the same. But note that you need a very, very good (and far from trivial) object pool to beat a good GC in multithreaded environments. > I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. Well, most free ones. If you're writing a soft-realtime system with stricter latency requirements you'll either work harder to avoid the GC or pay for a low-latency one.
  - pjmlp 11y ago
    > To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. Like these ones? http://www.atego.com/de/products/atego-perc/ http://www.atego.com/de/products/atego-perc/ Used for this? http://mil-embedded.com/news-id/?21468= http://mil-embedded.com/news-id/?21468=
- vvanders 11y ago
  Any place you care about memory layout, AKA performance. O(n) doesn't matter if you cache miss all over the place. Some GC languages(like C#'s structs) have some tools for this but as soon as you work with refs you've lost control. To me that's any device with a battery(I'm looking at you smartphones), gamedev, and as you mentioned embedded systems. There's also another class of programs that's not related to GC. C++(and C by subset) is the only way to write truly cross-platform code for all the modern OS's. If you want to target Android, iOS and Desktop C++ is the only supported path on all those platforms with the right performance guarantees(JS doesn't cut it perf-wise on mobile, yet). That's why you see DropBox and quite a few other shops using C++.
  - pron 11y ago
    GC and control over memory layout are two completely orthogonal issues. You can have either one, neither, or both.
    - vvanders 11y ago
      I don't know that they're completely orthogonal, GC by nature controls the allocation of objects which implicitly means that the layout in memory is controlled by the GC algorithm. For instance if you have a GC that compacts then by definition you cannot guarantee object relative layout. This object layout is critical in making sure that your traversal order is cache and pre-fetch friendly. AFAIK struts+arrays in C# are the only construct I've seen that lets you get close to explicitly control ordering of objects. In almost every other GC'd language you end up needing to use a giant byte array(hello emscripten!) in order to make those guarantees. If you work in that manner you're throwing away 90% of what makes the language useful and paying the cost of not working with the objects in their native form.
      - pjmlp 11y ago
        > AFAIK struts+arrays in C# are the only construct I've seen that lets you get close to explicitly control ordering of objects. Check Mesa/Cedar, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, D. All system programming languages with GC.
- pron 11y ago
  I've used a GC language (Java) in hard-realtime systems successfully. Realtime Java (RTSJ) gives you control over which threads can trigger a GC and which operate in an arena. Even hard realtime systems have a very small core that's actually hard realtime, and real-time Java isolates it nicely.
  - vvanders 11y ago
    Isn't that effectively the same thing as embedding the JVM inside C/C++ with thread execution control? From what I've read on the RTJS spec the real-time areas you're talking about use an arena allocator which is a different memory allocation strategy than GC.
    - pron 11y ago
      > Isn't that effectively the same thing as embedding the JVM inside C/C++ with thread execution control? I don't see how. > From what I've read on the RTJS spec the real-time areas you're talking about use an arena allocator which is a different memory allocation strategy than GC. Yes, but both hard- and soft-realtime threads (that do use a GC) share the same JVM and can share some objects. Also, keep in mind that realtime JVMs guarantee scheduling latency for hard realtime threads of up to a few microseconds. If you can live with higher latencies, you can use realtime GCs.
- agentultra 11y ago
  I can think of a few more... Operating Systems. Games. Deterministic soft and hard real-time systems (there's a reason you wouldn't be able to certify a control system for a fighter jet written in Javascript). Scientific stacks. Multi-media (do you think Renderman is written in Ruby?). I'd even argue against using GC'd languages in desktop applications. It's getting to a point where these run-times are gobbling up a few gigs worth of pages from the OS and they still hang or crash when the OS decides to start paging them to disk. Or another process gets priority from the scheduler. The fact is while processor speeds have increased memory hasn't and that's the big bottle-neck on current hardware. Despite popular beliefs I think users do care about performance. They don't notice good performance but as soon as that beachball/whitescreen/whatever comes up and the UI is unresponsive you can bet their face is scrunching up like a walnut. Does that happen only to 1 or 2 users? 10%? We don't measure things like that enough when our happy little GC will take care of it for us. Tuning GCs for workloads is probably as much or more work, in my limited experience, as designing your program from the bottom up around its specific data patterns. You'll get better performance from the latter approach more often than tuning a GC to your workloads after profiling. The wins in that case are incremental (we tuned our JVM after some profiling and shaved off 1.8% from our inner loop!). Where they can be dramatic with the right data structures and careful attention to locality (we saw an 800x reduction in cycles due to cutting unnecessary allocations and a 300% speed increase -- sweet!). Even tuning your allocation strategy can net you bigger gains than trying to structure your code around a JIT. All that being said -- GC's are incredibly useful in many situations. You just have to measure and be thoughtful. Memory is still an issue GC or not.
  - pjmlp 11y ago
    > Tuning GCs for workloads is probably as much or more work, in my limited experience, as designing your program from the bottom up around its specific data patterns. If you are coding the full application yourself, probably. If doing distributed development with 20+ team members from multiple contractors of various skill levels, which is my world, I have my doubts.
jlarocco 11y ago
> Yeah, we get it that functional languages came first, but rather than looking down on C++ why not celebrate that functional constructs are making it into places where they haven't been before. Because that's a meaningless thing to celebrate? Having functional concepts available in a poorly integrated way, with super ugly syntax is more depressing than anything, because seeing it in use is a reminder of how much cleaner it would be in a language like Haskell or OCaml. Why not accept that C++ isn't a functional language, and realize that many die-hard C++ users won't use these features for the same reasons they're not already using functional languages. I'd rather see these efforts directed towards improving the compilers and libraries for languages like Haskell, OCaml, etc.
- dragonwriter 11y ago
  > Having functional concepts available in a poorly integrated way, with super ugly syntax is more depressing than anything, because seeing it in use is a reminder of how much cleaner it would be in a language like Haskell or OCaml. I swear I remember fans of older OO languages saying the almost exactly the same thing with "object oriented" in place of "functional" about the way C++ grafted OO concepts onto C when C++ was new -- and, IMO, with good justification. Still, C++ was not exactly unsuccessful with that, either.
- CyberDildonics 11y ago
  I guess that's why so much of the software you use every day is written in Haskell and OCaml.
- quizotic 11y ago
  > Why not accept that C++ isn't a functional language, and realize that many die-hard C++ users won't use these features I'm a die-hard C++ user, and have come to love functional programming for a very C++y reason: improved performance that comes from lock-free parallelizability (if you never modify values, you don't have to synchronize access). But I also love the simplicity that comes from not having to think so deeply about lifetimes and which portions of code can see which objects in which states. The abstraction of data-structure from algorithm is nice, the terseness is nice, the regularity is nice, but it's the lifetime and visibility simplification that helps me the most. I don't know Haskell or OCaml. I wouldn't know a monad if it slapped me in the face. But functional C++ makes me happy

rwmj 11y ago

What are the problems where GC can't be used? I'm going to guess very tiny embedded systems and hard real time. What are the places where C++ is being used? Unfortunately a lot more than those, resulting in expensive, unreliable, insecure software.

marshray 11y ago
'hard real time' -> multimedia and action games
- unwind 11y ago
  Not sure what you mean by that arrow, but if you're implying those things on the right are examples of hard real-time, I disagree. In hard real-time systems, there's generally the idea that if scheduling fails, things will break and/or property (or, worse, people) will be damaged. Think of things like industrial high-torque motor control and avionics.
  - mpweiher 11y ago
    Also, hard real-time systems often don't have to be particularly fast. They are just not allowed to ever be late.
    - AnimalMuppet 11y ago
      This. "The right answer, too late, is wrong."
      - mpweiher 11y ago
        And it doesn't matter if you got the right answer 100 times faster than needed 99 times if you are late once.
  - marshray 11y ago
    Physical property damage isn't a requirement of the definition of 'hard real time', it's just that common examples are often given that way. If deadlines are missed in multimedia applications the product isn't meeting its stated and implied requirements. The consequences may be different, but a television that drops perceptible video frames is just as 'defective' (from an engineering point of view) as an industrial control system which drops motor control signals.
Guvante 11y ago
To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. There is at least work towards making controlled GC pauses a possibility.
- pron 11y ago
  > random multi-millisecond pauses break everything Then either use a GC that doesn't have multi-millisecond pauses, or make sure your "plain" GC doesn't. Both approaches are used very commonly.
  - Guvante 11y ago
    It is hard to have a discussion about GC's in the super abstract because object pools are better than GC's and even malloc. Without additional details about what the implementation will look like it is impossible to know the best memory allocation mechanism is. I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. I did not say that GC's are incompatible with soft-realtime systems.
    - pron 11y ago
      > because object pools are better than GC's Object pools and GCs do different things, and you can have object pools in both GCed environments as in manually-managed ones, and they'd work equally the same. But note that you need a very, very good (and far from trivial) object pool to beat a good GC in multithreaded environments. > I was just pointing out that most GC's that are general purpose have 2-3 ms pauses for collection which is a no-go for soft-realtime systems. Well, most free ones. If you're writing a soft-realtime system with stricter latency requirements you'll either work harder to avoid the GC or pay for a low-latency one.
- pjmlp 11y ago
  > To be fair soft-realtime systems don't interact well with GC's since random multi-millisecond pauses break everything. Like these ones? http://www.atego.com/de/products/atego-perc/ http://www.atego.com/de/products/atego-perc/ Used for this? http://mil-embedded.com/news-id/?21468= http://mil-embedded.com/news-id/?21468=
vvanders 11y ago
Any place you care about memory layout, AKA performance. O(n) doesn't matter if you cache miss all over the place. Some GC languages(like C#'s structs) have some tools for this but as soon as you work with refs you've lost control. To me that's any device with a battery(I'm looking at you smartphones), gamedev, and as you mentioned embedded systems. There's also another class of programs that's not related to GC. C++(and C by subset) is the only way to write truly cross-platform code for all the modern OS's. If you want to target Android, iOS and Desktop C++ is the only supported path on all those platforms with the right performance guarantees(JS doesn't cut it perf-wise on mobile, yet). That's why you see DropBox and quite a few other shops using C++.
- pron 11y ago
  GC and control over memory layout are two completely orthogonal issues. You can have either one, neither, or both.
  - vvanders 11y ago
    I don't know that they're completely orthogonal, GC by nature controls the allocation of objects which implicitly means that the layout in memory is controlled by the GC algorithm. For instance if you have a GC that compacts then by definition you cannot guarantee object relative layout. This object layout is critical in making sure that your traversal order is cache and pre-fetch friendly. AFAIK struts+arrays in C# are the only construct I've seen that lets you get close to explicitly control ordering of objects. In almost every other GC'd language you end up needing to use a giant byte array(hello emscripten!) in order to make those guarantees. If you work in that manner you're throwing away 90% of what makes the language useful and paying the cost of not working with the objects in their native form.
    - pjmlp 11y ago
      > AFAIK struts+arrays in C# are the only construct I've seen that lets you get close to explicitly control ordering of objects. Check Mesa/Cedar, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, D. All system programming languages with GC.
pron 11y ago
I've used a GC language (Java) in hard-realtime systems successfully. Realtime Java (RTSJ) gives you control over which threads can trigger a GC and which operate in an arena. Even hard realtime systems have a very small core that's actually hard realtime, and real-time Java isolates it nicely.
- vvanders 11y ago
  Isn't that effectively the same thing as embedding the JVM inside C/C++ with thread execution control? From what I've read on the RTJS spec the real-time areas you're talking about use an arena allocator which is a different memory allocation strategy than GC.
  - pron 11y ago
    > Isn't that effectively the same thing as embedding the JVM inside C/C++ with thread execution control? I don't see how. > From what I've read on the RTJS spec the real-time areas you're talking about use an arena allocator which is a different memory allocation strategy than GC. Yes, but both hard- and soft-realtime threads (that do use a GC) share the same JVM and can share some objects. Also, keep in mind that realtime JVMs guarantee scheduling latency for hard realtime threads of up to a few microseconds. If you can live with higher latencies, you can use realtime GCs.
agentultra 11y ago
I can think of a few more... Operating Systems. Games. Deterministic soft and hard real-time systems (there's a reason you wouldn't be able to certify a control system for a fighter jet written in Javascript). Scientific stacks. Multi-media (do you think Renderman is written in Ruby?). I'd even argue against using GC'd languages in desktop applications. It's getting to a point where these run-times are gobbling up a few gigs worth of pages from the OS and they still hang or crash when the OS decides to start paging them to disk. Or another process gets priority from the scheduler. The fact is while processor speeds have increased memory hasn't and that's the big bottle-neck on current hardware. Despite popular beliefs I think users do care about performance. They don't notice good performance but as soon as that beachball/whitescreen/whatever comes up and the UI is unresponsive you can bet their face is scrunching up like a walnut. Does that happen only to 1 or 2 users? 10%? We don't measure things like that enough when our happy little GC will take care of it for us. Tuning GCs for workloads is probably as much or more work, in my limited experience, as designing your program from the bottom up around its specific data patterns. You'll get better performance from the latter approach more often than tuning a GC to your workloads after profiling. The wins in that case are incremental (we tuned our JVM after some profiling and shaved off 1.8% from our inner loop!). Where they can be dramatic with the right data structures and careful attention to locality (we saw an 800x reduction in cycles due to cutting unnecessary allocations and a 300% speed increase -- sweet!). Even tuning your allocation strategy can net you bigger gains than trying to structure your code around a JIT. All that being said -- GC's are incredibly useful in many situations. You just have to measure and be thoughtful. Memory is still an issue GC or not.
- pjmlp 11y ago
  > Tuning GCs for workloads is probably as much or more work, in my limited experience, as designing your program from the bottom up around its specific data patterns. If you are coding the full application yourself, probably. If doing distributed development with 20+ team members from multiple contractors of various skill levels, which is my world, I have my doubts.

jlarocco 11y ago

> Yeah, we get it that functional languages came first, but rather than looking down on C++ why not celebrate that functional constructs are making it into places where they haven't been before. Because that's a meaningless thing to celebrate? Having functional concepts available in a poorly integrated way, with super ugly syntax is more depressing than anything, because seeing it in use is a reminder of how much cleaner it would be in a language like Haskell or OCaml. Why not accept that C++ isn't a functional language, and realize that many die-hard C++ users won't use these features for the same reasons they're not already using functional languages. I'd rather see these efforts directed towards improving the compilers and libraries for languages like Haskell, OCaml, etc.

dragonwriter 11y ago
> Having functional concepts available in a poorly integrated way, with super ugly syntax is more depressing than anything, because seeing it in use is a reminder of how much cleaner it would be in a language like Haskell or OCaml. I swear I remember fans of older OO languages saying the almost exactly the same thing with "object oriented" in place of "functional" about the way C++ grafted OO concepts onto C when C++ was new -- and, IMO, with good justification. Still, C++ was not exactly unsuccessful with that, either.
CyberDildonics 11y ago
I guess that's why so much of the software you use every day is written in Haskell and OCaml.
quizotic 11y ago
> Why not accept that C++ isn't a functional language, and realize that many die-hard C++ users won't use these features I'm a die-hard C++ user, and have come to love functional programming for a very C++y reason: improved performance that comes from lock-free parallelizability (if you never modify values, you don't have to synchronize access). But I also love the simplicity that comes from not having to think so deeply about lifetimes and which portions of code can see which objects in which states. The abstraction of data-structure from algorithm is nice, the terseness is nice, the regularity is nice, but it's the lifetime and visibility simplification that helps me the most. I don't know Haskell or OCaml. I wouldn't know a monad if it slapped me in the face. But functional C++ makes me happy