Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reworking 30 lines of Linux code could cut power use by up to 30 percent

spectrum.ieee.org

Post reply on HN
Print view View original

71–80 of 123 posts

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#71

Post by queuebert »

jeffbee wrote: post #40
toomuchtodo wrote: post #28

Earlier quoted context omitted.

My experience with HPC is only tangential to being a sysadmin for data taking and cluster management for a high energy physics project; I am interested on your thoughts about using generative AI to search out for potentially power inefficient code paths in codebases for potential improvement.

Don't send an LLM to do a profiler's job.

I agree with this.

For the completely uninitiated, taking the most critical code paths uncovered via profiling and asking an LLM to rewrite it to be more efficient might give an average user some help in optimization. If your code takes more than a few minutes to run, you definitely should invest in learning how to profile, common optimizations, hardware latencies and bandwidths, etc.

With most everything I use at the consumer level these days, you can just feel the excessive memory allocations and network latency oozing out of it, signaling the inexperience or lack of effort of the developers.

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#72

Post by eichin »

ryao wrote: post #5

Linux added a busy polling feature for high performance networking. Most Linux software does not use it, but software used in datacenters (e.g. by CDNs) that does use it makes the system very energy inefficient when things are not busy. This patch gives the the kernel the ability to turn that off when not busy to regain energy efficiency until things become busy again. The article name is somewhat misleading, since i…

heh, will this become the equivalent of "in mice" for bio papers?

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#73

Post by teddyh »

Jeaye wrote: post #52

Niiice. What if we reworked 100 lines?

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?”

“It will take one year,” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.

— Chapter 3.4 of The Tao of Programming, by Geoffrey James (1987)

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#74

Post by ssuds »

Key paragraph: "This energy savings comes with a caveat. “It is sort of a best case because the 30 percent applies to the network stack or communication part of it,” Karsten explains. “If an application primarily does that, then it will see 30 percent improvement. If the application does a lot of other things and only occasionally uses the network, then the 30 percent will shrink to a smaller value.”"

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#75

Post by jeffbee »

consumer451 wrote: post #69
adrianN wrote: post #67

Earlier quoted context omitted.

I would hope that the hyperscalers have sufficient economic incentive to optimize this without an X-prize.

One would hope, but when I last gave this some thought... If you are in the C-suite, and could deploy your best devs to maybe save some unknown % on energy costs, or have them work on a well-defined new feature that grows your ARR 5% next year, which would you do? Also, would you share all new found efficiencies with your competitors?

At a large business the 1% cost savings is going to be a lot easier to find than the 5% revenue growth.

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#76

Post by jeffbee »

linsomniac wrote: post #39

Does this mean that "adaptive interrupt mitigation" is no longer a thing in the kernel? I haven't really messed with it in ~15+ years, but it used to be that the kernel would adapt, if network rate was low it would use interrupts, but then above a certain point it would switch to turning off interrupts and using polling instead. The issue I was trying to resolve was sudden, dramatic changes in traffic. Think: a loop…

Adaptive IRQ moderation is a hardware feature. https://edc.intel.com/content/www/us/en/design/products/ethe...

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#77

Post by jeffbee »

secondcoming wrote: post #49

I thought that Intel added the ‘pause’ instruction to make busy spinning more power friendly

x86 has always had PAUSE, what they did is they made the PAUSE way longer in Skylake-X which threw everyone off guard. But yeah, x86 ISA extensions cover this ground very well. Atom, the low-power server line, introduced UMWAIT and TPAUSE that enable cores to briefly enter a power-saving active state while waiting for something to happen. These instructions later came to mainstream Core and Xeon CPUs because Intel made those frankenchips with Atoms and Cores together.

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#78

Post by p_l »

Denvercoder9 wrote: post #65
fnordpiglet wrote: post #32

Earlier quoted context omitted.

It’s a lot more nuanced than that. Being in a data center doesn’t imply heavy network utilization. The caveat is clearly outlined in the article being workload based not deployment based. If you have a home machine doing network routing it would absolutely benefit from this. In fact I would say probably the vast majority of Linux installs are home network devices, just people don’t know it. Embedded Linux machines do…

> If you have a home machine doing network routing it would absolutely benefit from this. It most likely won't. This patch set only affects applications that enable epoll busy poll using the EPIOCSPARAMS ioctl. It's a very specialized option that's not commonly used by applications. Furthermore, network routing in Linux happens in the kernel, not in user space, so this patch set doesn't apply to it at all.

NAPI is not busy poll, though, and the way the article is worded suggests it's about NAPI.

Now, NAPI already was supposed to have some adaptiveness involved, so I guess it's possibly a matter of optimizing it.

But my system is compiling for now so will look at article more in depth later :V

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#79

Post by timewizard »

queuebert wrote: post #7

This is really cool. As a high-performance computing professional, I've often wondered how much energy is wasted due to inefficient code and how much that is a problem as planetary compute scales up. For me, it feels like a moral imperative to make my code as efficient as possible, especially when a job will take months to run on hundreds of CPU.

> I've often wondered how much energy is wasted due to inefficient code and how much that is a problem as planetary compute scales up.

I personally believe the majority is wasted. Any code that runs in an interpreted language, JIT/AOT or not, is at a significant disadvantage. On performance measurements it's as bad as 2x to 60x worse than the performance of the equivalent optimized compiled code.

> it feels like a moral imperative to make my code as efficient as possible

Although we're still talking about fractions of a Watt of power here.

> especially when a job will take months to run on hundreds of CPU.

To the extent that I would say _only_ in these cases are the optimizations even worth considering.

Re: Reworking 30 lines of Linux code could cut power use by up to 30 percent

#80

Post by ori_b »

tuetuopay wrote: post #45
taeric wrote: post #34

Earlier quoted context omitted.

I was curious how much this would be applicable to home routers. I confess I'm dubious on major savings for most home users, though? At least, at an absolute level. 30% of less than five percent is still not that big of a deal. No reason not to do it, but don't expect to really see the results there.

Practically none of it would be applicable (if using a commercial router). They all use hardware offloading, and traffic seldom touches the CPU. Only "logical" tasks are raised to the CPU, like ARP resolution and the likes (what’s called "trap to cpu"). If you’re doing custom routing with a NUC or a basic Linux box, however, this would gain massive power savings because that box pretty much only does networking.

Only if you're using busy polling. Very little software uses it, because it's only a good fit if you think pegging a CPU to reduce latency responding to packets is a good trade.
Post reply on HN