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

31–40 of 152 posts

Re: Introducing architecture variants

#32

Post by Havoc »

dehrmann wrote: post #13
juujian wrote: post #8

Earlier quoted context omitted.

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

Anything at scale. 1% across FAANG is huge.

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

Re: Introducing architecture variants

#33

Post by ninkendo »

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 has custom assembly versions of things like memcpy/etc, and selects from them at startup. I'm not really sure if that was common 20 years ago but it is now.

It's cool that after 20 years we can finally start using the newer instructions in binary packages, but it definitely seems to not matter all that much, still.

Re: Introducing architecture variants

#34

Post by pizlonator »

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

That 1% number is interesting but risks missing the point.

I bet you there is some use case of some app or library where this is like a 2x improvement.

Re: Introducing architecture variants

#36

Post by iso1631 »

Aissen wrote: post #20
juujian wrote: post #8

Earlier quoted context omitted.

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.

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

Re: Introducing architecture variants

#37

Post by wtallis »

theandrewbailey wrote: post #10
jsheard wrote: post #7

Earlier quoted context omitted.

> x86-64-v3 is AVX2-capable CPUs. Which unfortunately extends all the way to Intels newest client CPUs since they're still struggling to ship their own AVX512 instructions, which are required for v4. Meanwhile AMD has been on v4 for two generations already.

At least Intel and AMD have settled on a mutually supported subset of AVX-512 instructions.

The hard part was getting Intel and Intel to agree on which subset to keep supporting.

Re: Introducing architecture variants

#39

Post by zdw »

Many other 3rd party software has already required x86-64-v2 or -v3 already.

I couldn't run something from NPM on a older NAS machine (HP Microserver Gen 7) recently because of this.

Post reply on HN