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

21–30 of 152 posts

Re: Introducing architecture variants

#21

Post by PeterStuer »

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?

A lott of improvements are very incremental. In agregate, they often compound and are vey significant.

If you would only accept 10x improvements, I would argue progress would be very small.

Re: Introducing architecture variants

#23

Post by colechristensen »

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…

Most of the scientific numerical code I ever used had been in use for decades and would compile on a unix variant released in 1992, much less the distribution version of dependencies that were a year or two behind upstream.

Re: Introducing architecture variants

#24

Post by stabbles »

Seems like this is not using glibc's hwcaps (where shared libraries were located in microarch specific subdirs).

To me hwcaps feels like a very unfortunate feature creep of glibc now. I don't see why it was ever added, given that it's hard to compile only shared libraries for a specific microarch, and it does not benefit executables. Distros seem to avoid it. All it does is causing unnecessary stat calls when running an executable.

Re: Introducing architecture variants

#25

Post by niwtsol »

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…

Thanks for sharing this. I'd love to learn more about micro-architectures and instruction sets - would you have any recommendations for books or sources that would be a good starting place?

Re: Introducing architecture variants

#26

Post by colechristensen »

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?

Very few people are in the situation where this would matter.

Standard advice: You are not Google.

I'm surprised and disappointed 1% is the best they could come up with, with numbers that small I would expect experimental noise to be much larger than the improvement. If you tell me you've managed a 1% improvement you have to do a lot to convince me you haven't actually made things 5% worse.

Re: Introducing architecture variants

#27

Post by jeffbee »

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…

I wonder who downvoted this. The juice you are going to get from building your core applications and libraries to suit your workload are going to be far larger than the small improvements available from microarchitectural targeting. For example on Ubuntu I have some ETL pipelines that need libxml2. Linking it statically into the application cuts the ETL runtime by 30%. Essentially none of the practices of Debian/Ubuntu Linux are what you'd choose for efficiency. Their practices are designed around some pretty old and arguably obsolete ideas about ease of maintenance.

Re: Introducing architecture variants

#28

Post by [deleted] »

dfc wrote: post #17

> you will not be able to transfer your hard-drive/SSD to an older machine that does not support x86-64-v3. Usually, we try to ensure that moving drives between systems like this would work. For 26.04 LTS, we’ll be working on making this experience cleaner, and hopefully provide a method of recovering a system that is in this state. Does anyone know what the plans are to accomplish this?

[deleted]
Post reply on HN