5 ms·

You are also allowed to write in a GC language.

pkolaczk 6y ago
The problem with GC languages is that if the requirements (or data sizes) change and you run into performance problems related to GC later (e.g unacceptable pause times or high heap usage) then it is extremely hard to get out. Often the only choice is a complete rewrite of time-critical parts. There is a whole world of difference between a Rust program that does clone() occasionally to escape borrow checker strictness and a Java program that allocates 99% of stuff like crazy on GCed heap.
- galacticdessert 6y ago
  True, but I expect that only ~2% of programs to ever run into this problem
  - pkolaczk 6y ago
    Then how come everything is so ridiculously slow these days, despite faster computers? I've ran into situations when displaying text on the screen was lagging - and that in several different programs, on various (modern) computers. Not saying GC was a problem there, but I guess this has something to do with the generally accepted culture of "only 2% of programs need high performance".
    - higerordermap 6y ago
      > Then how come everything is so ridiculously slow these days, despite faster computers? There is difference between GC overhead, VM overhead, interpreter overhead, and programmer not understanding basic concepts and doing stupid shit. Go is GC language and tools written in Go often approach C/C++ speeds, despite lacking an optimizer like LLVM and lack of some performance oriented features. Another example is OCaml.
    - sacado2 6y ago
      > Then how come everything is so ridiculously slow these days, despite faster computers? As you said, it's usually not a GC issue. Many of these ridiculously slow programs you talk about are written in C++.
      - pkolaczk 6y ago
        VSCode, Slack, Intellij Idea, some random JS on a website - indeed all C++ programs. I'm not arguing against GC, but more about the philosophy of saying that only 2% programs need a good level of performance. It starts from using GC instead of thinking about object ownerships (which btw often also results in harder to read, more convoluted code) and ends up launching an embedded web-browser to display a few images and a bunch of text and taking 1 GB of RAM. But it is not developer's RAM, so who cares? Summarising - using a GCed language instead of dropping a few occasional clone calls in the code is bad advice, unless the program is really a one-off fire and forget thing (but these are not 98% of software).
        sacado2 6y ago
        The soft I have the most performance issues are Firefox, LibreOffice and Aperçu (don't know its original name, but it's called that way in French -- Apple's PDF viewer). All of them written in different, non-GCed languages. Usuall the problem is abuse of abstraction layers, more than abuse of a GC. And your javascript examples are a good example of that. GCed languages tend to abuse dynamic allocation and dynamic dispatch, even when it's not needed (there is more garbage to deal with). However I agree the idea only a few software need to run fast is bullcrap.
- pizza234 6y ago
  There was recent talk about the small kernel written in Go (I can't find the thread, though), which showed Go can have a performance profile good for systems programming. The considerations can be very complex though, e.g. what's the effort required for reaching this performance profile? is it consistent across all the types of project? etc.etc.
  - pkolaczk 6y ago
    When Java came out, and later when C#/.NET arrived some people did the same with them. Nihil novi. It is often easier to get decent performance in tiny projects or micro-benchmarks, simply because you can spend so much more time on optimization vs all other tasks. That's probably why I often see Java benchmarks claiming close-to-C performance (only ~2x slower) levels, but I fail to see it in real big applications.
    - pjmlp 6y ago
      Yet I have replaced plenty of C++ systems with Java/.NET based ones, or hybrid solutions where C++ is left for a couple of high performance libraries (e.g. in COM), with the rest in some managed language. If the hard deadlines are still met, it doesn't matter that another solution is 50% faster when it takes 150% more money to develop and doesn't bring anything to the table (hard deadlines were accomplished). This is what people keep forgetting when arguing my language is faster than yours. What I care is about project costs, meeting deadlines and acceptance criteria.
      - Shorn 6y ago
        > What I care is about project costs, meeting deadlines and acceptance criteria. Are you sure you're on the right website? :D
      - pkolaczk 6y ago
        50% faster and 150% more expensive are numbers my experience doesn't agree with. First, programs coded in Rust are typically nowhere near 50% faster than the ones coded in managed languages - I observe 500% to 5000% differences. And it is not just faster but also uses an order of magnitude less memory. In cloud based software this translates to savings on TCO users of the software I write do care about. Second, as for 150% more development cost - this is also not my experience. There is some upfront cost related to learning a new language, but then later this pays off on maintenance and bug finding (lack of data races or relying on fragile runtime reflection are big ones). Plus Rust is more expressive than Java/C#/Go and many common programming problems are actually surprisingly faster to code. E.g serialization / deserialization of object graphs.
- Const-me 6y ago
  > and a Java program that allocates 99% of stuff like crazy on GCed heap Java is too extreme with GC, not all languages are like that. In .NET it's only moderately hard to avoid GC when you want to. It has value types, real stack, and other relevant features. Here's an example of non-trivial code written in that style for performance reasons: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
- pjmlp 6y ago
  1 - Not all GC languages are Java 2 - Those languages offer C++ like features for memory management if one bothers to actually learn to use them 3 - Java is also getting them via projects Panama and Valhalla So it is more a matter to actually bother to learn the tools one has at their disposition.
  - pkolaczk 6y ago
    1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCed languages, in particular when we also take memory use and pauses into account, not just throughput. Throughput, low latency, low memory use - there are inherent tradeoffs between them and usually you can pick only one to tune for. 2 - Not really. The fact they allow to allocate/deallocate manually is not enough. Dealing with non-GCed memory in Java or C# is much more error-prone and less ergonomic than even in C++. E.g. no automatic reference counting nor RAII. 3 - It is 5 years in development now and as far as the specs goes value types will be limited to immutable objects only, so it is inefficient by design and it solves only half of the problem. Similarly high hopes were associated with escape analysis which turned out to be totally ineffective.
    - pjmlp 6y ago
      1 - Java is not the only game in town. 2 - automatic reference counting is slower than tracing GC. Strange to prefer something with less performance. RAII is possible in C# via IDispose (alongside Roslyn compiler errors for not using it properly) and FP patterns similar to -with in Common Lisp. 3 - It is a major engineering feat to design a feature that will work out of the box with 25 years old compiled jars without playing a Python 2 in the Java world. Naturally it takes its time to get right. Just like it took 10 years to get modules and concepts and they are still not available across all major C++ compilers. Good engineering takes time.
      - pkolaczk 6y ago
        1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects. 2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient. 3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.
dpc_pw 6y ago
Yeah, but dealing with debugging leaking resources (because memory is just one of many resources that a program will use, and GCs don't help with most of them) sucks. https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficient https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... Ownership model seems hard for people to internalize, but once learned feels very natural, leads to programs that are better structured and frees programmer from "manually managing resources".
- pjmlp 6y ago
  That is what happens when one doesn't learn the available tooling for doing deterministic resource management in GC languages.
  - higerordermap 6y ago
    That also happens when the person is very eager to talk about rust.
    - pjmlp 6y ago
      Talking to the wrong person I guess.
  - dpc_pw 6y ago
    > available tooling for doing deterministic resource management in GC languages Other than Python's `with` and alikes, wrapping in a closure, `defer`/`scope` (Go/D), what else is there? What am I missing? None of these work if the lifetime of a resource is not a simple "this scope".
    - pjmlp 6y ago
      Swift, D and Nim have RAII just like C++. Idris2 and now Haskell have linear types.
      - dpc_pw 6y ago

The problem with GC languages is that if the requirements (or data sizes) change and you run into performance problems related to GC later (e.g unacceptable pause times or high heap usage) then it is extremely hard to get out. Often the only choice is a complete rewrite of time-critical parts. There is a whole world of difference between a Rust program that does clone() occasionally to escape borrow checker strictness and a Java program that allocates 99% of stuff like crazy on GCed heap.

galacticdessert 6y ago
True, but I expect that only ~2% of programs to ever run into this problem
- pkolaczk 6y ago
  Then how come everything is so ridiculously slow these days, despite faster computers? I've ran into situations when displaying text on the screen was lagging - and that in several different programs, on various (modern) computers. Not saying GC was a problem there, but I guess this has something to do with the generally accepted culture of "only 2% of programs need high performance".
  - higerordermap 6y ago
    > Then how come everything is so ridiculously slow these days, despite faster computers? There is difference between GC overhead, VM overhead, interpreter overhead, and programmer not understanding basic concepts and doing stupid shit. Go is GC language and tools written in Go often approach C/C++ speeds, despite lacking an optimizer like LLVM and lack of some performance oriented features. Another example is OCaml.
  - sacado2 6y ago
    > Then how come everything is so ridiculously slow these days, despite faster computers? As you said, it's usually not a GC issue. Many of these ridiculously slow programs you talk about are written in C++.
    - pkolaczk 6y ago
      VSCode, Slack, Intellij Idea, some random JS on a website - indeed all C++ programs. I'm not arguing against GC, but more about the philosophy of saying that only 2% programs need a good level of performance. It starts from using GC instead of thinking about object ownerships (which btw often also results in harder to read, more convoluted code) and ends up launching an embedded web-browser to display a few images and a bunch of text and taking 1 GB of RAM. But it is not developer's RAM, so who cares? Summarising - using a GCed language instead of dropping a few occasional clone calls in the code is bad advice, unless the program is really a one-off fire and forget thing (but these are not 98% of software).
      - sacado2 6y ago
        The soft I have the most performance issues are Firefox, LibreOffice and Aperçu (don't know its original name, but it's called that way in French -- Apple's PDF viewer). All of them written in different, non-GCed languages. Usuall the problem is abuse of abstraction layers, more than abuse of a GC. And your javascript examples are a good example of that. GCed languages tend to abuse dynamic allocation and dynamic dispatch, even when it's not needed (there is more garbage to deal with). However I agree the idea only a few software need to run fast is bullcrap.
pizza234 6y ago
There was recent talk about the small kernel written in Go (I can't find the thread, though), which showed Go can have a performance profile good for systems programming. The considerations can be very complex though, e.g. what's the effort required for reaching this performance profile? is it consistent across all the types of project? etc.etc.
- pkolaczk 6y ago
  When Java came out, and later when C#/.NET arrived some people did the same with them. Nihil novi. It is often easier to get decent performance in tiny projects or micro-benchmarks, simply because you can spend so much more time on optimization vs all other tasks. That's probably why I often see Java benchmarks claiming close-to-C performance (only ~2x slower) levels, but I fail to see it in real big applications.
  - pjmlp 6y ago
    Yet I have replaced plenty of C++ systems with Java/.NET based ones, or hybrid solutions where C++ is left for a couple of high performance libraries (e.g. in COM), with the rest in some managed language. If the hard deadlines are still met, it doesn't matter that another solution is 50% faster when it takes 150% more money to develop and doesn't bring anything to the table (hard deadlines were accomplished). This is what people keep forgetting when arguing my language is faster than yours. What I care is about project costs, meeting deadlines and acceptance criteria.
    - Shorn 6y ago
      > What I care is about project costs, meeting deadlines and acceptance criteria. Are you sure you're on the right website? :D
    - pkolaczk 6y ago
      50% faster and 150% more expensive are numbers my experience doesn't agree with. First, programs coded in Rust are typically nowhere near 50% faster than the ones coded in managed languages - I observe 500% to 5000% differences. And it is not just faster but also uses an order of magnitude less memory. In cloud based software this translates to savings on TCO users of the software I write do care about. Second, as for 150% more development cost - this is also not my experience. There is some upfront cost related to learning a new language, but then later this pays off on maintenance and bug finding (lack of data races or relying on fragile runtime reflection are big ones). Plus Rust is more expressive than Java/C#/Go and many common programming problems are actually surprisingly faster to code. E.g serialization / deserialization of object graphs.
Const-me 6y ago
> and a Java program that allocates 99% of stuff like crazy on GCed heap Java is too extreme with GC, not all languages are like that. In .NET it's only moderately hard to avoid GC when you want to. It has value types, real stack, and other relevant features. Here's an example of non-trivial code written in that style for performance reasons: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
pjmlp 6y ago
1 - Not all GC languages are Java 2 - Those languages offer C++ like features for memory management if one bothers to actually learn to use them 3 - Java is also getting them via projects Panama and Valhalla So it is more a matter to actually bother to learn the tools one has at their disposition.
- pkolaczk 6y ago
  1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCed languages, in particular when we also take memory use and pauses into account, not just throughput. Throughput, low latency, low memory use - there are inherent tradeoffs between them and usually you can pick only one to tune for. 2 - Not really. The fact they allow to allocate/deallocate manually is not enough. Dealing with non-GCed memory in Java or C# is much more error-prone and less ergonomic than even in C++. E.g. no automatic reference counting nor RAII. 3 - It is 5 years in development now and as far as the specs goes value types will be limited to immutable objects only, so it is inefficient by design and it solves only half of the problem. Similarly high hopes were associated with escape analysis which turned out to be totally ineffective.
  - pjmlp 6y ago
    1 - Java is not the only game in town. 2 - automatic reference counting is slower than tracing GC. Strange to prefer something with less performance. RAII is possible in C# via IDispose (alongside Roslyn compiler errors for not using it properly) and FP patterns similar to -with in Common Lisp. 3 - It is a major engineering feat to design a feature that will work out of the box with 25 years old compiled jars without playing a Python 2 in the Java world. Naturally it takes its time to get right. Just like it took 10 years to get modules and concepts and they are still not available across all major C++ compilers. Good engineering takes time.
    - pkolaczk 6y ago
      1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects. 2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient. 3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.

dpc_pw 6y ago

Yeah, but dealing with debugging leaking resources (because memory is just one of many resources that a program will use, and GCs don't help with most of them) sucks. https://ruudvanasseldonk.com/2015/10/06/neither-necessary-nor-sufficient https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... Ownership model seems hard for people to internalize, but once learned feels very natural, leads to programs that are better structured and frees programmer from "manually managing resources".

pjmlp 6y ago
That is what happens when one doesn't learn the available tooling for doing deterministic resource management in GC languages.
- higerordermap 6y ago
  That also happens when the person is very eager to talk about rust.
  - pjmlp 6y ago
    Talking to the wrong person I guess.
- dpc_pw 6y ago
  > available tooling for doing deterministic resource management in GC languages Other than Python's `with` and alikes, wrapping in a closure, `defer`/`scope` (Go/D), what else is there? What am I missing? None of these work if the lifetime of a resource is not a simple "this scope".
  - pjmlp 6y ago
    Swift, D and Nim have RAII just like C++. Idris2 and now Haskell have linear types.
    - dpc_pw 6y ago