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

Introducing architecture variants

discourse.ubuntu.com

Post reply on HN
Print view View original

131–140 of 152 posts

Re: Introducing architecture variants

#131

Post by horizion2025 »

mobilio wrote: post #5

Announce was here: https://discourse.ubuntu.com/t/introducing-architecture-vari... and key point: "Previous benchmarks we have run (where we rebuilt the entire archive for x86-64-v3 57) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that."

How many additions have there even been outside of AVX-x? And even AVX-2 is from 2011. If we ignore AVX-x the last I can recall are the few instructions added in the manipulation sets BMI/ABM, but they are Haswell/Piledriver/Jaguar era (2012-2013). While some specific cases could benefit, doesn't seem like a goldmine of performance improvements.

Further, maybe it has not been a focus for compiler vendors to generate good code for these higher-level archs if few are using the feature. So Ubuntu's move could improve that.

Re: Introducing architecture variants

#132

Post by alkonaut »

wongarsu wrote: post #18
juujian wrote: post #8

Earlier quoted context omitted.

Are there any use cases where that 1% is worth any hassle whatsoever?

If every computer built in the last decade gets 1% faster and all we have to pay for that is a bit of one-off engineering effort and a doubling of the storage requirement of the ubuntu mirrors that seems like a huge win If you aren't convinced by your ubuntu being 1% faster, consider how many servers, VMs and containers run ubuntu. Millions of servers using a fraction of a percent less energy multiplies out to a lot…

If I recompile a program to fully utilize my cpu better (use AVX or whatever) then if my program takes 1 second to execute instead of 2, it likely did not use half the _energy_.

Re: Introducing architecture variants

#133

Post by darkwater »

alkonaut wrote: post #132
wongarsu wrote: post #18

Earlier quoted context omitted.

If every computer built in the last decade gets 1% faster and all we have to pay for that is a bit of one-off engineering effort and a doubling of the storage requirement of the ubuntu mirrors that seems like a huge win If you aren't convinced by your ubuntu being 1% faster, consider how many servers, VMs and containers run ubuntu. Millions of servers using a fraction of a percent less energy multiplies out to a lot…

If I recompile a program to fully utilize my cpu better (use AVX or whatever) then if my program takes 1 second to execute instead of 2, it likely did not use half the _energy_.

Obviously not. But scale it out to a fleet of 1000 servers running your program continuously, you can now shut down 10 for the same exact workload.

Re: Introducing architecture variants

#134

Post by darkwater »

Insanity wrote: post #12
adgjlsfhk1 wrote: post #9

Earlier quoted context omitted.

it's very no uniform. 99% see no change, but 1% see 1.5-2x better performance

I read it as, across the board a 1% performance improvement. Not that only 1% of packages get a significant improvement.

The announcement is pretty clear on this:

   > Previous benchmarks (...) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that.

Re: Introducing architecture variants

#135

Post by darkwater »

dabinat wrote: post #116
dehrmann wrote: post #13

Earlier quoted context omitted.

Anything at scale. 1% across FAANG is huge.

If those kinds of optimizations are on the table, why would they not already be compiling and optimizing from source?

I'm not an hyperscaler, I run a thousand machines. If by just changing the base image I use to build - in an already automated process - those machines, well, the optimization is basically for free. Well, unless it triggers some new bug that was not there before.

Re: Introducing architecture variants

#137

Post by viraptor »

ploxiln wrote: post #69
ninkendo wrote: post #33

Earlier quoted context omitted.

> show that most packages show a slight (around 1%) performance improvement This takes me back to arguing with Gentoo users 20 years ago who insisted that compiling everything from source for their machine made everything faster. The consensus at the time was basically "theoretically, it's possible, but in practice, gcc isn't really doing much with the extra instructions anyway". Then there's stuff like glibc which h…

FWIW the cool thing about gentoo was the "use-flags", to enable/disable compile-time features in various packages. Build some apps with GTK or with just the command-line version, with libao or pulse-audio, etc. Nowadays some distro packages have "optional dependencies" and variants like foobar-cli and foobar-gui, but not nearly as comprehensive as Gentoo of course. Learning about some minor custom CFLAGS was just par…

Nixpkgs exposes a lot of options like that. You can override both options and dependencies and supply your own cflags if you really want.

Re: Introducing architecture variants

#138

Post by alternatex »

pizlonator wrote: post #34
mobilio wrote: post #5

Announce was here: https://discourse.ubuntu.com/t/introducing-architecture-vari... and key point: "Previous benchmarks we have run (where we rebuilt the entire archive for x86-64-v3 57) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that."

That 1% number is interesting but risks missing the point. I bet you there is some use case of some app or library where this is like a 2x improvement.

Aggregated metrics are always useless as they tend to show interesting and sometimes exciting data that in actuality contains zero insight. I'm always weary of people making decisions based on aggregate metrics.

Would be nice to know the per app metrics.

Post reply on HN