This study is a bit silly, I had to check whether it was an April Fool's joke. The chipset running the instructions is going to have a far higher impact on energy usage than the language compiling those instructions. For instance, switching to ASICs or even FPGAs that are optimized to handle certain types of computations. Just look at datacenters or mobile devices. Sure, optimizations are made to runtime environments…
Which Programming Languages Use the Least Electricity? (2018)
101–110 of 267 posts
Re: Which Programming Languages Use the Least Electricity? (2018)
#102Couple points (I've worked on app servers): 1- This is exactly how we should all be thinking about server engineering moving forward, as we aim to drastically reduce carbon footprint within 11 years. Efficiencies at the language level are one of biggest bangs for buck here. Just by redeploying, you can reduce energy consumption by perhaps double digits. Imagine how hard that is to do at the hardware or energy farm le…
Re: Which Programming Languages Use the Least Electricity? (2018)
#103Re: Which Programming Languages Use the Least Electricity? (2018)
#104Are they counting the electricity used to heat the pizzas that feed the programmers?
Re: Which Programming Languages Use the Least Electricity? (2018)
#105Earlier quoted context omitted.
Maybe you can switch it out :) https://webassembly.org/
It wouldn't be switching out. You'd just be running WASM.
Re: Which Programming Languages Use the Least Electricity? (2018)
#106Interesting results, but I think the farther you go down the list the more the fact that you're using the Computer Language Benchmark Game affects what you're seeing, as not all languages get the same attention. For example, Javascript and Typescript. Theoretically, I would assume those to be very close, since one compiles to the other. And for memory usage, they are very close. But for running time, Typescript is an…
That’s an interesting discrepancy, I might have had the same gut reaction. But you’re using that assumption to cast slippery-slope doubt on the whole project without knowing anything specific. It’s possible you’re right, but maybe find out which algorithms are being used first? Perhaps there is a reason that TypeScript actually is an order of magnitude slower than JavaScript. The Benchmark Game project was specifical…
The issue is that one of the metrics in the suite is lines of code, so people write fantastically obscure and concise functional programs in Perl when the imperative one would be 2x the LOC, but much, much faster.
(This is from a spot check years ago. Maybe they’ve fixed this somehow).
Re: Which Programming Languages Use the Least Electricity? (2018)
#107Earlier quoted context omitted.
Typescript is a superset of Javascript, you can literally submit the faster JS programmes as the TS ones.
This may be a dumb question as I know nothing about Typescript, but is it idiomatic to do that, though? You can, for the most part, use C in C++. But if C was beating the pants off of C++ in benchmarks it wouldn't tell me anything useful if someone submitted a C program as the C++ benchmark. If I wanted to use idiomatic C, I'd use C. I expect a C++ vs. C comparison to compare the encouraged features of C++ with what'…
Re: Which Programming Languages Use the Least Electricity? (2018)
#108Re: Which Programming Languages Use the Least Electricity? (2018)
#109I'm a little surprised at where Erlang features in the list. I've never used it personally, but have heard so much about it being an amazing, performant language. I wonder why it's so time/energy/memory inefficient for the algorithms used in this exercise.
From http://erlang.org/doc/man/erl.html:
+sbwt none|very_short|short|medium|long|very_long
Sets scheduler busy wait threshold. Defaults to medium. The threshold
determines how long schedulers are to busy wait when running out of work
before going to sleep.Re: Which Programming Languages Use the Least Electricity? (2018)
#110For example, saying that Python uses much more energy is a foolish thing to say. The “same” algorithm written in pure Python is a very semantically different thing. It involves allocation of flexible objects that obey certain attribute lookup protocols, operator protocols, dynamic attribute mutation / creation, iteration protocols, etc. It is presumed that if you wrote in pure Python, you need this dynamism and ability to introspect at runtime, modify data structure layout arbitrarily, utilize an automatic garbage collector, etc. So you’d need a benchmark test that requires all that functionality before it could possibly make sense to test Python. Otherwise you’re penalizing Python for a bunch of expensive overhead, which is totally unfair and foolish because the whole point is that such overhead exists for use cases where either the costs are negligible or the flexibility that necessitates that overhead in any language happens to be a desired and important part, such that to write the same functionality in other languages would first require building all the protocols, garbage collection, etc. machinery that essentially defines Python.
If instead you have some benchmark problem that can be solved in e.g. C or Rust without needing any runtime dynamism or heavy machinery of certain protocols or garbage collection, then to write it in Python you would just write it in Cython or as a hand-made C extension module to specifically bypass the overhead of the interpreter or Python protocols / dynamic lookups / etc.
Basically, it never makes sense to compare Python and C on a benchmark that doesn’t require reimplementing most of Python in C first. Because to solve that problem in Python, the ubiquitous, basic, Python 101 way to do it would be to use Cython or numba or write your own extension module.
Python is basically a special C language DSL for dynamic types, garbage collection, and a set of conventions and protocols.
“Pure Python” is a linguistic trick for saying “a huge ton of tools that make C-level polymorphic structs easy to use.”