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

101–110 of 152 posts

Re: Introducing architecture variants

#101

Post by slavik81 »

Amadiro wrote: post #52
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…

It's also because around 20 years ago there was a "reset" when we switched from x86 to x86_64. When AMD introduced x86_64, it made a bunch of the previously optional extension (SSE up to a certain version etc) a mandatory part of x86_64. Gentoo systems could already be optimized before on x86 using those instructions, but now (2004ish) every system using x86_64 was automatically always taking full advantage of all of…

The llama.cpp package on Debian and Ubuntu is also rather clever in that it's built for x86-64-v1, x86-64-v2, x86-64-v3, and x86-64-v4. It benefits quite dramatically from using the newest instructions, but the library doesn't have dynamic instruction selection itself. Instead, ld.so decides which version of libggml.so to load depending on your hardware capabilities.

Re: Introducing architecture variants

#102

Post by godelski »

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?

  > where that 1% is worth any hassle
You'll need context to answer your question, but yes there are cases.

Let's say you have a process that takes 100hrs to run and costs $1k/hr. You save an hour and $1k every time you run the process. You're going to save quite a bit. You don't just save the time to run the process, you save literal time and everything that that costs (customers, engineering time, support time, etc).

Let's say you have a process that takes 100ns and similarly costs $1k/hr. You now run in 99ns. Running the process 36 million times is going to be insignificant. In this setting even a 50% optimization probably isn't worthwhile (unless you're a high frequency trader or something)

This is where the saying "premature optimization is the root of all evil" comes from! The "premature" part is often disregarded and the rest of the context goes with it. Here's more context to Knuth's quote[0].

  There is no doubt that the holy grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

  Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.
Knuth said: "Get a fucking profiler and make sure that you're optimizing the right thing". He did NOT say "don't optimize".

So yes, there are plenty of times where that optimization will be worthwhile. The percentages don't mean anything without the context. Your job as a programmer is to determine that context. And not just in the scope of your program, but in the scope of the environment you expect a user to be running on. (i.e. their computer probably isn't entirely dedicated to your program)

[0] https://dl.acm.org/doi/10.1145/356635.356640 (alt) https://sci-hub.se/10.1145/356635.356640

Re: Introducing architecture variants

#103

Post by harha »

ninkendo wrote: post #33
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."

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

Would it make a difference if you compile the whole system vs. just the programs you want optimized?

As in, are there any common libraries or parts of the system that typically slow things down, or was this more targeting a time when hardware was more limited so improving all would have made things feel faster in general.

Re: Introducing architecture variants

#104

Post by suprjami »

ninkendo wrote: post #33
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."

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

I somehow have the memory that there was an extremely narrow time window where the speedup was tangible and quantifiable for Gentoo, as they were the first distro to ship some very early gcc optimisation. However it's open source software so every other distro soon caught up and became just as fast as Gentoo.

Re: Introducing architecture variants

#106

Post by Seattle3503 »

oivey wrote: post #60
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…

This should build a lot more incentive for compiler devs to try and use the newer instructions. When everyone uses binaries compiled without support for optional instruction sets, why bother putting much effort into developing for them? It’ll be interesting to see if we start to see more of a delta moving forward.

And application developers to optimize with them in mind?

Re: Introducing architecture variants

#107

Post by zerocrates »

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…

I started with Debian on CDs, but used Gentoo for years after that. Eventually I admitted that just Ubuntu suited my needs and used up less time keeping it up to date. I do sometimes still pull in a package that brings a million dependencies for stuff I don't want and miss USE flags, though.

I'd agree that the manual Gentoo install process, and those tinkering years in general, gave me experience and familiarity that's come in handy plenty of times when dealing with other distros, troubleshooting, working on servers, and so on.

Re: Introducing architecture variants

#108

Post by izacus »

mikepurvis wrote: post #92
Amadiro wrote: post #52

Earlier quoted context omitted.

It's also because around 20 years ago there was a "reset" when we switched from x86 to x86_64. When AMD introduced x86_64, it made a bunch of the previously optional extension (SSE up to a certain version etc) a mandatory part of x86_64. Gentoo systems could already be optimized before on x86 using those instructions, but now (2004ish) every system using x86_64 was automatically always taking full advantage of all of…

> AVX, encryption and virtualization I would guess that these are domain-specific enough that they can also mostly be enabled by the relevant libraries employing function multiversioning.

You would guess wrong.

Re: Introducing architecture variants

#109

Post by tclancy »

gpm wrote: post #47
iso1631 wrote: post #36

Earlier quoted context omitted.

1% is less than the difference between negotiating with a hangover or not.

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.

Sounds like someone never read Sun Tzu.

(Not really, I just know somewhere out there is a LinkedInLunatic who has a Business Philosophy based on being hungover.)

Re: Introducing architecture variants

#110

Post by watersb »

Over the past year, Intel has pulled back from Linux development.

Intel has reduced its number of employees, and has lost lots of software developers.

So we lost Clear Linux, their Linux distribution that often showcased performance improvements due to careful optimization and utilization of microarchitectural enhancements.

I believe you can still use the Intel compiler, icc, and maybe see some improvements in performance-sensitive code.

https://clearlinux.org/

"It was actively developed from 2/6/2015-7/18/2025."

Post reply on HN