10 ms·

Energy Efficiency across Programming Languages (2017) [pdf]

79 points by g42gregory 4y ago

pttrn 4y ago
Note: this is from 2017.
sodimel 4y ago
I've seen some comments on twitter (like this one [0]) that are saying that the complexity of programs in different languages is not the same and that is impacting results. Is someone willing to develop this for me (since I don't really know any other language here other than Python)? Bonus: here's "Ranking Programming Languages by Energy Efficiency", from 2021 [1] [0]: https://twitter.com/Czaki_PL/status/1569636020475265025 https://twitter.com/Czaki_PL/status/1569636020475265025 [1]: https://haslab.github.io/SAFER/scp21.pdf https://haslab.github.io/SAFER/scp21.pdf
- ranguna 4y ago
  I really need to pickup on rust
- hither_shores 4y ago
  The linked c code sample sorts the array, then accumulates the unique elements in a single pass. The python code sample makes a separate pass over `unique` for every element of `items`.
  - Genmutant 4y ago
    The python code also prints the resulting list in the same order. It's a completely different problem to solve. In python I would throw the list in a set and return the size of it / print that.
rahen 4y ago
Previous submission: https://news.ycombinator.com/item?id=32485886 https://news.ycombinator.com/item?id=32485886
misja111 4y ago
I see similar postings coming by on LinkedIn now and then. Although there is some value in the benchmark results, the way these results are promoted is such a BS. If your company's business is really in running some algorithms similar to binary search or the n-body problem, you should probably not be checking which language to choose that is most energy efficient, but which library or framework suits you the best. E.g you can perfectly well use Python + Pandas or NumPy even though everybody will agree that Python in itself is terribly inefficient. If you really want to go to the extreme in saving energy you should go all the way and code your algorithms in assembly. But it's obvious why this is probably not a very wise choice. Everybody who knows a bit about IT will understand this, but the danger is that some project managers will read one of these papers and draw the conclusion that the team should switch to C or Rust because it is more sustainable ..
- c_o_n_v_e_x 4y ago
  I'm also seeing this trend as well.. "Software needs to be made more energy efficient." Usually this comment is coming from disgruntled data center designers who feel like they are unfairly being forced to eek out more efficiency when the onus should be the IT manufacturers and SW developers. This attitude is somewhat justified as it is possible to run servers at much warmer temps, but the DC industry (namely their customers) still continue to insist on SLAs that have unreasonably low air temperature set points. IMO, the first wave of optimizing software for energy consumption has already happened via virtualization. Ideally, I can run the same workload with less metal/watts. I feel like the next round of optimization will be more problematic. You could re-write software to take advantage of hardware acceleration features that are baked into the silicon to ideally speed things up/reduce power consumption, however this comes with its own issues. You need to be very familiar with your hardware. Integrating much more tightly means your married to your metal... kinda like CUDA lock-in in the GPU ecosystem.
  - josephg 4y ago
    > You need to be very familiar with your hardware. Integrating much more tightly means your married to your metal I don’t know how true it is in the HPC space, but the more optimization work I do the more I realise how horribly inefficient 99% of programs are. Most devs these days just don’t care about making software fast, and when they do they have no idea where to start or what will help. Last year I spent some time optimising CRDTs (used in collaborative text editing). Automerge (a well known library) took 5 minutes to run a certain benchmark. Yjs (considered a mature, well performing library) took 1 second to run the same test. After spending some time optimizing, I have code now which can do the same work in 4 milliseconds. I’m not using any special hardware - this is just in straight forward rust. The remarkable part is that automerge isn’t written in an uncharacteristically bad way. Sure, it uses immutablejs - but plenty of modern javascript programs do something very similar. Even yjs, despite being the target of some careful optimization work, is still 200x slower than it could be. - and thus, wasting 99.5% of its energy budget. If even yjs can be sped up by 200x, how much do you think most enterprise software could be sped up, if people tried? 500x? 10000x? I don’t think we need deeper integration with hardware. We just need more software developers who care at all about performance. Virtualisation wipes out 20%+ of the performance of the machine, depending on what you’re doing. But we pay that cost gladly because it’s marginally easier than sharing a Linux kernel between multiple processes. I think if our CPUs had capped out 50x slower than they are today, the average user would hardly notice any difference. The only difference would be that software would be more expensive to make, because software engineers would need to actually understand how the computer works to make software perform. Things like the virtual DOM wouldn’t be fast enough to use at scale. Video games and zoom wouldn’t be quite as pretty. But we’d live.
montebicyclelo 4y ago
The code from this study is here: https://github.com/greensoftwarelab/Energy-Languages https://github.com/greensoftwarelab/Energy-Languages From looking at the code snippets, a big issue with this study becomes clear - it doesn't reflect how languages like Python are used in practice. In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/... i.e. Python code usually makes use of a vast ecosystem of optimized science/maths/data science libraries. Whereas the study code is mainly using pure Python. It's an issue with the methodology that the programs are written specifically for this study; creating an artificial situation.
- zekrioca 4y ago
  > In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/ How would this be comparing apples to apples? The paper’s main objective is to compare programming languages in their own native calls. It is like properly translating the Bible or Shakespeare to other languages: some translations will be more textual than others, loosing all the nuances, specially if compared to the original transcript. If you have python glue calls to other processes written in other languages, then you would be creating noisy in results. It is not the purpose of the paper at all, and it is outside of its scope.
- g42gregory 4y ago
  That is a really good point about Python being a connector language and internal API implementations done in C/C++/Fortran/etc... It kind of makes me question the entire premise of this paper.
- alcover 4y ago
  Forgive my pedantry but the ecosystem is not the language. Nor is practice. Ad absurdum, you could include the hardware pythonists usually employ. If you use python as glue, it should be compared to other languages used as glue.
  - montebicyclelo 4y ago
    Is it not fair enough to use ubiquitous libraries in the code for this test? E.g. look at the n bodies code.. someone trying to write efficient Python code would be using NumPy at the very least (and possibly Numba).
Neil44 4y ago
PHP looks horrific for energy use although it would have been 5.x in 2017. Think about all those PHP websites out there spending all day serving requests to bots and brute forcers. That's a lot of energy.
- sdze 4y ago
  Rasmus Lerdorf promotes PHP8 as CO2 reducing update. I agree. You can serve many more visitors with the same server hardware.
- kaba0 4y ago
  Well, those websites just wait for the OS most of the time, not using any energy. These benchmarks may not be representative for PHP as the usual way of operation for it is not some hot loop numerical compute done continuously.
whizzter 4y ago
JavaScript and TypeScript yield different results, there could be reasons like backwards compatibility transpilation but that's an option, otherwise code should be identical if written for performance.
- HoolaBoola 4y ago
  One of the JavaScript programs at least was concurrent, whereas the TypeScript equivalent was synchronous. No wonder there's a difference... Haven't looked closely at the other problems, but it's apparent to me that the solutions are not even trying to be similar, so comparing their efficiency is near useless. the problem in question was the k-nucleotide one, IIRC: https://github.com/greensoftwarelab/Energy-Languages/blob/1356528173d6bb07fb2512037c0ed8e2279ce440/JavaScript/k-nucleotide/knucleotide.node-2.node https://github.com/greensoftwarelab/Energy-Languages/blob/13...
- igouy 4y ago
  Maybe the JavaScript wouldn't type check with TypeScript.
guiriduro 4y ago
Interesting, but I'd be more interested in the holistic, total energy cost of a particular language choice. Only where the program is highly compute-bound and is run for many parallel instance-hours, would an analysis like this help to determine the best options, like e.g. the language used for a widely-used spreadsheet program. In a more 'real life' case, the energy costs of developer-hours also needs to be amortised (their dev machines, their coffees & pizzas, the light and heating of their home/office, maybe travel to office etc.) which is much more conditioned by the productivity of the language for the problem domain. In many cases, the production energy use of a given language is miniscule in that totality, so only where it is a significant component should it be part of language selection criteria.
wilmajacob 4y ago
JonChesterfield 4y ago
A colleague looked into improving energy efficiency of software as a academic project. Concluded that it's essentially the same problem as optimisation. Making the program/task finish sooner was by far the biggest contributor to energy saving, so the techniques for reducing energy consumption are those of program optimisation.
- kaba0 4y ago
  That’s the reason for mobile devices’ processor setup. There is a race to sleep with regards to CPUs.
- GrumpySloth 4y ago
  Except SIMD code while faster may sometimes be less energy-efficient than scalar code. Different SIMD extensions have different energy efficiency characteristics. Also, multithreaded code may finish a task sooner, but spend more energy budget due to costs of synchronisation, spawning and joining threads, etc.
  - JonChesterfield 4y ago
    Nice point. I'll add it to the list of reasons to avoid multi-threading things wherever possible!
kaba0 4y ago
It’s crazy how good Java is at energy efficiency. It is criminally underhyped and are sometimes replaced by the new best PL that will change everything, and yet it is very unlikely to have better results besides the inherent one in the rewrite. Also, the often claimed negative of Java, memory overhead is relevant here — a GCd language operates best with a deliberate overhead over the strictly necessary memory. Java’s GCs are quite “lazy” in that they will not collect unused objects until it is deemed necessary, which is in line with energy efficiency.
- jstimpfle 4y ago
  But there is still no nice way to embed structures "flat" in arrays or other structures, right? If there was, I'd consider switching to Java as my main programming language. I don't understand much about the theory and practice of implementing a GC'ed language, but I figure the problem is "locking" such an embedded object, because it doesn't have an obvious reference. One could take its enclosing object's reference but I suppose that leads to complications. What about functions that need a pointer to an embedded object in order to read or write to it? etc. I've had only short encounters with Java, but it (OpenJDK) did bite me in 2016, when I had to process millions of entities. I'd often run into low-memory situations and my machine would completely lock up for a minute or so, before the GC would give up and terminate the process. There was no nice way to solve the issue, other than allocating all my entities SOA style. This helped with the GC problem since it reduced my GC object count from #entities to #columns. But it isn't nice to read/write the code like that, nor is it good for the cache splitting up every little integer. I hear that GC's have improved much recently, removing the performance issues almost entirely. However, I believe the problem remains that a lot of code is harder to write because you can't simply pass a pointer + length to a function or do a memcpy. I figure this is one reason why there is so much abstraction in Java, with proxy objects and virtual methods and the like. If the "embedding" problem did not exist, there might not even be such a great need for GC rocket science, because there was a lot less need to have millions of objects in the first place.
  - eurasiantiger 4y ago
    If your structures are simple data with no methods, serialize them to BSON and store them as String. I’m half-joking, unfortunately.
kingkongjaffa 4y ago
Surely just short-circuit this by running your apps on servers powered by sustainability focused renewables energy sources.
nindalf 4y ago
Please, for the love of God, can we ignore this useless paper? It has no new insights. It simply takes the Benchmarks Game and concludes that the ones that are fastest also consume least energy. Benchmarks Game is a fun exercise to kill some time on, but it doesn't indicate anything about anything. The solutions across different languages don't even have the same algorithmic complexity. How can these possibly be compared?
- danuker 4y ago
  What would you see as a "fair" benchmark? Here's another, for the server use case: https://www.techempower.com/benchmarks/#section=data-r21&test=composite https://www.techempower.com/benchmarks/#section=data-r21&tes... I am stunned that a JS tool came out on top.
  - nindalf 4y ago
    There are no fair benchmarks between programming languages. > When a measure becomes a target, it ceases to be a good measure. If you're deciding what language to use for your next project, there are better ways. Ask yourself these questions. - Can developers be hired/trained to use it? - Will they be happy using it? - What will our development velocity be on this language? What will be the operational burden of keeping it running in production? - Do we need to rely on third party code? Does that code already exist and what is it's quality? Importantly, how will the answers to these questions change over time? Will this language be just as easy to hire for in 5 years time? Comparing languages by benchmarks is a waste of time.
    - galangalalgol 4y ago
      Were those prioritized? I would have put velocity first,then will devs like it. Those are coupled. If they like it, it is less important if you can hire people who know it already, and likewise, if your velocity is high, maintainability becomes less important. All those are subject to physical constraints though. Much of the worlds code is embedded, and thus severely constrained in both compute and power. That limits your choices, but within those choices your criteria are still absolutely the correct ones.
deleted 4y ago
[deleted]
londons_explore 4y ago
For most businesses, a good chunk of their compute costs are energy costs, directly or indirectly (eg. via cooling, or via paying for cloud hosting from someone else who pays the energy bill). Therefore, the real question becomes: Which language will reduce my compute budget most?
bob1029 4y ago
I think the answer for efficiency in programming is to reduce the total number of servers, data centers and bandwidth required to deliver the solution. Picking a programming language has virtually no bearing on this. There are certainly some languages that can run faster in some scenarios, but these microbenchmarks have little relevance to any practical reality at scale. For me, I like to go though hell instead of around it. Don't try to make one server sip the power obsessively. Make that one server do as much as possible, since you are already paying a fixed, idle power cost. I think picking things like SQLite vs SQL Server have a much bigger impact on power consumption. These are less disruptive choices than swapping programming languages as well.
- zozbot234 4y ago
  > Picking a programming language has virtually no bearing on this. How so? Usage of, e.g. RAM and memory bandwidth shows huge variation depending on which programming languages are chosen - and that tends to be the most relevant bottleneck wrt. aggregating workloads onto a single server, or a limited number thereof.
- skohan 4y ago
  But things like PL choice are a tool in the toolbox if you are trying to reduce the number of servers you use. If your PL is extremely memory hungry, or doesn't parallelize efficiently, you're going to bottleneck a lot sooner.
752963e64 4y ago
pmayrgundter 4y ago
But be careful to not conclude that we ought to use more efficient languages to save resources. Remember Jevons' Paradox: Efficiency leads to higher consumption, because that which is efficient will be used more, which in turn leads to higher consumption of the fuel by which its efficient use is measured. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
- skohan 4y ago
  Yeah but it's still a net benefit as you provide more value for the same amount of resources
  - pmayrgundter 4y ago
    Yep!
skohan 4y ago
It seems like a legitimate problem that JavaScript, probably one of the languages with the most code executed worthwhile, is down toward the bottom. I honestly wonder how much time and energy capacity could be freed up world wide if we just used tools optimized for hardware and network performance and efficiency.
netjiro 4y ago
Profiling code optimisation in joules is a fun and somewhat unusual task. Surprisingly it has come up both for the high end in a supercomputing project and at the very low end embedded. Having an execution budget in handfuls of joules is just weird, and fun.
nivertech 4y ago
Bitcoin Script[1] is probably the least efficient, then languages like Solidity[2] targeting Ethereum's EVM. [1] https://en.bitcoin.it/wiki/Script https://en.bitcoin.it/wiki/Script https://www.pcmag.com/encyclopedia/term/bitcoin-script https://www.pcmag.com/encyclopedia/term/bitcoin-script [2] https://docs.soliditylang.org/en/v0.8.17/ https://docs.soliditylang.org/en/v0.8.17/
dang 4y ago
Related: Energy Efficiency across Programming Languages [pdf] - https://news.ycombinator.com/item?id=24642134 https://news.ycombinator.com/item?id=24642134 - Sept 2020 (158 comments) Energy Efficiency Across Programming Languages - https://news.ycombinator.com/item?id=21950341 https://news.ycombinator.com/item?id=21950341 - Jan 2020 (1 comment) Energy Efficiency Across Programming Languages (2017) [pdf] - https://news.ycombinator.com/item?id=19618699 https://news.ycombinator.com/item?id=19618699 - April 2019 (1 comment) Energy Efficiency Across Programming Languages - https://news.ycombinator.com/item?id=15249289 https://news.ycombinator.com/item?id=15249289 - Sept 2017 (139 comments)

79 points by g42gregory 4y ago

Note: this is from 2017.

I've seen some comments on twitter (like this one [0]) that are saying that the complexity of programs in different languages is not the same and that is impacting results. Is someone willing to develop this for me (since I don't really know any other language here other than Python)? Bonus: here's "Ranking Programming Languages by Energy Efficiency", from 2021 [1] [0]: https://twitter.com/Czaki_PL/status/1569636020475265025 https://twitter.com/Czaki_PL/status/1569636020475265025 [1]: https://haslab.github.io/SAFER/scp21.pdf https://haslab.github.io/SAFER/scp21.pdf

ranguna 4y ago
I really need to pickup on rust
hither_shores 4y ago
The linked c code sample sorts the array, then accumulates the unique elements in a single pass. The python code sample makes a separate pass over `unique` for every element of `items`.
- Genmutant 4y ago
  The python code also prints the resulting list in the same order. It's a completely different problem to solve. In python I would throw the list in a set and return the size of it / print that.

rahen 4y ago

Previous submission: https://news.ycombinator.com/item?id=32485886 https://news.ycombinator.com/item?id=32485886

misja111 4y ago

I see similar postings coming by on LinkedIn now and then. Although there is some value in the benchmark results, the way these results are promoted is such a BS. If your company's business is really in running some algorithms similar to binary search or the n-body problem, you should probably not be checking which language to choose that is most energy efficient, but which library or framework suits you the best. E.g you can perfectly well use Python + Pandas or NumPy even though everybody will agree that Python in itself is terribly inefficient. If you really want to go to the extreme in saving energy you should go all the way and code your algorithms in assembly. But it's obvious why this is probably not a very wise choice. Everybody who knows a bit about IT will understand this, but the danger is that some project managers will read one of these papers and draw the conclusion that the team should switch to C or Rust because it is more sustainable ..

c_o_n_v_e_x 4y ago
I'm also seeing this trend as well.. "Software needs to be made more energy efficient." Usually this comment is coming from disgruntled data center designers who feel like they are unfairly being forced to eek out more efficiency when the onus should be the IT manufacturers and SW developers. This attitude is somewhat justified as it is possible to run servers at much warmer temps, but the DC industry (namely their customers) still continue to insist on SLAs that have unreasonably low air temperature set points. IMO, the first wave of optimizing software for energy consumption has already happened via virtualization. Ideally, I can run the same workload with less metal/watts. I feel like the next round of optimization will be more problematic. You could re-write software to take advantage of hardware acceleration features that are baked into the silicon to ideally speed things up/reduce power consumption, however this comes with its own issues. You need to be very familiar with your hardware. Integrating much more tightly means your married to your metal... kinda like CUDA lock-in in the GPU ecosystem.
- josephg 4y ago
  > You need to be very familiar with your hardware. Integrating much more tightly means your married to your metal I don’t know how true it is in the HPC space, but the more optimization work I do the more I realise how horribly inefficient 99% of programs are. Most devs these days just don’t care about making software fast, and when they do they have no idea where to start or what will help. Last year I spent some time optimising CRDTs (used in collaborative text editing). Automerge (a well known library) took 5 minutes to run a certain benchmark. Yjs (considered a mature, well performing library) took 1 second to run the same test. After spending some time optimizing, I have code now which can do the same work in 4 milliseconds. I’m not using any special hardware - this is just in straight forward rust. The remarkable part is that automerge isn’t written in an uncharacteristically bad way. Sure, it uses immutablejs - but plenty of modern javascript programs do something very similar. Even yjs, despite being the target of some careful optimization work, is still 200x slower than it could be. - and thus, wasting 99.5% of its energy budget. If even yjs can be sped up by 200x, how much do you think most enterprise software could be sped up, if people tried? 500x? 10000x? I don’t think we need deeper integration with hardware. We just need more software developers who care at all about performance. Virtualisation wipes out 20%+ of the performance of the machine, depending on what you’re doing. But we pay that cost gladly because it’s marginally easier than sharing a Linux kernel between multiple processes. I think if our CPUs had capped out 50x slower than they are today, the average user would hardly notice any difference. The only difference would be that software would be more expensive to make, because software engineers would need to actually understand how the computer works to make software perform. Things like the virtual DOM wouldn’t be fast enough to use at scale. Video games and zoom wouldn’t be quite as pretty. But we’d live.

montebicyclelo 4y ago

The code from this study is here: https://github.com/greensoftwarelab/Energy-Languages https://github.com/greensoftwarelab/Energy-Languages From looking at the code snippets, a big issue with this study becomes clear - it doesn't reflect how languages like Python are used in practice. In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/... i.e. Python code usually makes use of a vast ecosystem of optimized science/maths/data science libraries. Whereas the study code is mainly using pure Python. It's an issue with the methodology that the programs are written specifically for this study; creating an artificial situation.

zekrioca 4y ago
> In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/ How would this be comparing apples to apples? The paper’s main objective is to compare programming languages in their own native calls. It is like properly translating the Bible or Shakespeare to other languages: some translations will be more textual than others, loosing all the nuances, specially if compared to the original transcript. If you have python glue calls to other processes written in other languages, then you would be creating noisy in results. It is not the purpose of the paper at all, and it is outside of its scope.
g42gregory 4y ago
That is a really good point about Python being a connector language and internal API implementations done in C/C++/Fortran/etc... It kind of makes me question the entire premise of this paper.
alcover 4y ago
Forgive my pedantry but the ecosystem is not the language. Nor is practice. Ad absurdum, you could include the hardware pythonists usually employ. If you use python as glue, it should be compared to other languages used as glue.
- montebicyclelo 4y ago
  Is it not fair enough to use ubiquitous libraries in the code for this test? E.g. look at the n bodies code.. someone trying to write efficient Python code would be using NumPy at the very least (and possibly Numba).

Neil44 4y ago

PHP looks horrific for energy use although it would have been 5.x in 2017. Think about all those PHP websites out there spending all day serving requests to bots and brute forcers. That's a lot of energy.

sdze 4y ago
Rasmus Lerdorf promotes PHP8 as CO2 reducing update. I agree. You can serve many more visitors with the same server hardware.
kaba0 4y ago
Well, those websites just wait for the OS most of the time, not using any energy. These benchmarks may not be representative for PHP as the usual way of operation for it is not some hot loop numerical compute done continuously.

whizzter 4y ago

JavaScript and TypeScript yield different results, there could be reasons like backwards compatibility transpilation but that's an option, otherwise code should be identical if written for performance.

HoolaBoola 4y ago
One of the JavaScript programs at least was concurrent, whereas the TypeScript equivalent was synchronous. No wonder there's a difference... Haven't looked closely at the other problems, but it's apparent to me that the solutions are not even trying to be similar, so comparing their efficiency is near useless. the problem in question was the k-nucleotide one, IIRC: https://github.com/greensoftwarelab/Energy-Languages/blob/1356528173d6bb07fb2512037c0ed8e2279ce440/JavaScript/k-nucleotide/knucleotide.node-2.node https://github.com/greensoftwarelab/Energy-Languages/blob/13...
igouy 4y ago
Maybe the JavaScript wouldn't type check with TypeScript.

guiriduro 4y ago

Interesting, but I'd be more interested in the holistic, total energy cost of a particular language choice. Only where the program is highly compute-bound and is run for many parallel instance-hours, would an analysis like this help to determine the best options, like e.g. the language used for a widely-used spreadsheet program. In a more 'real life' case, the energy costs of developer-hours also needs to be amortised (their dev machines, their coffees & pizzas, the light and heating of their home/office, maybe travel to office etc.) which is much more conditioned by the productivity of the language for the problem domain. In many cases, the production energy use of a given language is miniscule in that totality, so only where it is a significant component should it be part of language selection criteria.

wilmajacob 4y ago

JonChesterfield 4y ago

A colleague looked into improving energy efficiency of software as a academic project. Concluded that it's essentially the same problem as optimisation. Making the program/task finish sooner was by far the biggest contributor to energy saving, so the techniques for reducing energy consumption are those of program optimisation.

kaba0 4y ago
That’s the reason for mobile devices’ processor setup. There is a race to sleep with regards to CPUs.
GrumpySloth 4y ago
Except SIMD code while faster may sometimes be less energy-efficient than scalar code. Different SIMD extensions have different energy efficiency characteristics. Also, multithreaded code may finish a task sooner, but spend more energy budget due to costs of synchronisation, spawning and joining threads, etc.
- JonChesterfield 4y ago
  Nice point. I'll add it to the list of reasons to avoid multi-threading things wherever possible!

kaba0 4y ago

It’s crazy how good Java is at energy efficiency. It is criminally underhyped and are sometimes replaced by the new best PL that will change everything, and yet it is very unlikely to have better results besides the inherent one in the rewrite. Also, the often claimed negative of Java, memory overhead is relevant here — a GCd language operates best with a deliberate overhead over the strictly necessary memory. Java’s GCs are quite “lazy” in that they will not collect unused objects until it is deemed necessary, which is in line with energy efficiency.

jstimpfle 4y ago
But there is still no nice way to embed structures "flat" in arrays or other structures, right? If there was, I'd consider switching to Java as my main programming language. I don't understand much about the theory and practice of implementing a GC'ed language, but I figure the problem is "locking" such an embedded object, because it doesn't have an obvious reference. One could take its enclosing object's reference but I suppose that leads to complications. What about functions that need a pointer to an embedded object in order to read or write to it? etc. I've had only short encounters with Java, but it (OpenJDK) did bite me in 2016, when I had to process millions of entities. I'd often run into low-memory situations and my machine would completely lock up for a minute or so, before the GC would give up and terminate the process. There was no nice way to solve the issue, other than allocating all my entities SOA style. This helped with the GC problem since it reduced my GC object count from #entities to #columns. But it isn't nice to read/write the code like that, nor is it good for the cache splitting up every little integer. I hear that GC's have improved much recently, removing the performance issues almost entirely. However, I believe the problem remains that a lot of code is harder to write because you can't simply pass a pointer + length to a function or do a memcpy. I figure this is one reason why there is so much abstraction in Java, with proxy objects and virtual methods and the like. If the "embedding" problem did not exist, there might not even be such a great need for GC rocket science, because there was a lot less need to have millions of objects in the first place.
- eurasiantiger 4y ago
  If your structures are simple data with no methods, serialize them to BSON and store them as String. I’m half-joking, unfortunately.

kingkongjaffa 4y ago

Surely just short-circuit this by running your apps on servers powered by sustainability focused renewables energy sources.

nindalf 4y ago

Please, for the love of God, can we ignore this useless paper? It has no new insights. It simply takes the Benchmarks Game and concludes that the ones that are fastest also consume least energy. Benchmarks Game is a fun exercise to kill some time on, but it doesn't indicate anything about anything. The solutions across different languages don't even have the same algorithmic complexity. How can these possibly be compared?

danuker 4y ago
What would you see as a "fair" benchmark? Here's another, for the server use case: https://www.techempower.com/benchmarks/#section=data-r21&test=composite https://www.techempower.com/benchmarks/#section=data-r21&tes... I am stunned that a JS tool came out on top.
- nindalf 4y ago
  There are no fair benchmarks between programming languages. > When a measure becomes a target, it ceases to be a good measure. If you're deciding what language to use for your next project, there are better ways. Ask yourself these questions. - Can developers be hired/trained to use it? - Will they be happy using it? - What will our development velocity be on this language? What will be the operational burden of keeping it running in production? - Do we need to rely on third party code? Does that code already exist and what is it's quality? Importantly, how will the answers to these questions change over time? Will this language be just as easy to hire for in 5 years time? Comparing languages by benchmarks is a waste of time.
  - galangalalgol 4y ago
    Were those prioritized? I would have put velocity first,then will devs like it. Those are coupled. If they like it, it is less important if you can hire people who know it already, and likewise, if your velocity is high, maintainability becomes less important. All those are subject to physical constraints though. Much of the worlds code is embedded, and thus severely constrained in both compute and power. That limits your choices, but within those choices your criteria are still absolutely the correct ones.

deleted 4y ago

[deleted]

londons_explore 4y ago

For most businesses, a good chunk of their compute costs are energy costs, directly or indirectly (eg. via cooling, or via paying for cloud hosting from someone else who pays the energy bill). Therefore, the real question becomes: Which language will reduce my compute budget most?

bob1029 4y ago

I think the answer for efficiency in programming is to reduce the total number of servers, data centers and bandwidth required to deliver the solution. Picking a programming language has virtually no bearing on this. There are certainly some languages that can run faster in some scenarios, but these microbenchmarks have little relevance to any practical reality at scale. For me, I like to go though hell instead of around it. Don't try to make one server sip the power obsessively. Make that one server do as much as possible, since you are already paying a fixed, idle power cost. I think picking things like SQLite vs SQL Server have a much bigger impact on power consumption. These are less disruptive choices than swapping programming languages as well.

zozbot234 4y ago
> Picking a programming language has virtually no bearing on this. How so? Usage of, e.g. RAM and memory bandwidth shows huge variation depending on which programming languages are chosen - and that tends to be the most relevant bottleneck wrt. aggregating workloads onto a single server, or a limited number thereof.
skohan 4y ago
But things like PL choice are a tool in the toolbox if you are trying to reduce the number of servers you use. If your PL is extremely memory hungry, or doesn't parallelize efficiently, you're going to bottleneck a lot sooner.

752963e64 4y ago

pmayrgundter 4y ago

But be careful to not conclude that we ought to use more efficient languages to save resources. Remember Jevons' Paradox: Efficiency leads to higher consumption, because that which is efficient will be used more, which in turn leads to higher consumption of the fuel by which its efficient use is measured. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox

skohan 4y ago
Yeah but it's still a net benefit as you provide more value for the same amount of resources
- pmayrgundter 4y ago
  Yep!

skohan 4y ago

It seems like a legitimate problem that JavaScript, probably one of the languages with the most code executed worthwhile, is down toward the bottom. I honestly wonder how much time and energy capacity could be freed up world wide if we just used tools optimized for hardware and network performance and efficiency.

netjiro 4y ago

Profiling code optimisation in joules is a fun and somewhat unusual task. Surprisingly it has come up both for the high end in a supercomputing project and at the very low end embedded. Having an execution budget in handfuls of joules is just weird, and fun.

nivertech 4y ago

Bitcoin Script[1] is probably the least efficient, then languages like Solidity[2] targeting Ethereum's EVM. [1] https://en.bitcoin.it/wiki/Script https://en.bitcoin.it/wiki/Script https://www.pcmag.com/encyclopedia/term/bitcoin-script https://www.pcmag.com/encyclopedia/term/bitcoin-script [2] https://docs.soliditylang.org/en/v0.8.17/ https://docs.soliditylang.org/en/v0.8.17/

dang 4y ago

Related: Energy Efficiency across Programming Languages [pdf] - https://news.ycombinator.com/item?id=24642134 https://news.ycombinator.com/item?id=24642134 - Sept 2020 (158 comments) Energy Efficiency Across Programming Languages - https://news.ycombinator.com/item?id=21950341 https://news.ycombinator.com/item?id=21950341 - Jan 2020 (1 comment) Energy Efficiency Across Programming Languages (2017) [pdf] - https://news.ycombinator.com/item?id=19618699 https://news.ycombinator.com/item?id=19618699 - April 2019 (1 comment) Energy Efficiency Across Programming Languages - https://news.ycombinator.com/item?id=15249289 https://news.ycombinator.com/item?id=15249289 - Sept 2017 (139 comments)