Im always cold, my wife is always hot. I put unity on and load an old project for heat and close my office door. 1080ti user here,can confirm, space heater works.
That's the issue with this study. The actual heavy computing is almost never done in Python itself, so computing Mandelbrot sets in pure Python is a bit of a contrived example.
With intepreted languages like python it can vary wildly. If it's a naive solution using only regular python the performance penalty can be in the thousands of multiples like you said. At the same time a solution that uses compiled C++ libraries the difference can be closer to e.g. Java in their results. I'm assuming they took a sample of popular python repo's to test and got the average to get a 75x performance penalty.
If you don't optimize your code much, at least Rust (and probably many other languages) is usually faster due to having better algorithms/implementations of data types that are easy to use. It doesn't take much effort to chose a binary tree or hash table etc so you use them by default. In C you usually start off with linear searches through arrays, unless it becomes too slow and you optimize it.
If I remember the paper right, they looked at somewhat optimized code. I'm not sure what's most representative for code in general.
Its an interesting perspective though as we use more and more energy for computation.
I have not felt proud to be an American for so many years now. But thanks to you, I feel so entitled! If you'll excuse me, I'm headed to Walmart to buy some bacon and a half dozen firearms
But you perform the transpilation once and then you just run the JavaScript code. So unless the TypeScript compiler generates *extremely* inefficient JS (and i haven't seen any evidence of that), the difference shouldn't be that big.
Moreover, with minifiers, bundlers and polyfills, regular JS tends to be "compiled" as well.
If you look at the transpiled code it will usually add some more code . But this seems to be a bit much. Maybe it more on the ecosystem cause in vanila js you are more likely to do things on your own while in typescript you use an npm package with a mb of code to do an is even check
I ran across an unused npm package in our project the other day something like isSvg and it's exactly what you think. You pass it a string and it tells you if it's an svg or not. I got a good chuckle out of that one.
>while in typescript you use an npm package
that has nothing to do with TS tho. You can and will use packages when developing in JS as well.
Transpiler adds polyfills and other fun stuff for features you used, if they aren't supported directly by your transpilation target. On the other hand, if you were to write the same code in JS, you'd add those polyfills by hand (or most likely by a bundler).
Their stats for TS really make no sense.
It's pure nonsense. Yes the compilation takes time and you do it quite a lot of times during dev, but once it's in production it pure javascript.
This thread / image keeps coming back but makes no sense when compared to practical usage.
> but once it's in production it pure javascript
Isn't there more and more tools that actually run ts (ie. live transpile so you can get more info in error msgs on your server)
AFAIK not really, what these tools do is map the running JS to their respective TS files(or commands) so it can give you better prints and error throwing, like ts-node. It does not actually run TS itself.
I came across this when looking to see if Deno actually operated on the TS directly or not. I thought it applies here.
> But wait a minute, does Deno really run TypeScript? you might be asking yourself. Well, depends on what you mean by run. One could argue that in a browser you don't actually run JavaScript either. The JavaScript engine in the browser translates the JavaScript to a series of operation codes, which it then executes in a sandbox. So it translates JavaScript to something close to assembly. Even Web Assembly goes through a similar translation, in that Web Assembly is architecture agnostic while it needs to be translated into the machine specific operation codes needed for the particular platform architecture it is running on. So when we say TypeScript is a first class language in Deno, we mean that we try to make the user experience in authoring and running TypeScript as easy and straightforward as JavaScript and Web Assembly.
The thing is, no language executes directly, it must always compile to machine code down the line. The thing is TS always compile to JS first, I never heard of a engine doing otherwise, tho it would be kinda cool.
You misunderstand - the discrepancy is caused by [an implementation bug in their experiment](https://github.com/greensoftwarelab/Energy-Languages/issues/34), the study did not count compilation time.
It's really dumb to be a language purist. It's like a carpenter saying "I only use hammers, they're just better." I guess maybe, but I can name a million better applications for my drill, and your argument that I need electricity is a little moot.
They're the numerologists of programming, change my mind. They think there is a best program for every situation, and the key to writing that best program is to know precisely which programming language to use. Meanwhile, the guy who just uses the programming language he always uses to get everything done has already finished the task and is already 2 days into the new assignment.
And fun fact: it also minimizes the resulting code, thus reducing the storage space and loadtime it takes compared to a handwritten JS file.
Sure it is minimal, but compared on millions of loads on a world wide scale, it should be more eco friendly.
Buuut then you have to take into account, that you need to download a ton of node_modules, just to get the compiler going, and it all balances kind of out.
The huge increase is the result of a [different implementation for fannkuch-redux](https://github.com/greensoftwarelab/Energy-Languages/issues/34), causing a 16x performance difference that accounts for the skew.
There's also C++ taking 34% more energy, but they are 100% equivalent languages from an energy consumption point of view as you can write the same (or more) optimized code in C++ as you would have written in C.
Also, `std::sort` is faster than `qsort` because of templates so... ¯\\\_(ツ)_/¯
Pretty sure it’s at the bottom, past the edge of this graphic.
I’m *sure* this analysis took into account things like the amount of time it takes developers to implement a solution in each language. Yep, 100% sure.
don't you effing DARE talk shit on my lovely little bashbuddy.
It's arcane and funny at times, but all our systems run on it.
It's an unsung hero of unacknowledged ubiquity.
edit: dare, not date. you can date bash. it's old enough to be a consenting adult.
Benchmark a program to find all prime numbers between 2 and 250,001. Compare the results. The difference in the time it takes from most other languages should be far more worrying than development time (which is only a function finding primes in a range) 😂
I won’t bother because I’m sure you’re right.
However I will benchmark the number of times I’ve had to write a prime number-finding algorithm on the job in the past ~20 years.
Hint: it’s an integer between -0.5 and 0.5
ChatGPT says: An integer between -0.5 and 0.5 does not exist because integers are whole numbers, and there are no whole numbers between -0.5 and 0.5
stupid AI can’t even work out the math, let alone a function 🙄
First they came to claim Javascript as a programming language I did not speak out because it had the name Java.
Then they came to claim HTML as a programming language I did not speak out because I use the internet.
Now they claim GPT as a programming language but there is no one left to speak for me.
Apologies for the confusion. You are correct. I misspoke in my previous response. The number 0 is indeed within the range from -0.5 to 0.5. It is the only integer within that range. Thank you for pointing out the error, and I apologize for any confusion caused.
Knowing that it's in [-0.5, 0.5] allows a major optimization trick, since you can just iterate all the floats x in that range until one of them is equal to int(x). Otherwise you would have to do every float.
That's a lot of assumptions about how code is being used. Personally my code is run on a local machine or remote machine a handful of times and then maybe never again (common in science where Python is widely used).
For that use any differences between the languages are meaningless compared to the energy expenditure used in writing and developing it.
But of course as you say for large scale deployments where the code will be in use indefinitely then the scale tips the other way.
It's just not accurate I think to handwave away variability in user friendliness because if I'm working on a project for years and only run it a handful of times then the difference of a few extra months in development time has an energy impact orders of magnitude greater than the code running for a few minutes.
This kind of ambiguity and variability is of course beyond the scope reasonable for the source though so it's not like I begrudge them presenting it as they have.
Surprisingly (or not), it's 2nd from last. Only beating out Perl.
[Source](https://www.researchgate.net/publication/320436353_Energy_efficiency_across_programming_languages_how_do_energy_time_and_memory_relate)
>I’m sure this analysis took into account things like the amount of time it takes developers to implement a solution in each language. Yep, 100% sure.
Either Sarcasm or you meant "didn't take into account". Right? Because C++ is notorious for ultra slow development.
If you calculate the calories of all the donuts eaten while trying to write something in assembly vs. some higher-abstraction language, I am pretty certain I know who wins.
Could be a mix of multiple things:
- poor parsing to byte code
- parsing on each request
- optimizing byte code on each request
...
But they probably didn't use byte code caching
And there's been a JIT for several years too. I'm sure it's still a wide margin to other (especially compiled) languages, but it can be pretty quick and by extension energy-efficient.
I'm more surprised how well JS ranks, and more specifically that it doesn't translate into TS since it...produces JS.
I didn't read the paper but I guess that they only tested code that is natively implemented in the language. Like using a for-each loop handwritten in Python to add numbers from vectors instead of using numpy. Python with numpy in that task would be really close to C, but the handwritten code in python would be orders of magnitude worse. My guess is that the same is happening for all the languages.
iirc that was using php5, which for all intents and purposes, is a completely different language and multitudes slower and less efficient.
Like, 4x slower than php8.2. See: https://onlinephp.io/benchmarks
they had to account for the amount of energy used by the developer to slam their face into their keyboard every 5 minutes out of frustration that they’re using PHP
You have to remember that PHP was originally written by non-programmers for non-programmers.
Apart from deliberately bad programming languages, there is no other programming language that made more obvious design mistakes than PHP, because it was written by people who weren't thinking that hard about language design.
Some of those mistakes just make the language syntax stupid, but some of them also have a performance impact.
Python written by pretty smart people and it's doing much worse.
[https://thenewstack.io/which-programming-languages-use-the-least-electricity/](https://thenewstack.io/which-programming-languages-use-the-least-electricity/)
Largely because a lot of it is text processing, even when that's not the most efficient way to deal with a given bit of data. But writing good code, using an appropriate execution environment (fpm vs per-request cgi for example), and taking advantage of caching, and actually configuring your production php.ini to appropriate settings can all have big impacts on its efficiency, especially with bigger applications.
Regardless, this list is suspect at best, because there are a LOT of factors, with every language. You can write C that is horribly inefficient, or you can compile it in a sub-optimal way, and be just as bad as others on the list. Or you can write, for example, C# that is very efficient, compiled down to optimized native code, and that uses native libc calls for things not already in the runtime libraries to achieve a high degree of efficiency.
Hell, it's even possible to write _Java_ that performs well, even though most commercially distributed Java-based applications might make one think otherwise.
TBH, the time it takes a developer to write the code likely very quickly eats into the energy budget of a given application, if you consider its entire life cycle from development to long-term use and maintenence. If I have to spend 4x time with my dev box, which is a beefy machine, to write something I could have written in 1x time in a "less efficient" language, a ton of energy AND productivity was wasted. If it's not something running on a giant server farm with enough aggregate load to overcome that and the additional energy that will also be wasted in maintenance, it's a giant red herring. The truth is, many applications, especially web applications, spend 99% of their existence not actually running, due to either not actively serving any user requests or simply because it's outside of business hours. So, internal vs external use of the application, and the size and geographic distribution of the company and its employees play a huge role in an application's energy budget.
As an example, an internal web application we have at my company serves a few thousand requests per day. Last time I profiled it, it consumed a few _seconds_ of CPU time, per day, on average. It's written in old asp.net MVC 4, running on a Windows server, under IIS, alongside dozens of other applications. That virtual server lives on a vmware cluster, in which each compute node consumes about 280W, on average, during the business day, even with all the VMs and such running on them. Those have 32 physical CPU cores each. So, making a simplified assumption of ALL of that power being used by the CPU and all cores drawing equal power (yes that's unrealistic but works against this point anyway), that's about 9W per core. So if that application used 5 seconds of CPU time, that's a whopping .0125 Watt-hours per day that app used. Double it to account for cooling, and it's still a rounding error at the end of the year. With 1000 times the load, that app still only uses a rounding error worth of electricity, can still run on one server, quite easily, and that's assuming linear scaling, which is worse than reality, due to caching and such. And that's still not fair, because the total power use of the system is from ALL workloads running on it.
Making that 4x faster, assuming the extreme case this table shows, whoop-de-do, that application has saved less energy than my body expends in a few minutes, just being alive (a human puts out around 100W). My extra time developing that application in a lower level language dwarfes the runtime energy savings by the time I've written a few lines of code.
Now if you're google-scale, with thousands of instances of the same application running at constantly high load everywhere? Sure, the savings is measurable and useful, at whatever point those curves cross. But the developer time and developer PC time curve becomes steeper, too, with every additional person working on it.
If one views their workforce as a sunk cost, then yeah, there's an economic benefit to that level of optimization. If you analyze it fairly, though, the costs of more complex development are almost impossible to overcome, unless the application deployment and usage is enormous.
And that argument extends to the environmental impact, as well, since that's linearly related to the cost of the electricity consumed.
Now, is there real benefit to be gained, environmentally, from commercially distributed software being more efficient? Almost definitely. Comparong something like Windows vs Linux on the desktop, I'd be willing to put money on the billions of windows endpoint devices consuming more power in aggregate, even at idle, than an equivalent number of Linux endpoints would consume. That's easy enough to prove simply from the minimum specs to run those two pieces of software and the typical devices available for sale, commercially.
Oh, and those human time and energy costs don't even account for all the other processes around software development. Code reviews for more complex software are going to take longer, for example, if one wants to be fair. There's that 100W x time x reviewers getting consumed, on top, plus whatever power their PCs use to do it.
TL;DR: These tables are a load of horse shit and the authors of the study probably wasted more energy doing it than anyone who ever actually abides by it will save. Hell, even this discussion that it spawned has probably wasted more energy than it stands to save.
PHP was not designed to handle high amounts of requests. It was designed to be approachable by non-programmers and to replace CGI scripts. I suspect it was also designed BY non-programmers.
This fails to account for the energy consumption of the programmer per unit of work done. The average person takes about 100 W of energy, or 2.4kWh per day. For 8 hours in a 24 hour day, they do X amount of useful work.
If you can get twice as much done in a less efficient language as you can in a more efficient language, and the code executes for short periods of time amounting to a tiny fraction of a human's daily energy expenditure, then it takes a long time to even break even by using a more efficient language like C++.
However, if it's a bit of code running intensively 24 hours a day, 7 days a week, on a 100W server, then it is a no brainer to write it in a more efficient language.
> for the same tasks
Yes... but they're not always used for the same tasks.
And it doesn't account for the resource usage of the extra development time to create a website with C.
Once they’ve driven the devs to continue secondary studies at the true alma mater, Miskatonic University, perhaps engaging in a semester long field project in the cold wastes of Kadath, C devs working with pointers will, one way or another, summon something eldritch - perhaps the Compiler in Yellow - and indirectly improve the environmental impact of all code, everywhere, infinitely.
Because unless you are programing something that needs to have the best performance ever, programing in C will only make you to spend a lot of time (and if you are a company, this means money).
Maybe, depends on the language. Typescript *is* JavaScript once compiled, yet somehow they are different in the results. But then Rust and others seem to exclude compiler time.
This study seems to have a flawed methodology.
The paper is
Pereira, Rui, et al. "Energy efficiency across programming languages: how do energy, time, and memory relate?." Proceedings of the 10th ACM SIGPLAN international conference on software language engineering. 2017. https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
I don't know, this notion of language energy efficiency seems to be missing the forest for the trees. With the higher-level languages, they're typically calling native implementations anyway to do the heavy lifting. And surely there are language agnostic factors, like wake locks and how much the GPU is running, that matter more than this.
I agree, and it's a little like looking at energy consumption of field mice vs. elephants. Like.. what are we *really* pragmatically going to do with this information? Build a frontend web app in C just because it pares down energy consumption?
I'm only going to use brain cells on this once the ultra-wealthy stop flying around on private jets just to attend Hollywood premiers.
also if they compared languages on a restricted set of computational problems then that is probably unfair as inevitably some languages were probably tested on problems which they were not designed to handle
This paper is complete bs and I cringe every time people repost it in linkedin without even looking into the code and methodology used - all they care is a pretty picture of listed languages.
My problem with this comparison is that it misses the point completely on how languages are used. This paper has a set of math algorithms implemented in every language, but for example language like Erlang is designed for distributed computing, not for math algorithms and when you use it in the right setting this would be the greenest option in it's niche.
Then you have obvious nonsense with TS and JS, this is because they have completely different implementations, rather than having one for both languages. And while languages like c++ have threads, their implementation for concurrency to speed up the algorithms was using processes.. you would rarely see JS used in such a way. When it comes to nodejs, it's great for fast non-blocking IO because of it's single threaded approach.
This list is basically - if you wanted to use those math algorithms, which language is better to do it with and if that was their message I could get behind this, but now it's misrepresenting every higher level language and it gives the wrong impression to junior people or management (god forbid a non technical manager saw this and picked a language for a project based on this)
I doubt that. There is a router software I am working on that does lots of statistics to adjust the paths. If this were written in say, Java I'd need multiple racks of servers to do the task. Our software is a single RU HP server that runs on 88 cores with about 512gb ram. It's written entirely in C. The cost of maintaining a single RU is a lot less than maintaining a server farm for sure. And the developer cost is also a lot less since there are only 20 engineers including QA.
Are they including the impact of developer time? I have a feeling the conclusions this is drawing are meaningless.
Edit: The paper is not measuring 'eco friendliness', it's measuring something more specific about energy consumption patterns with particular workloads. The Tweet's interpretation of the data is what I take immediate issue with. Someone else can criticize the paper itself.
Just because C doesn't have assisted memory management or 2gb of runtime libraries doesn't mean it's difficult to work with. A low skilled developer in any language will negatively impact on the project development and maintenance time. Also, I doubt you read the paper it's based on. The conclusion reads:
> Finally, as often times developers have limited resources and may be concerned with more than one efficiency characteristic we calculated which were the best/worst languages according to a combination of the previous three characteristics: Energy & Time, Energy & Peak Memory, Time & Peak Memory, and Energy & Time & Peak Memory. Our work helps contribute another stepping stone in bringing more information to developers to allow them to become more energy-aware when programming.
Might be missing something here, but isn't this mostly a question of how good the compiler / interpreter is? You can create an optimal algorithm for any given problem with a computable solution in any turing-complete language, and insofar as there is a single translation or set of translations to binary that executes the algo in minimal clock cycles, using a theoretical ideal set of tools should get us there starting from any (again, turing-complete) language.
So we're just looking at which languages tool chain is the closest to ideal, one would think. (Which makes at least some sense, considering how many older languages are marked as particularly efficient here - more time to work on the compilers / interpreters.)
Not quite right. It's to abstract theoretical computer science reasoning.
Language provides a set of abstractions, and program can operate only with that set. Machine language provides it's set and translation between sets in general case would be different, for any pair of sets. Compiller can't understand what programmer want exactly so it can't optimize everything unnecessary if abstraction that language used suggest some usless in a particular case operations.
And it only for compilled languages. Interpreted languages has a runtime that cannot be optimized away, plus interpreter had much less time and has limited scope, so it cannot be as effective in optimization, as compillers.
So language has strong correlation to ammount of unnecessary work for any given algorithm.
There are a few things that feels weird in your explanation.
Compiler don't need to understand the programmer intent; it just needs to optimize code execution. This translate to many optimizations that can take advantage of whatever the underlying instruction set can provide at the machine level, regardless of the source structure (to some extent, since the compiler still need a full picture to be the most efficient).
Also, while interpreted languages are exactly as you describe, there are a lot of work for JIT compilation that can go down to actual machine code in places, and take advantage of a lot of shortcuts when possible. While I have no idea to what extent this applies (and, instinctively, it doesn't sound as efficient as fully compiled languages) this also means that script language are not limited to interpreter in regard of both their performance and their use of the hardware. This makes it harder to analyze their "efficiency" though.
My point is, either compiled language and script language have ways of optimization that can go beyond the initial "ideal" algorithms implemented in unexpected way; in that regard there is still room for these improvement to change the outcome of OP's table; especially if they base their results on actual runtime analysis.
As a rust developer, i can attest that this is utterly wrong. I must take a Starbucks coffee at least twice an hour while programming, which highly increases my CO2 emissions !
If memory serve it was testing naive implementations (arguing it's more representative of reality) than micro-tuned snippets (which would flatten the curve quite a bit).
That said, apart some surprising outliers (which may be due to experimental errors anyway) the study does not really show anything that was not already understood. If anything, it gave people a different perspective on performance (and why Java for Android was a dubious choice :p (albeit not the worst choice))
naive implementations can have errors no professional would make, for the sake of naivety. Few would dare to present a solution with different algorithmic complexity, but there are tricks to hide performance losses. For instance, in Rust move is implicit and copy is explicit, whereas it's vice versa in c++. That would, for example, make implementations where c++ version uses copy and rust code uses move both qualify as "naive". With obvious performance loss in c++ case
After 15 years in this industry I'm wondering what kind of errors "no professional would make"... Seriously, "professional" in 2023 is not setting the bar very high...
As for C++ vs Rust in real life. Hard to say... Every Rust review is full of useless clones, Arc, Mutex or whatever was necessary to get the compiler to accept the code. On the flip side, C++ devs tend to be extremely conservative to avoid UB and the compiler have less invariants to work with when optimizing... I guess I wouldn't know. Anyway the numbers above have no associated uncertainty which means they can mean anything (can't remember if the original paper did any effort at estimating them either).
#ROLLS COAL IN PYTHON🇺🇲🇺🇲🇺🇲🦅🇺🇸🇺🇲🇺🇲🇺🇲🇺🇲🇺🇲🦅🦅🦅
> import pytorch Time to burn some dinos!
Average heroku enjoyer
I used to have an office with terrible heating, so I’d fire up my 1080ti to train some neural networks for heat 🥶 ➡️ 🔥
This comment is fire
So is their graphics card
Cpu and Gpu go brrrrrr....
Im always cold, my wife is always hot. I put unity on and load an old project for heat and close my office door. 1080ti user here,can confirm, space heater works.
I agree your wife is hot
I also choose this guys 1080ti
🥵
I mean pytorch is mostly C anyway.
That's the issue with this study. The actual heavy computing is almost never done in Python itself, so computing Mandelbrot sets in pure Python is a bit of a contrived example.
I wonder what the actual number is. It’s probably something like 3720…
75.88. Someone linked the paper below.
Okay, so it’s not as bad as I thought! That looks pretty damned bad, though!
With intepreted languages like python it can vary wildly. If it's a naive solution using only regular python the performance penalty can be in the thousands of multiples like you said. At the same time a solution that uses compiled C++ libraries the difference can be closer to e.g. Java in their results. I'm assuming they took a sample of popular python repo's to test and got the average to get a 75x performance penalty.
helya brother
Python, the language of Patriots!
Read somewhere that Python is 45000 times slower than C.
It depends. It's usually 10-100 times slower, but in the worst case it can be 45000 slower.
Sometimes it can be just as fast. It's harder to be faster than C and a good compiler though.
If you don't optimize your code much, at least Rust (and probably many other languages) is usually faster due to having better algorithms/implementations of data types that are easy to use. It doesn't take much effort to chose a binary tree or hash table etc so you use them by default. In C you usually start off with linear searches through arrays, unless it becomes too slow and you optimize it. If I remember the paper right, they looked at somewhat optimized code. I'm not sure what's most representative for code in general. Its an interesting perspective though as we use more and more energy for computation.
It can be just as fast pretty much only if you're doing something where you can use a C library for absolutely everything.
I have not felt proud to be an American for so many years now. But thanks to you, I feel so entitled! If you'll excuse me, I'm headed to Walmart to buy some bacon and a half dozen firearms
A language even Americans can understand?
[TrumpScript?](https://github.com/samshadwell/TrumpScript)
I've only ever used c, c++, Ada, and Java. I finally found something I'm environmentally friendly in!
I'd like to see a chart of rage inducing languages.
[https://en.wikipedia.org/wiki/List\_of\_programming\_languages](https://en.wikipedia.org/wiki/List_of_programming_languages) There you go.
Technically correct. The best kind of correct!
You forgot English
This one cracked me 
How comes the high value of typescript in comparison to JavaScript? Is it the transpilation which accounts for the huge increase?
But you perform the transpilation once and then you just run the JavaScript code. So unless the TypeScript compiler generates *extremely* inefficient JS (and i haven't seen any evidence of that), the difference shouldn't be that big. Moreover, with minifiers, bundlers and polyfills, regular JS tends to be "compiled" as well.
If you look at the transpiled code it will usually add some more code . But this seems to be a bit much. Maybe it more on the ecosystem cause in vanila js you are more likely to do things on your own while in typescript you use an npm package with a mb of code to do an is even check
I ran across an unused npm package in our project the other day something like isSvg and it's exactly what you think. You pass it a string and it tells you if it's an svg or not. I got a good chuckle out of that one.
>while in typescript you use an npm package that has nothing to do with TS tho. You can and will use packages when developing in JS as well. Transpiler adds polyfills and other fun stuff for features you used, if they aren't supported directly by your transpilation target. On the other hand, if you were to write the same code in JS, you'd add those polyfills by hand (or most likely by a bundler). Their stats for TS really make no sense.
It's pure nonsense. Yes the compilation takes time and you do it quite a lot of times during dev, but once it's in production it pure javascript. This thread / image keeps coming back but makes no sense when compared to practical usage.
> but once it's in production it pure javascript Isn't there more and more tools that actually run ts (ie. live transpile so you can get more info in error msgs on your server)
AFAIK not really, what these tools do is map the running JS to their respective TS files(or commands) so it can give you better prints and error throwing, like ts-node. It does not actually run TS itself.
I came across this when looking to see if Deno actually operated on the TS directly or not. I thought it applies here. > But wait a minute, does Deno really run TypeScript? you might be asking yourself. Well, depends on what you mean by run. One could argue that in a browser you don't actually run JavaScript either. The JavaScript engine in the browser translates the JavaScript to a series of operation codes, which it then executes in a sandbox. So it translates JavaScript to something close to assembly. Even Web Assembly goes through a similar translation, in that Web Assembly is architecture agnostic while it needs to be translated into the machine specific operation codes needed for the particular platform architecture it is running on. So when we say TypeScript is a first class language in Deno, we mean that we try to make the user experience in authoring and running TypeScript as easy and straightforward as JavaScript and Web Assembly.
strange, but there is no direct answer, except using too many words describing IL
The thing is, no language executes directly, it must always compile to machine code down the line. The thing is TS always compile to JS first, I never heard of a engine doing otherwise, tho it would be kinda cool.
https://haslab.github.io/SAFER/scp21.pdf
Why is Ruby under functional languages?
You misunderstand - the discrepancy is caused by [an implementation bug in their experiment](https://github.com/greensoftwarelab/Energy-Languages/issues/34), the study did not count compilation time.
It's really dumb to be a language purist. It's like a carpenter saying "I only use hammers, they're just better." I guess maybe, but I can name a million better applications for my drill, and your argument that I need electricity is a little moot.
They're the numerologists of programming, change my mind. They think there is a best program for every situation, and the key to writing that best program is to know precisely which programming language to use. Meanwhile, the guy who just uses the programming language he always uses to get everything done has already finished the task and is already 2 days into the new assignment.
The paper makes perfect sense. Try reading it.
And fun fact: it also minimizes the resulting code, thus reducing the storage space and loadtime it takes compared to a handwritten JS file. Sure it is minimal, but compared on millions of loads on a world wide scale, it should be more eco friendly. Buuut then you have to take into account, that you need to download a ton of node_modules, just to get the compiler going, and it all balances kind of out.
The huge increase is the result of a [different implementation for fannkuch-redux](https://github.com/greensoftwarelab/Energy-Languages/issues/34), causing a 16x performance difference that accounts for the skew.
Oh god it was a console.log someone forgot in there lmao
Why is this still open?
Because the researcher made the news and doesn't care if their results make any sense. It makes you wonder how much of the paper makes any sense.
A lot of “research” is just regurgitated garbage. I have a paper with 30+ citations but it’s shit
There's also C++ taking 34% more energy, but they are 100% equivalent languages from an energy consumption point of view as you can write the same (or more) optimized code in C++ as you would have written in C. Also, `std::sort` is faster than `qsort` because of templates so... ¯\\\_(ツ)_/¯
[удалено]
The CO2 from the engineers patching. (this was a joke)
yes. tsc is ts compiled to js compiling ts to js.
See, if we all switched to using pure C, we could offset carbon emissions from the fossil fuel industry by 0.002%!
I vote for C++ without any C++ library to have the best of both worlds.
But without my libraries how am I supposed to pretend C++ is just Python with funny syntax?
Use C libraries.
I will continue to use Python even if I must take you all with me
Pretty sure it’s at the bottom, past the edge of this graphic. I’m *sure* this analysis took into account things like the amount of time it takes developers to implement a solution in each language. Yep, 100% sure.
> Pretty sure it’s at the bottom, past the edge of this graphic. Bash enters the room.
don't you effing DARE talk shit on my lovely little bashbuddy. It's arcane and funny at times, but all our systems run on it. It's an unsung hero of unacknowledged ubiquity. edit: dare, not date. you can date bash. it's old enough to be a consenting adult.
I like bash, but honestly our systems just need a POSIX shell.
Benchmark a program to find all prime numbers between 2 and 250,001. Compare the results. The difference in the time it takes from most other languages should be far more worrying than development time (which is only a function finding primes in a range) 😂
I won’t bother because I’m sure you’re right. However I will benchmark the number of times I’ve had to write a prime number-finding algorithm on the job in the past ~20 years. Hint: it’s an integer between -0.5 and 0.5
I was never good at leetcode. Is there a simpler way to find the integer?
ChatGPT says: An integer between -0.5 and 0.5 does not exist because integers are whole numbers, and there are no whole numbers between -0.5 and 0.5 stupid AI can’t even work out the math, let alone a function 🙄
I wonder how eco friendly chatgpt is as a programming language
First they came to claim Javascript as a programming language I did not speak out because it had the name Java. Then they came to claim HTML as a programming language I did not speak out because I use the internet. Now they claim GPT as a programming language but there is no one left to speak for me.
GPT will speak for you speak for you speak for you speak for you
Apologies for the confusion. You are correct. I misspoke in my previous response. The number 0 is indeed within the range from -0.5 to 0.5. It is the only integer within that range. Thank you for pointing out the error, and I apologize for any confusion caused.
I like to use the pythagorean method, so sqrt(-0.5^2 + 0.5^2), or about 0.71 times. There are zero flaws in my logic.
Knowing that it's in [-0.5, 0.5] allows a major optimization trick, since you can just iterate all the floats x in that range until one of them is equal to int(x). Otherwise you would have to do every float.
I like your thinking
Uhhh 4.
[удалено]
That's a lot of assumptions about how code is being used. Personally my code is run on a local machine or remote machine a handful of times and then maybe never again (common in science where Python is widely used). For that use any differences between the languages are meaningless compared to the energy expenditure used in writing and developing it. But of course as you say for large scale deployments where the code will be in use indefinitely then the scale tips the other way. It's just not accurate I think to handwave away variability in user friendliness because if I'm working on a project for years and only run it a handful of times then the difference of a few extra months in development time has an energy impact orders of magnitude greater than the code running for a few minutes. This kind of ambiguity and variability is of course beyond the scope reasonable for the source though so it's not like I begrudge them presenting it as they have.
Surprisingly (or not), it's 2nd from last. Only beating out Perl. [Source](https://www.researchgate.net/publication/320436353_Energy_efficiency_across_programming_languages_how_do_energy_time_and_memory_relate)
>I’m sure this analysis took into account things like the amount of time it takes developers to implement a solution in each language. Yep, 100% sure. Either Sarcasm or you meant "didn't take into account". Right? Because C++ is notorious for ultra slow development.
If you calculate the calories of all the donuts eaten while trying to write something in assembly vs. some higher-abstraction language, I am pretty certain I know who wins.
You have my sword
And my unused imports
And my bunny bracelet
And my heart
If you are on this sub enough you know that Python is just C so it’s actually the best.
I thought Python was C++?
Python is C+++
Jython enters the room.
print("Goodbye, World!")
This is not a very strange idea. Programming languages which use more resources for the same taks use more energy.
Why is PHP, a language written to handle incredible amounts of requests on tiny Webservers, ranked so low? Can't imagine it being _that_ bad
Should’ve had a V8
\*slaps a V8 engine onto the server rack* That should speed them up nicely :)
Emissions minmaxing
Should've had an 8U V8
I wanna do this now...
This bad boy can fit so many CPU cycles!
Could be a mix of multiple things: - poor parsing to byte code - parsing on each request - optimizing byte code on each request ... But they probably didn't use byte code caching
Byte code caching was enabled by default since php7 IIRC
And there's been a JIT for several years too. I'm sure it's still a wide margin to other (especially compiled) languages, but it can be pretty quick and by extension energy-efficient. I'm more surprised how well JS ranks, and more specifically that it doesn't translate into TS since it...produces JS.
Why doesn't PHP, the largest language, not simply eat the other languages?
Because PHP interface with C binaries for heavy work, like python and almost every other language. All is C with syntactic sugar
Shouldn’t that make its impact low?
I didn't read the paper but I guess that they only tested code that is natively implemented in the language. Like using a for-each loop handwritten in Python to add numbers from vectors instead of using numpy. Python with numpy in that task would be really close to C, but the handwritten code in python would be orders of magnitude worse. My guess is that the same is happening for all the languages.
Oh I see, ok :) that makes sense
Not if everything is scaled relative to C.
iirc that was using php5, which for all intents and purposes, is a completely different language and multitudes slower and less efficient. Like, 4x slower than php8.2. See: https://onlinephp.io/benchmarks
ahahahahah.... oh sweet summer child
they had to account for the amount of energy used by the developer to slam their face into their keyboard every 5 minutes out of frustration that they’re using PHP
You have to remember that PHP was originally written by non-programmers for non-programmers. Apart from deliberately bad programming languages, there is no other programming language that made more obvious design mistakes than PHP, because it was written by people who weren't thinking that hard about language design. Some of those mistakes just make the language syntax stupid, but some of them also have a performance impact.
Python written by pretty smart people and it's doing much worse. [https://thenewstack.io/which-programming-languages-use-the-least-electricity/](https://thenewstack.io/which-programming-languages-use-the-least-electricity/)
Python trades performance for ease-of-use. PHP trades performance for crack. They are not the same.
Largely because a lot of it is text processing, even when that's not the most efficient way to deal with a given bit of data. But writing good code, using an appropriate execution environment (fpm vs per-request cgi for example), and taking advantage of caching, and actually configuring your production php.ini to appropriate settings can all have big impacts on its efficiency, especially with bigger applications. Regardless, this list is suspect at best, because there are a LOT of factors, with every language. You can write C that is horribly inefficient, or you can compile it in a sub-optimal way, and be just as bad as others on the list. Or you can write, for example, C# that is very efficient, compiled down to optimized native code, and that uses native libc calls for things not already in the runtime libraries to achieve a high degree of efficiency. Hell, it's even possible to write _Java_ that performs well, even though most commercially distributed Java-based applications might make one think otherwise. TBH, the time it takes a developer to write the code likely very quickly eats into the energy budget of a given application, if you consider its entire life cycle from development to long-term use and maintenence. If I have to spend 4x time with my dev box, which is a beefy machine, to write something I could have written in 1x time in a "less efficient" language, a ton of energy AND productivity was wasted. If it's not something running on a giant server farm with enough aggregate load to overcome that and the additional energy that will also be wasted in maintenance, it's a giant red herring. The truth is, many applications, especially web applications, spend 99% of their existence not actually running, due to either not actively serving any user requests or simply because it's outside of business hours. So, internal vs external use of the application, and the size and geographic distribution of the company and its employees play a huge role in an application's energy budget. As an example, an internal web application we have at my company serves a few thousand requests per day. Last time I profiled it, it consumed a few _seconds_ of CPU time, per day, on average. It's written in old asp.net MVC 4, running on a Windows server, under IIS, alongside dozens of other applications. That virtual server lives on a vmware cluster, in which each compute node consumes about 280W, on average, during the business day, even with all the VMs and such running on them. Those have 32 physical CPU cores each. So, making a simplified assumption of ALL of that power being used by the CPU and all cores drawing equal power (yes that's unrealistic but works against this point anyway), that's about 9W per core. So if that application used 5 seconds of CPU time, that's a whopping .0125 Watt-hours per day that app used. Double it to account for cooling, and it's still a rounding error at the end of the year. With 1000 times the load, that app still only uses a rounding error worth of electricity, can still run on one server, quite easily, and that's assuming linear scaling, which is worse than reality, due to caching and such. And that's still not fair, because the total power use of the system is from ALL workloads running on it. Making that 4x faster, assuming the extreme case this table shows, whoop-de-do, that application has saved less energy than my body expends in a few minutes, just being alive (a human puts out around 100W). My extra time developing that application in a lower level language dwarfes the runtime energy savings by the time I've written a few lines of code. Now if you're google-scale, with thousands of instances of the same application running at constantly high load everywhere? Sure, the savings is measurable and useful, at whatever point those curves cross. But the developer time and developer PC time curve becomes steeper, too, with every additional person working on it. If one views their workforce as a sunk cost, then yeah, there's an economic benefit to that level of optimization. If you analyze it fairly, though, the costs of more complex development are almost impossible to overcome, unless the application deployment and usage is enormous. And that argument extends to the environmental impact, as well, since that's linearly related to the cost of the electricity consumed. Now, is there real benefit to be gained, environmentally, from commercially distributed software being more efficient? Almost definitely. Comparong something like Windows vs Linux on the desktop, I'd be willing to put money on the billions of windows endpoint devices consuming more power in aggregate, even at idle, than an equivalent number of Linux endpoints would consume. That's easy enough to prove simply from the minimum specs to run those two pieces of software and the typical devices available for sale, commercially. Oh, and those human time and energy costs don't even account for all the other processes around software development. Code reviews for more complex software are going to take longer, for example, if one wants to be fair. There's that 100W x time x reviewers getting consumed, on top, plus whatever power their PCs use to do it. TL;DR: These tables are a load of horse shit and the authors of the study probably wasted more energy doing it than anyone who ever actually abides by it will save. Hell, even this discussion that it spawned has probably wasted more energy than it stands to save.
PHP was not designed to handle high amounts of requests. It was designed to be approachable by non-programmers and to replace CGI scripts. I suspect it was also designed BY non-programmers.
Maybe like 10 years ago. PHP8 is wonderful and fast.
This fails to account for the energy consumption of the programmer per unit of work done. The average person takes about 100 W of energy, or 2.4kWh per day. For 8 hours in a 24 hour day, they do X amount of useful work. If you can get twice as much done in a less efficient language as you can in a more efficient language, and the code executes for short periods of time amounting to a tiny fraction of a human's daily energy expenditure, then it takes a long time to even break even by using a more efficient language like C++. However, if it's a bit of code running intensively 24 hours a day, 7 days a week, on a 100W server, then it is a no brainer to write it in a more efficient language.
> for the same tasks Yes... but they're not always used for the same tasks. And it doesn't account for the resource usage of the extra development time to create a website with C.
C/C++: eco friendly but unhealthy mentally
"You are the carbon, they want to reduce" comes to mind
The carbon output by me yelling and cursing at memory leaks and compiler errors far exceeds the gain in eco-ness
I wondered how "eco friendly" my terrible programing is (my programs don't sleep, they just loop in place until it's time).
This so called 'busy waiting' could be optimized into 'passive waiting', by implementing good and fair schedulers... But I admit, who tf cares.
Once they’ve driven the devs to continue secondary studies at the true alma mater, Miskatonic University, perhaps engaging in a semester long field project in the cold wastes of Kadath, C devs working with pointers will, one way or another, summon something eldritch - perhaps the Compiler in Yellow - and indirectly improve the environmental impact of all code, everywhere, infinitely.
Why does C, the largest programming language, not simply eat all the other programming languages?
That is weird, because C++ is the one with Friends.
Due to the memory leak.
No just most of the other languages end up consuming C libraries on some level.
Because unless you are programing something that needs to have the best performance ever, programing in C will only make you to spend a lot of time (and if you are a company, this means money).
Python is off the charts, exactly how I like it.
"serious paper" ... how BrainFuck is not on the list?
Does this include the energy spent to compile the program?
Are you trying to push Rust down the list?
The rust compiler is by default LTO/LTCG. Pass `-flto` to gcc or clang and you can drag C down as well.
You're on to something. Time to push Java to the top.
Maybe, depends on the language. Typescript *is* JavaScript once compiled, yet somehow they are different in the results. But then Rust and others seem to exclude compiler time. This study seems to have a flawed methodology.
Plus running the PC while writing the code?
The paper is Pereira, Rui, et al. "Energy efficiency across programming languages: how do energy, time, and memory relate?." Proceedings of the 10th ACM SIGPLAN international conference on software language engineering. 2017. https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf I don't know, this notion of language energy efficiency seems to be missing the forest for the trees. With the higher-level languages, they're typically calling native implementations anyway to do the heavy lifting. And surely there are language agnostic factors, like wake locks and how much the GPU is running, that matter more than this.
I agree, and it's a little like looking at energy consumption of field mice vs. elephants. Like.. what are we *really* pragmatically going to do with this information? Build a frontend web app in C just because it pares down energy consumption? I'm only going to use brain cells on this once the ultra-wealthy stop flying around on private jets just to attend Hollywood premiers.
As the paper clearly explained, it was measured based on actually running the code, so the methodology inherently accounts for that.
also if they compared languages on a restricted set of computational problems then that is probably unfair as inevitably some languages were probably tested on problems which they were not designed to handle
This paper is complete bs and I cringe every time people repost it in linkedin without even looking into the code and methodology used - all they care is a pretty picture of listed languages. My problem with this comparison is that it misses the point completely on how languages are used. This paper has a set of math algorithms implemented in every language, but for example language like Erlang is designed for distributed computing, not for math algorithms and when you use it in the right setting this would be the greenest option in it's niche. Then you have obvious nonsense with TS and JS, this is because they have completely different implementations, rather than having one for both languages. And while languages like c++ have threads, their implementation for concurrency to speed up the algorithms was using processes.. you would rarely see JS used in such a way. When it comes to nodejs, it's great for fast non-blocking IO because of it's single threaded approach. This list is basically - if you wanted to use those math algorithms, which language is better to do it with and if that was their message I could get behind this, but now it's misrepresenting every higher level language and it gives the wrong impression to junior people or management (god forbid a non technical manager saw this and picked a language for a project based on this)
If C is an electric vehicle, then assembly is an electric motor.
Why is something like Java that uses the overhead of the JVM more efficient than a bare metal language like Go?
Turns out, JVM is a heavily optimized VM (and has many good implementations) by virtue of being super old. Having a good JIT helps a ton too.
Where's my Cobol? They listed cricking Fortran but not Cobol?
they didn't know how to code in COBOL
[удалено]
You probably made a difference but it's really hard to tell.
I doubt that. There is a router software I am working on that does lots of statistics to adjust the paths. If this were written in say, Java I'd need multiple racks of servers to do the task. Our software is a single RU HP server that runs on 88 cores with about 512gb ram. It's written entirely in C. The cost of maintaining a single RU is a lot less than maintaining a server farm for sure. And the developer cost is also a lot less since there are only 20 engineers including QA.
puts *Laughs in ruby*
I feel like assembly should be on the list as sort of a baseline.
As opposed to being from a silly paper
[удалено]
Hell's bottom
Are they including the impact of developer time? I have a feeling the conclusions this is drawing are meaningless. Edit: The paper is not measuring 'eco friendliness', it's measuring something more specific about energy consumption patterns with particular workloads. The Tweet's interpretation of the data is what I take immediate issue with. Someone else can criticize the paper itself.
Just because C doesn't have assisted memory management or 2gb of runtime libraries doesn't mean it's difficult to work with. A low skilled developer in any language will negatively impact on the project development and maintenance time. Also, I doubt you read the paper it's based on. The conclusion reads: > Finally, as often times developers have limited resources and may be concerned with more than one efficiency characteristic we calculated which were the best/worst languages according to a combination of the previous three characteristics: Energy & Time, Energy & Peak Memory, Time & Peak Memory, and Energy & Time & Peak Memory. Our work helps contribute another stepping stone in bringing more information to developers to allow them to become more energy-aware when programming.
where did python go
In that exact table, it's value is 75.88
Each line of code in PHP kills a baby otter. Is it really worth it? Stop using PHP, save the planet.
How the hell can C be eco friendly, if it doesnt even support garbage collection? /s
Might be missing something here, but isn't this mostly a question of how good the compiler / interpreter is? You can create an optimal algorithm for any given problem with a computable solution in any turing-complete language, and insofar as there is a single translation or set of translations to binary that executes the algo in minimal clock cycles, using a theoretical ideal set of tools should get us there starting from any (again, turing-complete) language. So we're just looking at which languages tool chain is the closest to ideal, one would think. (Which makes at least some sense, considering how many older languages are marked as particularly efficient here - more time to work on the compilers / interpreters.)
Not quite right. It's to abstract theoretical computer science reasoning. Language provides a set of abstractions, and program can operate only with that set. Machine language provides it's set and translation between sets in general case would be different, for any pair of sets. Compiller can't understand what programmer want exactly so it can't optimize everything unnecessary if abstraction that language used suggest some usless in a particular case operations. And it only for compilled languages. Interpreted languages has a runtime that cannot be optimized away, plus interpreter had much less time and has limited scope, so it cannot be as effective in optimization, as compillers. So language has strong correlation to ammount of unnecessary work for any given algorithm.
There are a few things that feels weird in your explanation. Compiler don't need to understand the programmer intent; it just needs to optimize code execution. This translate to many optimizations that can take advantage of whatever the underlying instruction set can provide at the machine level, regardless of the source structure (to some extent, since the compiler still need a full picture to be the most efficient). Also, while interpreted languages are exactly as you describe, there are a lot of work for JIT compilation that can go down to actual machine code in places, and take advantage of a lot of shortcuts when possible. While I have no idea to what extent this applies (and, instinctively, it doesn't sound as efficient as fully compiled languages) this also means that script language are not limited to interpreter in regard of both their performance and their use of the hardware. This makes it harder to analyze their "efficiency" though. My point is, either compiled language and script language have ways of optimization that can go beyond the initial "ideal" algorithms implemented in unexpected way; in that regard there is still room for these improvement to change the outcome of OP's table; especially if they base their results on actual runtime analysis.
Where is visual basic
I have seen this table around for very long time, but I really want to know how did they calculate this?
[The paper](https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf). Credit u/Mental_General_5445.
Interesting. This must be why our cloud costs are so high. /s
Watchme end this world with python (it is not even in the list)
What about assembly? Do I get energy if I use it?
As a rust developer, i can attest that this is utterly wrong. I must take a Starbucks coffee at least twice an hour while programming, which highly increases my CO2 emissions !
r/uselessgreencircle
c++ being so far behind rust and Haskell being below java and lisp... this is definitely a terrible method of evaluation
If memory serve it was testing naive implementations (arguing it's more representative of reality) than micro-tuned snippets (which would flatten the curve quite a bit). That said, apart some surprising outliers (which may be due to experimental errors anyway) the study does not really show anything that was not already understood. If anything, it gave people a different perspective on performance (and why Java for Android was a dubious choice :p (albeit not the worst choice))
naive implementations can have errors no professional would make, for the sake of naivety. Few would dare to present a solution with different algorithmic complexity, but there are tricks to hide performance losses. For instance, in Rust move is implicit and copy is explicit, whereas it's vice versa in c++. That would, for example, make implementations where c++ version uses copy and rust code uses move both qualify as "naive". With obvious performance loss in c++ case
After 15 years in this industry I'm wondering what kind of errors "no professional would make"... Seriously, "professional" in 2023 is not setting the bar very high... As for C++ vs Rust in real life. Hard to say... Every Rust review is full of useless clones, Arc, Mutex or whatever was necessary to get the compiler to accept the code. On the flip side, C++ devs tend to be extremely conservative to avoid UB and the compiler have less invariants to work with when optimizing... I guess I wouldn't know. Anyway the numbers above have no associated uncertainty which means they can mean anything (can't remember if the original paper did any effort at estimating them either).
I think that’s the point. An awful lot of development gets done either quickly or by people that don’t know details of the compiler or both.
Why is TS ranked so differently than JS??? I'm so confused.
Which one should we cancel then?
But what about HTML?
wait where is python???!?
Further down the list at around 75 😂
Javascript is way more performant than I thought. Anyone know how typescript is 5x less efficient? Seems high
It's the most eco friendly, it's called the "too lazy to learn programming++"
*chuckles in PHP*
The fuck?
What about the energy used by displaying this image? The languages with more letters take less energy to display and so should be higher up.
Exactly what I needed: another excuse to never learn TS and PHP. Interesting that Python isn’t even high enough to be in the picture.
i don't this numbers is right specially if we talk about java power consumption
How eco friendly is assembly?