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?
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.
We've not switched away.
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.
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.
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...
[^2]: https://www.researchgate.net/publication/355862079_A_Review_...
[^3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
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.
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.
https://www.reddit.com/r/Common_Lisp/comments/riedio/quite_a...
(That comparison no longer seems to show Lisp?)
Unoptmized Java looks pretty similar to C/C++, so optimized Java looking similar doesn't surprise me.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
idiomatic SBCL ?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> 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
I guess we are interested in real life application performance, not in low-level benchmarks or benchmark games.
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.
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.
I agree that it's not 1:1 from CPU to equipment.
A human who spends his day writing code is going to consume (at worst) the exact same amount of food as if he spent only half his day coding and the other half on something else. He might even consume less food while coding, if his non-coding activity is something physically intensive (i.e. burns more calories). I don't really see how the implication (that saving human time saves energy too) can possibly be true.
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.
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.
Here you say “it comes at a cost” twice, but you don’t say what the cost is! Or am I missing something?
You can actually tell the JVM to not JIT... try that and see just how slow your code runs... it may give you an idea of how much it costs in terms of energy as well if you're able to measure that (I don't know how much that cost would look like, to be honest, I can only imagine it's a significant proportion of the total).
That is the beauty of languages with multiple implementations.
Also lets not forget the influence of Lisp/Scheme people like Guy Steele on how Java turned out.
"We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."
Full Lisp would have been better, but apparently Lisps in desguise like Dylan and Julia, are the best mainstream is willing to take on.
I don't think it's even close. Benchmark game is one (biased) reference. And it's even worse because optimized Java is not canonical Java. Canonical C++ is pretty fast.
I agree.
1. Benchmarks tend to do one thing, then repeat that one thing 25000 times. Non-server programs don't do that[1] so you don't get to amortise the time spent on JITting a code snippet across 25000 executions.
2. The runtime basically requires exclusive use of a core for short periods (GC, JIT). If you're running on a system that costs per core, you're using (worst case scenario) an extra core for each Java program. The benchmarks happily give multiple cores even to sequential (non-parallel) benchmarks.
[1] Even many server programs don't do that.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
2. The benchmarks game happily gives multiple cores and shows that "cpu secs" measurement:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
2) "one (biased) reference" is simply name calling.
3) What specifically are you saying is "biased" about these measurements?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.