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

11–20 of 152 posts

Re: Introducing architecture variants

#11

Post by physicsguy »

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 targeting the micro-architecture you’re running on.

Re: Introducing architecture variants

#12

Post by Insanity »

adgjlsfhk1 wrote: post #9
juujian wrote: post #8

Earlier quoted context omitted.

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

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.

Re: Introducing architecture variants

#13

Post by dehrmann »

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?

Anything at scale. 1% across FAANG is huge.

Re: Introducing architecture variants

#14

Post by IAmBroom »

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.

In a complicated system, a 1% overall benefit might well be because of a 10% improvement in just 10% of the system (or more in a smaller contributor).

Re: Introducing architecture variants

#15

Post by 2b3a51 »

adgjlsfhk1 wrote: post #9
juujian wrote: post #8

Earlier quoted context omitted.

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

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

I'm wondering if 'somewhat numerical in nature' relates to lpack/blas and similar libraries that are actually dependencies of a wide range of desktop applications?

Re: Introducing architecture variants

#16

Post by zozbot234 »

What are the changes to dpkg and apt? Are they being shared with Debian? Could this be used to address the pesky armel vs. armel+hardfloat vs. armhf issue, or for that matter, the issue of i486 vs. i586 vs. i686 vs. the many varieties of MMX and SSE extensions for 32-bit?

(There is some older text in the Debian Wiki https://wiki.debian.org/ArchitectureVariants but it's not clear if it's directly related to this effort)

Re: Introducing architecture variants

#17

Post by dfc »

> 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?

Re: Introducing architecture variants

#18

Post by wongarsu »

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?

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 of energy

Re: Introducing architecture variants

#19

Post by adgjlsfhk1 »

2b3a51 wrote: post #15
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'm wondering if 'somewhat numerical in nature' relates to lpack/blas and similar libraries that are actually dependencies of a wide range of desktop applications?

blas and lapack generally do manual multi-versioning by detecting CPU features at runtime. This is more useful 1 level up the stack in things like compression/decompression, ode solvers, image manipulation and so on that are still working with big arrays of data, but don't have a small number of kernels (or as much dev time), so they typically rely on compilers for auto-vectorization

Re: Introducing architecture variants

#20

Post by Aissen »

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?

You need 100 servers. Now you need to only buy 99. Multiply that by a million, and the economies of scale really matter.
Post reply on HN