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

141–150 of 152 posts

Re: Introducing architecture variants

#141

Post by michaelcampbell »

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…

Someone has set up an archive of that site; I visit it once in a while for a few nostalgiac chuckles

https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...

Re: Introducing architecture variants

#142

Post by ignoramous »

slavik81 wrote: post #101
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…

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.

> llama.cpp package on Debian and Ubuntu is also rather clever … ld.so decides which version of libggml.so to load depending on your hardware capabilities

Why is this "clever"? This is pretty much how "fat" binaries are supposed to work, no? At least, such packaging is the norm for Android.

Re: Introducing architecture variants

#143

Post by dehrmann »

bandrami wrote: post #119
dehrmann wrote: post #13

Earlier quoted context omitted.

Anything at scale. 1% across FAANG is huge.

Isn't Facebook still using PHP?

They forked PHP into Hack. They've diverged pretty far by this point (especially with data structures), but it maintains some of PHPs quirks and request-oriented runtime. It's jitted by HHVM. Both Hack and HHVM are open-source, but I'm not aware of any major users outside Meta.

Re: Introducing architecture variants

#144

Post by zymhan »

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_.

Sure, but we're talking about compiled packages being distributed by a package manager.

Re: Introducing architecture variants

#145

Post by mananaysiempre »

theandrewbailey wrote: post #2

A reference for x86-64 microarchitecture levels: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level... x86-64-v3 is AVX2-capable CPUs.

Right, though compared to what one generally thinks of as an “AVX2-compatible” CPU, it curiously omits AES-NI and CLMUL (both relevant to e.g. AES-GCM). Yes, they are not technically part of AVX2, but they are present in all(?) the qualifying Intel and AMD CPUs (like many other technically-not-AVX2 stuff that did get included, like BMI or FMA3).

Re: Introducing architecture variants

#146

Post by watersb »

dooglius wrote: post #115
watersb wrote: post #110

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

icc was discontinued FWIW. The replacement, icx, is AIUI just clang plus some proprietary plugins

I wonder how this relates to Intel's "One API", which extends a single C code base across the various CPU targets (such as the core ALU, base vector units, AVX-512, NPU) and Intel GPU accelerators.

Not the same thing, or perhaps an augmentation of Intel performance libraries (which required C++, I believe).

Sure, harmonizing all of this may have suggested that there were too many software teams. But device drivers don't write themselves, and without feedback from internal software developers, you can't validate your CPU designs.

Re: Introducing architecture variants

#147

Post by alkonaut »

zymhan wrote: post #144
alkonaut wrote: post #132

Earlier quoted context omitted.

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_.

Sure, but we're talking about compiled packages being distributed by a package manager.

Yes but my point is: if I download the AVX version instead of the SSE version of a package and that makes my 1000 servers 10% _quicker_ that is not the same as being 10% more _efficient_.

Because typically these modern things are a way of making the CPU do things faster by eating more power. There may be savings from having fewer servers etc, but savings in _speed_ are not the same as savings in _power_ (and some times even work the opposite way)

Re: Introducing architecture variants

#148

Post by random29ah »

I'm really "new" to x64 (I only migrated from 32-bit in 2020...) and the difference I noticed between x86-64-v1 and x86-64-v3 was only with video (with ffmpeg), audio (mp3/ogg/mp4...) and encryption; the rest remains practically the same.

Naively, I believe it might be more appropriate to have x86-64-v1 and x86-64-vN options only for specific software and leave the rest as x86-64-v1.

AVX seemed to give the biggest boost to things.

Regarding those who are making fun of Gentoo users, it really did make a bigger difference in the past, but with the refinement of compilers, the difference has diminished. Today, for me, who still uses Gentoo/CRUX for some specific tasks, what matters is the flexibility to enable or disable what I want in the software, and not so much the extra speed anymore.

As an example, currently I use -Os (x86-64-v1) for everything, and only for things related to video/sound/cryptography (I believe for things related to mathematics in general?) I use -O2 (x86-64-v3) with other flags to get a little more out of it.

Interestingly, in many cases -Os with -mtune=nocona generates faster binaries even though I'm only using hardware from Haswell to today's hardware (who can understand the reason for this?).

Post reply on HN