6 ms·

If only it were that simple! If such a gain could be made by simply switching your programming language to one that is "more efficient" (in power consumption te

If only it were that simple! If such a gain could be made by simply switching your programming language to one that is "more efficient" (in power consumption terms) we would see Google writing everything in C++, instead of the mix of Go, Python, Java, PHP, etc. that comprises most of their software stacks! But no, that's not how it works at all. Nearly half (about 40%)[^1] of datacenter's total power draw on average is from cooling, which is usually shared across every server in the datacenter. Next, about 30%[^2] of the average server's power draw comes from its CPU (this obviously varies, even at different times on the same server), most servers sit at about 50% utilization on average. So already we're looking at 50% of 30% of 60% = 9% total of energy consumption going to the CPU with very rough, over-estimations. Now Clojure makes up about 1.25% of code, ish[^3]. Let's round that up to 1.5% to be generous. So a reeeeally rough estimate has Clojure code taking up 0.135% of total datacenter power usage globally assuming averages for pretty much everything. I had trouble finding benchmarks for Clojure vs. Common Lisp, but Clojure is basically just Java at runtime, so this[^3] will do. Benchmarks are kinda silly, but we're talking about really average performance. The benchmarks I could find had Java beating SBCL on most benchmarks, but let's say you stand to gain a generous 20% efficiency by using SBCL over Java. That leaves you at a 0.027% gain in efficiency with a lot of generous rounding and assumptions. Now, of course most code is not CPU constrained... you get the idea. The efficiency gains are not much at all. [^1]: https://davidmytton.blog/how-much-energy-do-data-centers-use/ https://davidmytton.blog/how-much-energy-do-data-centers-use... [^2]: https://www.researchgate.net/publication/355862079_A_Review_of_Data_Centers_Energy_Consumption_And_Reliability_Modeling https://www.researchgate.net/publication/355862079_A_Review_... [^3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lisp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

refset 3y ago
Assuming current multi-tenant infrastructure trends continue, over-provisioning of RAM and slow start up times are likely the much bigger efficiency issues.
brabel 3y ago
Everything you said is a waste of your time. I am not talking about replacing Clojure with Common Lisp. Why did you even come up with that strawman?? The point is that if everyone used more efficient languages, a very large reduction in energy costs could be expected (not just in data centers by the way, every device takes power, and the ridiculously inefficient apps people are running probably cost a lot of energy). It's the same argument as to why you should have a ecofriendly house or whatever: you try to do your part and hope the others will do too. You may be cynic enough to think that makes no difference, but you're just blind to your own unjustified prejudices.
- medo-bear 3y ago
  Precisely. If you were to divide languages as high level vs low level, or garabge collected vs manual mem management, I feel that SBCL would be on top in terms of energy efficiency in both the formers.
  - packetlost 3y ago
    I think there's some Schemes that could give SBCL a run for it's money, but I have no doubt it would be a very strong contender. I hope this doesn't come across as bashing SBCL, that is not my intent at all.
- packetlost 3y ago
  > I am not talking about replacing Clojure with Common Lisp. Why did you even come up with that strawman?? Because that's what I was talking about in the first place? I was responding directly to the text under the linked video making an ecological appeal to using SBCL over Clojure. Both are very efficient languages, so that particular appeal seems silly. > The point is that if everyone used more efficient languages, a very large reduction in energy costs could be expected (not just in data centers by the way, every device takes power, and the ridiculously inefficient apps people are running probably cost a lot of energy). Sure, I agree with that. But that's not what was being talked about. If you have data or sources you can share that show studies that model how much energy could be saved, I'd love to see them. > It's the same argument as to why you should have a ecofriendly house or whatever: you try to do your part and hope the others will do too. So don't write load bearing applications in Python. But most code is not load bearing or even executed that often. The energy usage of SBCL vs Clojure is like making the decision to unplug your toaster when you're not using it, and it's not even clear which is more efficient. > You may be cynic enough to think that makes no difference, but you're just blind to your own unjustified prejudices. I looked at the data and came to a conclusion. I was talking about choosing one pretty efficient language over another, you were talking about something else. > Everything you said is a waste of your time. You have no right to tell me what is a waste of my time. I found it quite interesting, I just wish we could've had a conversation made in good faith instead of whatever this was.
medo-bear 3y ago
> I had trouble finding benchmarks for Clojure vs. Common Lisp, but Clojure is basically just Java at runtime, so this[^3] will do. If only it were that simple ! Clojure has no provision for compile time type checks, unlike Common Lisp running in SBCL. On the other hand Common Lisp running on JVM (see Armed Bear Common Lisp) could theoretically achieve those results because, but if we are including calls to host systems then Embedable CL could better it since it runs on top of C. The optimized Java in the benchmarks you quote in fact looks more like C or Cpp code. Im not informed enough to make a judgement if idiomatic Java even looks like that. Idiomatic SBCL (as opposed to just idiomatic Common Lisp) code does look like the versions achieving best results, because people often use SBCL for compiler optimization > The benchmarks I could find had Java beating SBCL on most benchmarks, Most of the benchmarks are actually quite similar - ie within the margin of error. Most of the times when Java did beat SBCL by a somewhat more significant margin I noticed that Java's submission used multi-threading whereas that particular submission for SBCL didn't, so the difference isn't so much as Java vs SBCL, but algorithm a vs algorithm b. Also, as far as I can remember, it is worth mentioning that there was some controversy over some SBCL submissions. One of the submitters had solutions which saw SBCL beating C, Cpp, Zig, and Rust on some of the numerically intensive benchmarks, however their submissions were rejected later for using a SIMD library which at the time was not yet part of SBCL, but now it is.
- medo-bear 3y ago
  See this for reference on SBCL beating C, Fortran, Rust, etc. https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/ https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...
  - igouy 3y ago
    SIMD "beating C, Fortran, Rust, etc." :-)
    - medo-bear 3y ago
      SIMD call in SBCL is explicit, which I personally like. In NumPy, as a counter example, it just happens. It is just a method of talking to the processor to take advantage of parallelization. Java will also have it soon: https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html https://download.java.net/java/early_access/loom/docs/api/jd...
lispm 3y ago
> Benchmarks are kinda silly, but we're talking about really average performance. I guess we are interested in real life application performance, not in low-level benchmarks or benchmark games.
- igouy 3y ago
  Please show the measurements for that real life application performance.
sokoloff 3y ago
Note that cooling is not independent of CPU power draw. (The more CPU power draw, the more heat is released that needs to be removed by cooling. The more power a CPU draws, the more heat is dissipated as waste in the power supply. If I'm following your math estimates, you're treating cooling and non-CPU as if was fixed.)
- packetlost 3y ago
  I'm using averages for both which should generally account for variations over time, but at any given moment the total percentage would change. I'm not educated enough on the topic to know how much though. My guess is there's a large baseline energy cost to running a chiller system, while a modern servers have a fairly low idle power draw (see some of my sources, it's pretty interesting how far we've come in this department).
  - sokoloff 3y ago
    Case 1a: A DC is using 60kW for equipment and 40kW for cooling Case 1b: Code efficiency of 5% improves the equipment to 57kW for equipment; I'd expect cooling to drop to around 38kW rather than remain at 40kW to remove that 57kW of heat load. If that's the case, a 5% improvement in equipment power draw is a 5% improvement in overall DC power draw, not a 3% (5% improvement on 60% of it).
    - packetlost 3y ago
      A code efficiency improvement of 5% (represented as a 5% improvement in CPU utilization) does not equate to a 5% improvement in equipment power draw though. You at least need to factor in the percentage of an individual server's power draw that goes to the CPU, which is about 30% (again, on average). So a 5% equipment power draw improvement would need at least a 15% code efficiency improvement (0.05 / 0.3 = 0.1666), assuming you're CPU bound on whatever your code is doing. I factored in the average CPU load (50%) to account for this, but it's heavily application dependent.
      - 3y ago

refset 3y ago

Assuming current multi-tenant infrastructure trends continue, over-provisioning of RAM and slow start up times are likely the much bigger efficiency issues.

brabel 3y ago

Everything you said is a waste of your time. I am not talking about replacing Clojure with Common Lisp. Why did you even come up with that strawman?? The point is that if everyone used more efficient languages, a very large reduction in energy costs could be expected (not just in data centers by the way, every device takes power, and the ridiculously inefficient apps people are running probably cost a lot of energy). It's the same argument as to why you should have a ecofriendly house or whatever: you try to do your part and hope the others will do too. You may be cynic enough to think that makes no difference, but you're just blind to your own unjustified prejudices.

medo-bear 3y ago
Precisely. If you were to divide languages as high level vs low level, or garabge collected vs manual mem management, I feel that SBCL would be on top in terms of energy efficiency in both the formers.
- packetlost 3y ago
  I think there's some Schemes that could give SBCL a run for it's money, but I have no doubt it would be a very strong contender. I hope this doesn't come across as bashing SBCL, that is not my intent at all.
packetlost 3y ago
> I am not talking about replacing Clojure with Common Lisp. Why did you even come up with that strawman?? Because that's what I was talking about in the first place? I was responding directly to the text under the linked video making an ecological appeal to using SBCL over Clojure. Both are very efficient languages, so that particular appeal seems silly. > The point is that if everyone used more efficient languages, a very large reduction in energy costs could be expected (not just in data centers by the way, every device takes power, and the ridiculously inefficient apps people are running probably cost a lot of energy). Sure, I agree with that. But that's not what was being talked about. If you have data or sources you can share that show studies that model how much energy could be saved, I'd love to see them. > It's the same argument as to why you should have a ecofriendly house or whatever: you try to do your part and hope the others will do too. So don't write load bearing applications in Python. But most code is not load bearing or even executed that often. The energy usage of SBCL vs Clojure is like making the decision to unplug your toaster when you're not using it, and it's not even clear which is more efficient. > You may be cynic enough to think that makes no difference, but you're just blind to your own unjustified prejudices. I looked at the data and came to a conclusion. I was talking about choosing one pretty efficient language over another, you were talking about something else. > Everything you said is a waste of your time. You have no right to tell me what is a waste of my time. I found it quite interesting, I just wish we could've had a conversation made in good faith instead of whatever this was.

medo-bear 3y ago

> I had trouble finding benchmarks for Clojure vs. Common Lisp, but Clojure is basically just Java at runtime, so this[^3] will do. If only it were that simple ! Clojure has no provision for compile time type checks, unlike Common Lisp running in SBCL. On the other hand Common Lisp running on JVM (see Armed Bear Common Lisp) could theoretically achieve those results because, but if we are including calls to host systems then Embedable CL could better it since it runs on top of C. The optimized Java in the benchmarks you quote in fact looks more like C or Cpp code. Im not informed enough to make a judgement if idiomatic Java even looks like that. Idiomatic SBCL (as opposed to just idiomatic Common Lisp) code does look like the versions achieving best results, because people often use SBCL for compiler optimization > The benchmarks I could find had Java beating SBCL on most benchmarks, Most of the benchmarks are actually quite similar - ie within the margin of error. Most of the times when Java did beat SBCL by a somewhat more significant margin I noticed that Java's submission used multi-threading whereas that particular submission for SBCL didn't, so the difference isn't so much as Java vs SBCL, but algorithm a vs algorithm b. Also, as far as I can remember, it is worth mentioning that there was some controversy over some SBCL submissions. One of the submitters had solutions which saw SBCL beating C, Cpp, Zig, and Rust on some of the numerically intensive benchmarks, however their submissions were rejected later for using a SIMD library which at the time was not yet part of SBCL, but now it is.

medo-bear 3y ago
See this for reference on SBCL beating C, Fortran, Rust, etc. https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_amazing_sbcl_benchmark_speed_with_sbsimd/ https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...
- igouy 3y ago
  SIMD "beating C, Fortran, Rust, etc." :-)
  - medo-bear 3y ago
    SIMD call in SBCL is explicit, which I personally like. In NumPy, as a counter example, it just happens. It is just a method of talking to the processor to take advantage of parallelization. Java will also have it soon: https://download.java.net/java/early_access/loom/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html https://download.java.net/java/early_access/loom/docs/api/jd...

lispm 3y ago

> Benchmarks are kinda silly, but we're talking about really average performance. I guess we are interested in real life application performance, not in low-level benchmarks or benchmark games.

igouy 3y ago
Please show the measurements for that real life application performance.

sokoloff 3y ago

Note that cooling is not independent of CPU power draw. (The more CPU power draw, the more heat is released that needs to be removed by cooling. The more power a CPU draws, the more heat is dissipated as waste in the power supply. If I'm following your math estimates, you're treating cooling and non-CPU as if was fixed.)

packetlost 3y ago
I'm using averages for both which should generally account for variations over time, but at any given moment the total percentage would change. I'm not educated enough on the topic to know how much though. My guess is there's a large baseline energy cost to running a chiller system, while a modern servers have a fairly low idle power draw (see some of my sources, it's pretty interesting how far we've come in this department).
- sokoloff 3y ago
  Case 1a: A DC is using 60kW for equipment and 40kW for cooling Case 1b: Code efficiency of 5% improves the equipment to 57kW for equipment; I'd expect cooling to drop to around 38kW rather than remain at 40kW to remove that 57kW of heat load. If that's the case, a 5% improvement in equipment power draw is a 5% improvement in overall DC power draw, not a 3% (5% improvement on 60% of it).
  - packetlost 3y ago
    A code efficiency improvement of 5% (represented as a 5% improvement in CPU utilization) does not equate to a 5% improvement in equipment power draw though. You at least need to factor in the percentage of an individual server's power draw that goes to the CPU, which is about 30% (again, on average). So a 5% equipment power draw improvement would need at least a 15% code efficiency improvement (0.05 / 0.3 = 0.1666), assuming you're CPU bound on whatever your code is doing. I factored in the average CPU load (50%) to account for this, but it's heavily application dependent.
    - 3y ago