A Comprehensive Study on the Energy Efficiency of Java Thread-Safe Collections [pdf] | Hacker News Reader

A Comprehensive Study on the Energy Efficiency of Java Thread-Safe Collections [pdf]

gustavopinto.github.io

50 pointsghlp30 comments

Great work! Let's hope this is an early contribution to a novel way of measuring computational complexity. Power drain, as much as time, is the scarce resource both in data centers and in mobile devices. It's great to think about measuring it.

Wouldn't it be great if our favorite IDEs showed a little yellow lightning bolt indicating suggestions for reducing the power-consumption profile of the code? Some of it could be obvious stuff (StringBuffer in place of string + string in loops, for example). But nonobvious stuff could be flagged too.

Of course, I hope the authors or others will try the same sorts of things on low-power mobile processors, and with workloads closer to the real world.

I set that linting rule in JavaScript. My entire app shows up as a lightning bolt.

Wish I could upvote this twice. The trend of using electron for desktop apps seems to waste a lot of battery and RAM. Between Atom and Slack I was losing between 3 and 5 GB of RAM. Ended up going back to Sublime and it rarely exceeds 300MB.

You really should go back to vim

Upvoted it for you. The current proliferation of web bloat is getting ridiculous.

The best way of making them go away is not to use them.

I only open an exception to VS Code, because it is currently the best experience to edit Rust code.

Yup, this! I like to have one GUI editor on my machine (I open it once month, because I live in iTerm with tmux and vim) and people on reddit convinced me to give Atom a shot. It has some really neat ideas, but in the end it is such a hog, so I deleted it. I cannot recommend electron as platform to anybody at this right moment. Some elctron apps used more resources and energy than IntelliJ Idea, which is ridiculous considering usage and specter of things that those programs are covering.

I wish caching patterns are something IDEs would predict :D

They don't need to, they just need access to profiling data from (latest?) run (could be test run, benchmark run, staging run etc).

True, but I would have to setup the profiling. Setting up a load generation pattern and a load tool would do the job on a local environment, but this is an obviously involved process that requires looking at the generated profile, response times and such. But, does not tell me an in-lined function is missing the cache a lot and slowing things down?

Where I work the IDE does indeed present this information prominently, if you consider raw cpu usage to be a decent approximation for energy consumption. A function using more than a certain amount of cpu in production is annotated with a little mark and if someone changes it the change review system brings the cost of the code to the attention of the reviewer so they have efficiency in mind when reading proposed changes.

Sounds impressive - is this a publicly available ide?

No it is a company-specific hack. The relevant thing would be to have the profile data to begin with. Then you can work that into whatever annotation scheme your IDE offers.

Great - reading between the lines that would require

a. Gathering perf data in prod at scale

b. Aggregating it and mapping it back to source

c. Having that available within the IDE

Looks like youre working for a surprisingly clueful employer if they are doing all of the above.

Since Roslyn there is a compiler plugin that does something like that for .NET, I don't remember the name now.

I recently had a little feud with the developers of react-native and fresco (the Facebook image loading library) because of their extensive use of Finalizers:

https://github.com/facebook/fresco/issues/1363

https://github.com/facebook/react-native/issues/8780

Apart from being unreliable, bad design, it slows GC and instantiation by orders of magnitude, which I considered important, but they did not.

I added a comment about how uninstalling the Facebook app improves the battery life of a phone dramatically, that I deleted afterwards because it was too flamy.

I don't expect this to get fixed ever :(.

In broad strokes, what are the most energy costly parts of a computation? One must be particularly bad... I'm guessing CPU activity, because it generates the most heat? If you broke it down further, what's the most expensive parts of it?

What causes divergence between energy efficiency and time complexity? I would expect both roughly scale proportionate to the number of instructions executed.

Looking forward to the days I can compile code with a "-Oe" to optimize for energy efficiency. ;-)

You laugh. Between servers and mobile that option is long overdue.

Oh, it'd be nice, but it probably makes more sense to have handle that kind of thing with a JIT runtime.

I'm surprised I got downgraded. What is most power efficient varies a lot not just based on machine, but based on the machine context.

-O3 is probably an excellent approximation. Faster programs tend to use less energy.

Spin locks are not very power efficient.

Not necessarily true. Please check: http://arcade.cs.columbia.edu/energy-oopsla14.pdf

-O3 unlocks a number of optimizations that are kind of the opposite of power efficient... at least, depending on the CPU that executes them.

If we're going for least energy, wouldn't it make sense to compare amongst languages? If it were one of my requirements I would not take Java as a given. I would also not take C++ as a given. I'd measure and choose.

Part of the reason could be 1) Android and 2) even excluding Android, Java is immensely popular for small, low-power systems.

Thanks for posting this. Because of it I just remembered that I saved a slightly similar link [1] and the github repo of the used jvm/scala library [2] into my bookmarks years ago, but haven't read them yet.

[1] https://hal.inria.fr/hal-00681560v3/document

[2] https://github.com/Spirals-Team/powerapi

This is very useful, but I hope they publish the code to perform this test. Sunacle changes stuff all the time to increase performance, and the numbers will change over time.

Wow! This is super-nerdy! Love it.

Reply on news.ycombinator.com