6 ms·

> our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also maki

> our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment. Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others?

packetlost 3y ago
Presumably execution efficiency, but tbh I don't think I've ever seen any compelling numbers. The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs.
- behnamoh 3y ago
  > Presumably execution efficiency, ... Yeah, in that case Assembly/C is the greenest language but should we switch to them? > The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs. I'm not sure I follow what you mean here.
  - kazinator 3y ago
    > Yeah, in that case Assembly/C is the greenest language but should we switch to them? We've not switched away.
  - packetlost 3y ago
    The electricity gains to be had are likely very small. Minuscule, even. Humans are not ecologically neutral, we consume food that has environmental impacts. Depending on diet and other lifestyle (physical activity, for example) factor into a humans ecological impact. By increasing the amount of time a human spends on something, you proportionally increase the ecological impact of the task the human is performing. The idea is that duplicating or redoing work may be more costly in aggregate, but absolute terms to the environment than the small offset in energy to be had by making the code more efficient. The point isn't about the absolute numbers, it's just trying to illustrate that the numbers are so small that it might as well be a rounding error unless you're talking about industry or society-levels of impact, which Clojure does not really have.
    - brabel 3y ago
      > The electricity gains to be had are likely very small. Minuscule, even. That's just wrong. Electricity used by data centers today add up to the whole consumption of a largish country. If you can save even just 5% of that, it's an enormous difference. Companies like Google and Netflix spend millions to save much less than that in computing.
      - packetlost 3y ago
        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/...
graemep 3y ago
> Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others? It means more energy efficient. May be we should, at least for some things. For code that runs a very large number of times the energy savings will add up. Data centres do use a lot of energy. So do client machines in aggregate.
nsm 3y ago
(I only read the pdf outline) As someone who is neither a Common Lisp nor a JVM programmer, I’m genuinely curious to hear from experts whether the old trope of “JVM is slow and bloated” is even remotely true any more. Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? As an aside, even the trope about us running out of energy, or energy usage directly corresponding to planetary destruction is becoming less and less true. With solar PVs and the sun, we truly do have a shot at a future with limitless energy and resources.
- brabel 3y ago
  > Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages. While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster. For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java. > How much do other platform developers leave on the table by ignoring the JVM these days? Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.
agumonkey 3y ago
I would draw parallels with the trend to use lower level languages. People didn't care about server costs for a while until they did, and now you see articles about how rewriting server side logic in rust cut the cost by 20. Maybe in the future, energy costs will also end up as a tangible constraint.

packetlost 3y ago

Presumably execution efficiency, but tbh I don't think I've ever seen any compelling numbers. The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs.

behnamoh 3y ago
> Presumably execution efficiency, ... Yeah, in that case Assembly/C is the greenest language but should we switch to them? > The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs. I'm not sure I follow what you mean here.
- kazinator 3y ago
  > Yeah, in that case Assembly/C is the greenest language but should we switch to them? We've not switched away.
- packetlost 3y ago
  The electricity gains to be had are likely very small. Minuscule, even. Humans are not ecologically neutral, we consume food that has environmental impacts. Depending on diet and other lifestyle (physical activity, for example) factor into a humans ecological impact. By increasing the amount of time a human spends on something, you proportionally increase the ecological impact of the task the human is performing. The idea is that duplicating or redoing work may be more costly in aggregate, but absolute terms to the environment than the small offset in energy to be had by making the code more efficient. The point isn't about the absolute numbers, it's just trying to illustrate that the numbers are so small that it might as well be a rounding error unless you're talking about industry or society-levels of impact, which Clojure does not really have.
  - brabel 3y ago
    > The electricity gains to be had are likely very small. Minuscule, even. That's just wrong. Electricity used by data centers today add up to the whole consumption of a largish country. If you can save even just 5% of that, it's an enormous difference. Companies like Google and Netflix spend millions to save much less than that in computing.
    - packetlost 3y ago
      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/...

graemep 3y ago

> Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others? It means more energy efficient. May be we should, at least for some things. For code that runs a very large number of times the energy savings will add up. Data centres do use a lot of energy. So do client machines in aggregate.

nsm 3y ago

(I only read the pdf outline) As someone who is neither a Common Lisp nor a JVM programmer, I’m genuinely curious to hear from experts whether the old trope of “JVM is slow and bloated” is even remotely true any more. Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? As an aside, even the trope about us running out of energy, or energy usage directly corresponding to planetary destruction is becoming less and less true. With solar PVs and the sun, we truly do have a shot at a future with limitless energy and resources.

brabel 3y ago
> Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days? I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages. While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you. Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster. For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java. > How much do other platform developers leave on the table by ignoring the JVM these days? Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.

agumonkey 3y ago

I would draw parallels with the trend to use lower level languages. People didn't care about server costs for a while until they did, and now you see articles about how rewriting server side logic in rust cut the cost by 20. Maybe in the future, energy costs will also end up as a tangible constraint.