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

71–80 of 152 posts

Re: Introducing architecture variants

#71

Post by PaulHoule »

ciaranmca wrote: post #67
PaulHoule wrote: post #45

Earlier quoted context omitted.

My RSS reader trains a model every week or so and takes 15 minutes total with plain numpy, scikit-learn and all that. Intel MKL can do the same job in about half the time as the default BLAS. So you are looking at a noticeable performance boost but zero bullshit install with uv is worth a lot. If I was interested in improving the model than yeah I might need to train 200 of them interactively and I’d really feel the…

Out of interest, what reader is this? Sounds interesting

I've talked about it a lot here, see https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Re: Introducing architecture variants

#73

Post by notatoad »

Havoc wrote: post #32
dehrmann wrote: post #13

Earlier quoted context omitted.

Anything at scale. 1% across FAANG is huge.

Arguable same across consumers too. It’s just harder to measure than central datacenters

nah, performance benefits are mostly wasted on consumers, because consumer hardware is very infrequently CPU-constrained. in a datacentre, a 1% improvement could actually mean you provision 99 CPUs instead of 100. but on your home computer, a 1% CPU improvement means that your network request completes 0.0001% faster, or your file access happens 0.000001% faster, and then your CPU goes back to being idle.

an unobservable benefit is not a benefit.

Re: Introducing architecture variants

#74

Post by Hasz »

Getting a 1% across the board general purpose improvement might sound small, but is quite significant. Happy to see Canonical invest more heavily in performance and correctness.

Would love to see which packages benefited the most in terms of percentile gain and install base. You could probably back out a kWh/tons of CO2 saved metric from it.

Re: Introducing architecture variants

#75

Post by oofbey »

zipy124 wrote: post #56
physicsguy wrote: post #11

This is quite good news but it’s worth remembering that it’s a rare piece of software in the modern scientific/numerical world that can be compiled against the versions in distro package managers, as versions can significantly lag upstream months after release. If you’re doing that sort of work, you also shouldn’t use pre-compiled PyPi packages for the same reason - you leave a ton of performance on the table by not…

Yup, if you're using OpenCV for instance compiling instead of using pre-built binaries can result in 10x or more speed-ups once you take into account avx/threading/math/blas-libraries etc...

Yup. The irony is that the packages which are difficult to build are the ones that most benefit from custom builds.

Re: Introducing architecture variants

#76

Post by locknitpicker »

juujian wrote: post #8
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."

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

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

I don't think this is a valid argument to make. If you were doing the optimization work then you could argue tradeoffs. You are not, Canonical is.

Your decision is which image you want to use, and Canonical is giving you a choice. Do you care about which architecture variant you use? If you do, you can now pick the one that works best for you. Do you want to win an easy 1% performance gain? Now you have that choice.

Re: Introducing architecture variants

#77

Post by gwbas1c »

juujian wrote: post #8
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."

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

> some packages, mostly those that are somewhat numerical in nature, improve more than that

Perhaps if you're doing CPU-bound math you might see an improvement?

Re: Introducing architecture variants

#79

Post by glenstein »

Pet_Ant wrote: post #49
gpm wrote: post #47

Earlier quoted context omitted.

What a strange comparison. If you're negotiating deals worth billions of dollars, or even just millions, I'd strongly suggest not doing so with a hangover.

> If you're negotiating deals worth billions of dollars, or even just millions, I'd strongly suggest not doing so with a hangover. ...have you met salespeople? Buying lap dances is a legitimate business expense for them. You'd be surprised how much personal rapport matters and facts don't. In all fairness, I only know about 8 and 9 figure deals, maybe at 10 and 11 salespeople grow ethics...

That's more an indictment of sales culture than a critique of computational efficiency.

Re: Introducing architecture variants

#80

Post by jnsgruk »

justahuman74 wrote: post #54

If this goes well - will they do v4 as well?

Maybe - likely we’ll trade-off the added build/test/storage cost of maintaining each variant - so you might not see amd64v4, but possibly amd64v5 depending on how impactful they turn out to be.

The same will apply to different arm64 or riscv64 variants.

Post reply on HN