Today we’re pleased to announce the first release of
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
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
addSbtPlugin("com.47deg" % "sbt-energymonitor" % "0.1.3")
So is it time now to measure all the things? Maybe not! There are quite a few caveats for using this plugin.
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
- 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.
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.