Announcing sbt-energymonitor

• by James Santucci
• •
• March 09, 2022
• •
• scala• green software• sbt
• |
• 4 minutes to read.

Today we’re pleased to announce the first release of sbt-energymonitor, a plugin for tracking energy consumption during Scala build tasks.

The purpose of the plugin is to provide sbt tasks for sampling energy consumption before and after running other tasks, so you can see how much energy your tests take. For example, in a toy repository I created for learning about droste, when I run energyMonitorPreSample;test;energyMonitorPostSample, I see:

sbt:droste-playground> energyMonitorPreSample;test;energyMonitorPostSample
[success] Total time: 0 s, completed Mar 3, 2022, 8:38:09 AM
io.github.jisantuc.drosteplayground.PlaygroundTestSuite:
  + solve the sample puzzle with explicit recursion 0.011s
  + solve the sample puzzle with rec schemes 0.013s
[info] Passed: Total 2, Failed 0, Errors 0, Passed 2
[success] Total time: 0 s, completed Mar 3, 2022, 8:38:09 AM
[info]  During CI attempt -1, this run consumed power from 4 CPU cores.
[info]
[info]  The total energy consumed in joules was 4.17.
[info]
[info]  In the sampling period, mean power consumption was 31.14 watts.
...

To get it, you can add it as an sbt plugin in your project/plugins.sbt file like so:

addSbtPlugin("com.47deg" % "sbt-energymonitor" % "0.1.3")

This plugin follows in the footsteps of benchmarking work done by the Green Software Lab and extensions to that work done by Julien Richard-Foy and Wojciech Mazur at The Scala Center.

So is it time now to measure all the things? Maybe not! There are quite a few caveats for using this plugin.

Caveats

The first is that, because it uses data from RAPL, you can only run the plugin on computers with an Intel processor. That’s not terrible, given Intel’s prevalence in laptops, desktops, and server environments.

The second caveat though is that you can’t run the plugin on a Mac or in the Windows Subsystem for Linux. Neither MacOS nor WSL has the modules available for obtaining power information from RAPL, so you’ll need an actual Linux laptop. Maybe this limitation will tip the scales in the silly tech Twitter argument of the week.

So, ok, we’ve knocked out WSL and MacOS and non-Intel processors . . . but it’s

1. It’s never been easier to spin up an Ubuntu VM in the cloud, and a lot of cloud providers offer VMs running on Intel CPUs; what about those? Well, the third caveat is that virtualization also causes problems for running the plugin. I wrote a comment about that in the PR adding the sampling tasks, but the short version is that, even on AWS EC2 instances that definitely have RAPL available, you still can’t make the calls.

So what can you do?

All those caveats aside, it’s still exciting to be able to measure energy consumption during test runs. Having the data available means you can ask questions like, “Suppose I ask Scalacheck for 20 examples instead of 100. How much less energy would I consume?” Over time, something like best practices for sustainable Scala might emerge based on energy utilization in non-benchmark code.

Next steps

Since power consumption will vary with the particulars of your computer’s hardware, results won’t be comparable between developers on your team, and centralized single source of truth energy statistics won’t be a possibility until it’s easy to measure in a continuous integration setting.

However, there are some easier improvements possible. First, the monitor in use in the plugin exposes other information, like GPU and DRAM energy consumption. Those aren’t part of the printed report right now, but they could be.

Second, the results don’t go anywhere right now, just to the console or, if you manually configure some GitHub environment variables, into a pull request comment. Creating some kind of persistence service would enable people to track progress over time and highlight changes that made a big difference.

For now though, you can install the plugin and measure! First measurements won’t mean anything, but if you have a few long-running tests that don’t seem to test much that you’ve been itching to banish from your codebase, maybe the energy they consume will be the last straw.