I Have a dream! a Green dream -- Does Julia save energy?

I wouldn’t feel too bad about CI. Let’s do a bit of fun order of magnitude analysis!

  • Your average laptop draws ten to a few tens of Watts at idle. Let’s overestimate at 100W at max load.
  • My typical packages take less than a minute to run through tests. Arguably for a good dev experience it should be < 10s, perhaps, but let’s call it 100s.
  • Let’s imagine several CI configurations for different Julia versions and operating systems. 10, say.

So all up, a single CI run is 100J/s * 100s * 10 = 100kJ which is probably an overestimate for most (but not all packages) I’ve written. For comparison:

  • That’s about the chemical energy in a small tomato
  • The typical human needs on the order of approximately 10_000 kJ per day of food energy. That’s ~100 CI runs per day per person, or at least tens of CI runs even if you’re starving.
  • There’s around 30_000 kJ of chemical energy in a litre of gasoline which is ~300 CI runs. If you’re willing to drive 5 km (0.25L of fuel, say) then you should be willing to do 75 CI runs!
  • The world average total energy usage per person is apparently around 20_000 kWh per year (See eg, Energy use per person - Our World in Data). This is ~200_000 kJ per day, or 2000 CI runs per day.

Largely, I don’t think computing is something the average user needs to be worried about! Other energy intensive human activities are much more concerning.

11 Likes

I’m not so sure about your calculations though - if that is so, why does mining cryptocurrencies use soooo much energy (more than some countries)

Server farms do use quite a bit of energy - so if you can get 10x - 100x more work done running Julia code rather than say, Python, wouldn’t that make a significant difference?

1 Like

That’s interesting to put computer activities in context, but I don’t think comparisons with unrelated domains make sense when considering the energy consumption of Julia specifically… It’s an excuse that can always be used, there’s always something else consuming more energy.

1 Like

for some values of “everybody”

1 Like

I think it absolutely makes sense to compare domains quantitatively, in terms of making life decisions “should I participate in this or that activity”.

If choosing Julia vs some other language is 1% or less of the energy used just to keep me living a normal life, then there’s no reason to waste time worrying about that choice.

2 Likes

I agree when considering my general choice of an activity, 1% is not that much. But if I can save 0.8% of my energy consumption just by switching language, and still accomplish my goals, that’s also very relevant! I think that’s the core question of this thread…

1 Like

To get back to the original topic here (which was a nice and positive message, thanks :slight_smile: )

I think it will be extremely difficult to quantitatively show that Julia saves energy. Things to consider:

  • Julia should be used “in production” as part of a large, potentially ongoing computation or a very widely deployed application. These are the cases where a significant amount of energy is actually used.
  • It should replace the fixed amount of work that another system was doing and do it more efficiently or better.

The hard part is that many systems don’t have a fixed amount of computational work to do. It seems we can always consume as much compute as possible given hardware and software improvements over many years. The actual limitation on energy use from computing seems more economic than computational.

For example HPC workloads do consume a lot of energy, but a lot of scientific workloads have the property that the simulation just expands to fill the compute available. Larger meshes, higher resolution, more samples. So the amount of energy used in these situations where Julia is great may be somewhat independent of the language, and more dependent on the budget to buy hardware and compute time. There’s better scientific return with the ability to do higher resolutions or whatever. But I think making a clear comparison is really difficult!

Crypto is another good example of where the practical energy usage of the system has nothing to do with computational efficiency of the components. Better efficiency just means the network adjusts to make hashing more difficult and the same total amount of energy is used. When bitcoin went to GPUs and then ASICs nothing really changed energy-wise. By design!

8 Likes
3 Likes

This has been discussed here some times. Although I agree mostly with the points of @c42f that it is not clear if these measures actually mean anything for the real-world use of energy in computing, there are these two studies:

In this one Julia is not initially present, but somewhere there one can find a link to an updated version in which Julia is included, and has a fair position:

And there is this Nature Astronomy commentary, which includes Julia:

https://www.su.se/department-of-meteorology/news/commentary-in-nature-astronomy-on-the-use-of-python-1.555475

3 Likes

Perhaps that’s not what this post is about, but it seems worthwhile to mention that Julia is very much used in green tech, from climate modelling to energy grid optimization. We’re using it as well in an industrial setting to reduce our client’s energy consumption. Those initiatives can move the needle a lot, even when the algorithms themselves take a lot of CPU time to run…

4 Likes

Here’s the broader research page for the previously linked ‘Which Programming Languages […]’ article: Original work in SLE'17

In the updated 2020 results, only Rust beats (or matches) Julia for low energy use: Original work in SLE'17 - Updated Functional results - 2020

If you interleave the 2020 results with the broader, original results, you’ll see Julia bested by C, Rust, C++, and Ada, but besting everyone else from OCaml to Fortran to Go to Java (especially considering the Java efficiency caveat detailed in: https://www.sciencedirect.com/science/article/abs/pii/S0167642321000022).

And I assume Julia has made efficiency improvements since v1.3.1 and will continue to improve, so pretty cool. I didn’t assume it would be energy efficient compared to compiled languages w/ GC.

3 Likes

> 100 minutes is common for the primary packages I work on.
Now, I’m suddenly concerned about the amount of energy I’m apparently using.
But I suspect they’re using much less than 100W, given that CI is restricted to a single core (2 threads).

3 Likes

You need to consider the other side of the coin. Julia being so efficient might lead people to write more code and thus use more energy.

3 Likes

AKA Jevon’s Paradox

2 Likes

This is great. Effectively a case where Julia is being used to make a fixed amount of work more efficient. And if it’s not computational work but an industrial process (or whatever), the amount of energy saved could be huge. (Assuming that your client has a fixed amount of work and they don’t scale up their operations until they’re using the same amount of energy again?)

Yeah, overconsumption and Jevon’s paradox make any kind of energy efficiency work a bit depressing, but there are other effects in play and hopefully it’s still worthwhile. Sigh.

2 ideas, where I think Julia has a strong potential to yield massive energy savings, if researchers extend Julia’s already excellent solvers/automatic differentiation and extend current research being done implemented in other languages, would be:

Extending Green Neural Architecture Search KNAS: Green Neural Architecture Search

Saving GPU-years of NAS can add up quickly.

Gradient estimation or more efficient gradient-free optimization/tuning of discrete simulators

Where I work we have (a thousand? more?) cloud VMs running nearly every day, running long (e.g. 6-CPU-hour per iteration) simulations of CPUs and GPUs in development. It’s not my day job, but I’ve been on the look-out for innovations (papers, etc) that would allow us to take these discontinuous/discrete simulations (often done using grid-search or primitive black-box-optimization) and somehow speed up the search, ideally using gradient estimation techniques so SGDs would “just work”. If anybody is aware of recent breakthroughs in this area (especially one Julia-based), I think in relatively little time I could rally some engineers in the company and rewrite some of the simulators from C++ to Julia to take advantage of it.

2 Likes

One thing which will save energy is choosing the correct type for calculations.
Look at the machine learning community with use of FLoat32 and the recent specific lower precision types from Nvidia.
I read a fantastic paper years ago on the topic of watts per instruction and choosing types - sadly I did not keep the reference. If anyone has it please let me know.

1 Like

Yeah, for sure, Int types (especially low-precision like Int4) are crazy cheap in area, power usage, etc. compared to Float16 or Float32. And at the extreme, binarizing a neural network can achieve an extra order of magnitude power and perf saving since multiplications get converted into adds, etc.

[2002.07795] Verified Instruction-Level Energy Consumption Measurement for NVIDIA GPUs

For GPU, Energy Consumption:

  • Double Precision > Half Precision > Single Precision ~ Integer
  • signed > unsigned
  • GPU architecture also has a significant impact

Of course, there is still space for improvement in half-precision.

1 Like