The actual benchmark: <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html" rel="nofollow noreferrer">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a><p>EDIT: fwiw, classic Fortran is twice as fast as java :P As is Rust, but that's less funny to me
One should always be skeptical of these sorts of benchmarks, especially against Java, and I say this as primarily a Java developer.<p>Well optimized Java is very lean and can be incredibly performant, but the median modern Java app is an obese cronenberg made out of gigabytes of SpringBoot dependencies. That's not particularly fast; and well optimized python will run circles around it.
Amazing. I have seen this list popping up in my LinkedIn feed for more than a year already and it keeps coming back.<p>While any benchmark is of course interesting when considered on its own, the conclusions that people draw from this list tend to be complete nonsense: "Python is bad for the environment", "we should switch to language xxx to combat global warming" etc.<p>First of all, especially for the slower languages in this list, it is extremely rare that application code written in that language is the bottleneck of a performance critical application. Typically the bottlenecks of every day applications tend to be databases and network. If you need heavy number crunching, there tend to be excellent libraries available written in lower level languages, such as e.g. for Python NumPy and Pandas.
If you are really concerned about the energy footprint of your application, you're probably better off with optimizing these components. Or optimizing the higher level architecture of your own application, which tends to be a lot easier in a higher level langguage.<p>Second, coding in a faster language is often not economically possible. Programming the same application in C will normally take much longer than coding it in Python. Developing time costs money and can also mean loss of opportunity.<p>And finally, the 'greenest' language of them all was not even included in this list: assembly. I guess the author must have realized in the back of his head that such a difficult language wasn't a realistic option for switching to a more energy efficient solution. He/she just failed to realize that this argument applies to many other languages as well.
Just write in Rust, it's easier to build good software than either of these languages (yea, yea, do you data analyst stuff in python until you start using POLARS). At this point it's a far superior ecosystem from a developer experience point of view and the fact it's going to get you as close to efficient as possible without you thinking too far into it is a welcome side effect.<p>Using VScode with the Sqlx package I get compile time errors on my SQL - as a result I haven't ran a binary with a typo from my SQL in the last 12 months.
This is why I'm learning Rust: C# gives fast development speeds than Python with decent performance. Python and Go for when their native libraries smoke C# and now Rust for performance or low level.
The research: "Energy Efficiency across Programming Languages" SLE’17, October 23–24, 2017<p>PDF: <a href="https://repositorio.inesctec.pt/bitstream/123456789/5492/1/P-00N-4CX.pdf" rel="nofollow noreferrer">https://repositorio.inesctec.pt/bitstream/123456789/5492/1/P...</a><p>The human mental energy required for programming, unfortunately, has not been measured. ;-)
While Java's compiler or JIT is probably one of the most optimized softwares in existence, how do we measure, what overhead the language nudges the programmers to build? I am thinking of AbstractProviderFactoryProxy and similar. Or that for a very long time it forced you (or still does to a degree) to put everything into classes, breeding 1 or 2 generations of programmers, who see a noun and jump to making a class and then subsequently initializing the class to be able to call a method, which actually would only need to be a standalone function.<p>It probably does not balance the 38x, and probably the JIT optimizes parts of it away, but surely the cost is far from zero.<p>Also what about the computational resources it takes to just run a JVM, compared to running a Python program?
Is Python's "values don't change, they get replaced by new ones stored elsewhere" approach what makes it slow?<p>I would like to see some micro-benchmarks which pin down the bottlenecks.<p>For example, this minimal benchmark with one variable and a few control structures:<p><pre><code> x=0
for i in range(int(10e6)):
if i<50: x=x+1
print (x)
</code></pre>
Runs 5 times slower here than the same in PHP:<p><pre><code> $x=0;
for ($i=0; $i<10e6; $i++)
if ($i<50) $x++;
echo "$x\n";
</code></pre>
Tested with:<p><pre><code> time python3 loop.py
</code></pre>
Which gives me 0.31s<p>And:<p><pre><code> time php loop.php
</code></pre>
Which gives me 0.06s<p>A factor of five seems to be roughly the average when comparing Python to PHP for a bunch of different code constructs I tried.
There is a more recent paper by Pereira et al. from 2021 (see <a href="https://www.sciencedirect.com/science/article/abs/pii/S0167642321000022" rel="nofollow noreferrer">https://www.sciencedirect.com/science/article/abs/pii/S01676...</a> ); if geomean is used (which is the correct method) instead of what they apparently do in the paper, there is yet a different order (see <a href="http://software.rochus-keller.ch/Ranking_programming_languages_by_energy_efficiency_evaluation.ods" rel="nofollow noreferrer">http://software.rochus-keller.ch/Ranking_programming_languag...</a>).
C++ uses 34% more energy than C?<p>I thought C code was generally also valid C++ code and so you really should be able to get the same performance and energy consumption. Very odd.