6 ms·

From an environmental perspective, I wonder how much energy is consumed (and emissions generated) for garbage collection and interpreters. These things exist t

From an environmental perspective, I wonder how much energy is consumed (and emissions generated) for garbage collection and interpreters. These things exist to make programming easier but are then duplicated across thousands of servers. If everyone used some compiled language that was just a little simpler, a little safer, had just a little better memory management/tooling, or like here, had better hardware support, how much would that reduce global emissions caused by data centers?

Wowfunhappy 7y ago
> These things exist to make programming easier but are then duplicated across thousands of servers. I think about this kind of thing, but more in regard to Electron et al. Garbage collection, by contrast, seems like a more worthwhile trade-off, because there's a great argument to be made that garbage collection isn't just easier for programmers but safer for users, in terms of security. Since it mostly removes an major class of vulnerabilities.
exabrial 7y ago
So... Rust, basically
- CoolGuySteve 7y ago
  I didn't want to start a language war but yeah, basically. Swift and/or ObjC + ARC seem to be attacking the same problems on the embedded side out of necessity. It's too bad Apple is so apathetic about Linux servers. Even just replacing Python with Go might save a massive amount of KWh consumed.
  - Scramblejams 7y ago
    I'm more interested in optimizing the client side, at least where the web is concerned. I keep wondering when Google is going to start generating energy ratings for the top few thousand sites on the web. It would shame the low performers into producing front ends that are no longer glacial. I was loading wunderground.com's 10 day forecast for the umpteenth time lately and reflecting on how horribly slow and inefficient it is... Surely website energy ratings must be in the works somewhere, right?
    - dimatura 7y ago
      I'd be surprised if gmail.com wasn't one of the worst performers on this hypothetical list.
- legulere 7y ago
  There’s actually a nice article about improving performance in rust with a bump allocator, which is conceptually similar to garbage collection: https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtual-doms-with-rust-and-wasm/ https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtua...
  - Jweb_Guru 7y ago
    It's only conceptually similar to the "bump allocation in the nursery" part of garbage collection, IMO, as it skips the whole tracing part that makes RC, GC, and even RAII substantially less efficient than stack allocation. When people talk about GC having great performance compared to manual memory management they are very often only considering objects that die before the first major collection.
p_l 7y ago
By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount. Exact results depend on what metrics are you targeting - a stop the world pause can result in very efficient (in total time and power use) system, but one that has problematic latencies. A metronome style approach will have lower efficiencies but timings more predictable than reasonably optimized malloc()/free()
- CoolGuySteve 7y ago
  > By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount. This is such an extraordinary claim that I'm going to need data before I believe it.
aidenn0 7y ago
Garbage collection is mostly an issue of latency, not overall CPU usage. malloc and free are not O(1) anymore than garbage collection is. [edit] I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.
- CoolGuySteve 7y ago
  A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases. https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l...
  - aidenn0 7y ago
    The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code. Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C). Highly dynamic languages are slower not because the GC is slower, but because the GC encourages (fails to discourage) a lot of allocations. If you were to write Haskell or Ocaml like-code in C you would put a lot of stress on the malloc/free implementations. Those have gotten a lot better in the past 20 years or so (web browsers in particular tend to stress malloc/free a lot as well), but it's still more of a question as to "which malloc best fits my workload" rather than a "one true malloc" which is a factor seen with garbage collectors as well.
    - flukus 7y ago
      You can argue over implementation details, it's what programmers do best, but at least it's data and you haven't presented any to support your claims. Shouldn't it be relatively simple to implement malloc/free as a wrapper around a garbage collector and compare like with like? Maybe we'd need some more annotations to cover copying, referencing, etc. For that matter if GC was faster I'm sure we'd have seen this in a number of large C/C++/rust programs already
flukus 7y ago
Here's a benchmark that includes an energy comparison: https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l... . It's interesting that speed does not directly correlate with energy consumption and the the energy consumption of functional languages was much higher than imperative.
- CoolGuySteve 7y ago
  Not sure why you’re getting downvoted when you’re the only response with actual data whereas the other responses are defending clearly less efficient practices with gobbledegook about O(1) memory algorithms and whatnot. I think most of it is coming from overly defensive users of GC languages . Sometime the world you want is not the world that exists.
  - xfer 7y ago
    > Specifically, they used 10 problems from the Computer Language Benchmarks Game Yeah some "actual data" right there.
    - CoolGuySteve 7y ago
      If you have a better Rosetta Stone of computer languages I’d like to see it.
      - xfer 7y ago
        well i am not using questionable data and calling it as an evidence of my beliefs.
- Symmetry 7y ago
  That's more a measure of indirection than of garbage collection.
  - flukus 7y ago
Simple_Guy 7y ago
If you want to reduce emission it is more effective to look at big things like car usage and space heating rather than interpreter use.
marcosdumay 7y ago
There is a much more pressing case for migrating JS, Python and Ruby codebases to Java, .Net, Haskell, or Go than for abandoning automatic memory management and migrating those to Rust or C. And even that more pressing case isn't pressing enough most of the time. Anyway, your ideals of simpler, safer, better tooling, and better hardware support are clearly in conflict with each other.

Wowfunhappy 7y ago

> These things exist to make programming easier but are then duplicated across thousands of servers. I think about this kind of thing, but more in regard to Electron et al. Garbage collection, by contrast, seems like a more worthwhile trade-off, because there's a great argument to be made that garbage collection isn't just easier for programmers but safer for users, in terms of security. Since it mostly removes an major class of vulnerabilities.

exabrial 7y ago

So... Rust, basically

CoolGuySteve 7y ago
I didn't want to start a language war but yeah, basically. Swift and/or ObjC + ARC seem to be attacking the same problems on the embedded side out of necessity. It's too bad Apple is so apathetic about Linux servers. Even just replacing Python with Go might save a massive amount of KWh consumed.
- Scramblejams 7y ago
  I'm more interested in optimizing the client side, at least where the web is concerned. I keep wondering when Google is going to start generating energy ratings for the top few thousand sites on the web. It would shame the low performers into producing front ends that are no longer glacial. I was loading wunderground.com's 10 day forecast for the umpteenth time lately and reflecting on how horribly slow and inefficient it is... Surely website energy ratings must be in the works somewhere, right?
  - dimatura 7y ago
    I'd be surprised if gmail.com wasn't one of the worst performers on this hypothetical list.
legulere 7y ago
There’s actually a nice article about improving performance in rust with a bump allocator, which is conceptually similar to garbage collection: https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtual-doms-with-rust-and-wasm/ https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtua...
- Jweb_Guru 7y ago
  It's only conceptually similar to the "bump allocation in the nursery" part of garbage collection, IMO, as it skips the whole tracing part that makes RC, GC, and even RAII substantially less efficient than stack allocation. When people talk about GC having great performance compared to manual memory management they are very often only considering objects that die before the first major collection.

p_l 7y ago

By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount. Exact results depend on what metrics are you targeting - a stop the world pause can result in very efficient (in total time and power use) system, but one that has problematic latencies. A metronome style approach will have lower efficiencies but timings more predictable than reasonably optimized malloc()/free()

CoolGuySteve 7y ago
> By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount. This is such an extraordinary claim that I'm going to need data before I believe it.

aidenn0 7y ago

Garbage collection is mostly an issue of latency, not overall CPU usage. malloc and free are not O(1) anymore than garbage collection is. [edit] I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.

CoolGuySteve 7y ago
A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases. https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l...
- aidenn0 7y ago
  The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code. Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C). Highly dynamic languages are slower not because the GC is slower, but because the GC encourages (fails to discourage) a lot of allocations. If you were to write Haskell or Ocaml like-code in C you would put a lot of stress on the malloc/free implementations. Those have gotten a lot better in the past 20 years or so (web browsers in particular tend to stress malloc/free a lot as well), but it's still more of a question as to "which malloc best fits my workload" rather than a "one true malloc" which is a factor seen with garbage collectors as well.
  - flukus 7y ago
    You can argue over implementation details, it's what programmers do best, but at least it's data and you haven't presented any to support your claims. Shouldn't it be relatively simple to implement malloc/free as a wrapper around a garbage collector and compare like with like? Maybe we'd need some more annotations to cover copying, referencing, etc. For that matter if GC was faster I'm sure we'd have seen this in a number of large C/C++/rust programs already

flukus 7y ago

Here's a benchmark that includes an energy comparison: https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l... . It's interesting that speed does not directly correlate with energy consumption and the the energy consumption of functional languages was much higher than imperative.

CoolGuySteve 7y ago
Not sure why you’re getting downvoted when you’re the only response with actual data whereas the other responses are defending clearly less efficient practices with gobbledegook about O(1) memory algorithms and whatnot. I think most of it is coming from overly defensive users of GC languages . Sometime the world you want is not the world that exists.
- xfer 7y ago
  > Specifically, they used 10 problems from the Computer Language Benchmarks Game Yeah some "actual data" right there.
  - CoolGuySteve 7y ago
    If you have a better Rosetta Stone of computer languages I’d like to see it.
    - xfer 7y ago
      well i am not using questionable data and calling it as an evidence of my beliefs.
Symmetry 7y ago
That's more a measure of indirection than of garbage collection.
- flukus 7y ago

Simple_Guy 7y ago

If you want to reduce emission it is more effective to look at big things like car usage and space heating rather than interpreter use.

marcosdumay 7y ago

There is a much more pressing case for migrating JS, Python and Ruby codebases to Java, .Net, Haskell, or Go than for abandoning automatic memory management and migrating those to Rust or C. And even that more pressing case isn't pressing enough most of the time. Anyway, your ideals of simpler, safer, better tooling, and better hardware support are clearly in conflict with each other.