5 ms·

> Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at th

by NAFV_P 12y ago

> Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point. I don't think there are many popular high level languages that target systems programming in the first place.

pjmlp 12y ago
The problem was the trend in the mid-90's to move away from native AOT compilers to VM JITs, thus leaving C and C++ as the main to go languages most mainstream developers know, as other options faded out of sight. Hopefully the "going back to native" trend will move us back on track, similar to how it happened in the early 80's VM attempts.
- twic 12y ago
  I think the real problem is the move from manual memory management to garbage collection. Garbage collection has immense advantages, and is indisputably the right choice for most application programming, but it only goes fast if you feed it lots of memory. See figure 3 of this wonderful but terrifying paper: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf (Caveat: that was published in 2005, and garbage collection has improved since then. However, i doubt it has improved enough to invalidate its conclusions.) The best collector there needed ~3x as much memory as a (admittedly superhumanly perfect) manually memory management to get to a competitive speed. There are plenty of problems where that memory is available. But there are plenty where it is not. I can justify giving loads of memory to the application that makes my company money. I can't justify giving it to some tiny little log shipper or message forwarder or other random system utility that i want to run on every machine in my infrastructure.
  - pjmlp 12y ago
    What does it have to do with VMs, though? There are lots of languages with native code generation compilers that have GC[1] support. Since the Xerox PARC days there have been system programming languages with automatic memory management (Cedar, Interlisp, Modula-3, Oberon, ....). They were just ignored by the mainstream OS vendors, that were busy creating UNIX System V and VMS clones. [1] RC is usually GC chapter 1 in CS books.
    - twic 12y ago
      What does it have to do with VMs, though? It doesn't. I think the point about VMs and JITs is a red herring.

by NAFV_P 12y ago

pjmlp 12y ago

The problem was the trend in the mid-90's to move away from native AOT compilers to VM JITs, thus leaving C and C++ as the main to go languages most mainstream developers know, as other options faded out of sight. Hopefully the "going back to native" trend will move us back on track, similar to how it happened in the early 80's VM attempts.

twic 12y ago
I think the real problem is the move from manual memory management to garbage collection. Garbage collection has immense advantages, and is indisputably the right choice for most application programming, but it only goes fast if you feed it lots of memory. See figure 3 of this wonderful but terrifying paper: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf (Caveat: that was published in 2005, and garbage collection has improved since then. However, i doubt it has improved enough to invalidate its conclusions.) The best collector there needed ~3x as much memory as a (admittedly superhumanly perfect) manually memory management to get to a competitive speed. There are plenty of problems where that memory is available. But there are plenty where it is not. I can justify giving loads of memory to the application that makes my company money. I can't justify giving it to some tiny little log shipper or message forwarder or other random system utility that i want to run on every machine in my infrastructure.
- pjmlp 12y ago
  What does it have to do with VMs, though? There are lots of languages with native code generation compilers that have GC[1] support. Since the Xerox PARC days there have been system programming languages with automatic memory management (Cedar, Interlisp, Modula-3, Oberon, ....). They were just ignored by the mainstream OS vendors, that were busy creating UNIX System V and VMS clones. [1] RC is usually GC chapter 1 in CS books.
  - twic 12y ago
    What does it have to do with VMs, though? It doesn't. I think the point about VMs and JITs is a red herring.