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

91–100 of 152 posts

Re: Introducing architecture variants

#91

Post by noir_lord »

colechristensen wrote: post #26
juujian wrote: post #8

Earlier quoted context omitted.

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.

No but a lot of people are buying a lot of compute from Google, Amazon and Microsoft.

At scale marginal differences do matter and compound.

Re: Introducing architecture variants

#92

Post by mikepurvis »

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…

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

Re: Introducing architecture variants

#93

Post by rock_artist »

So if it got it right, This is mostly a way to have branches within a specific release for various levels of CPUs and their support of SIMD and other modern opcodes.

And if I have it right, The main advantage should come with package manager and open sourced software where the compiled binaries would be branched to benefit and optimize newer CPU features.

Still, this would be most noticeable mostly for apps that benefit from those features such as audio dsp as an example or as mentioned ssl and crypto.

Re: Introducing architecture variants

#94

Post by jeffbee »

rock_artist wrote: post #93

So if it got it right, This is mostly a way to have branches within a specific release for various levels of CPUs and their support of SIMD and other modern opcodes. And if I have it right, The main advantage should come with package manager and open sourced software where the compiled binaries would be branched to benefit and optimize newer CPU features. Still, this would be most noticeable mostly for apps that bene…

I would expect compression, encryption, and codecs to have the least noticeable benefit because these already do runtime dispatch to routines suited to the CPU where they are running, regardless of the architecture level targeted at compile time.

Re: Introducing architecture variants

#95

Post by wtallis »

jsheard wrote: post #85
cogman10 wrote: post #83

Earlier quoted context omitted.

Even on the same chip. Having a non-uniform instruction set for one package was a baffling decision.

I think that stemmed from their P-core design being shared between server and client. They needed AVX512 for server so they implemented it in the P-cores, and it worked fine there since their server chips are entirely P-cores or entirely E-cores, but client uses a mixture of both so they had to disable AVX512 to bring the instruction set into sync across both sides.

Server didn't really have anything to do with it. They were fine shipping AVX 512 in consumer silicon for Cannon Lake (nominally), Ice Lake, Tiger Lake, and most damningly Rocket Lake (backporting an AVX 512-capable core to their 14nm process for the sole purpose of making a consumer desktop chip, so they didn't even have the excuse that they were re-using a CPU core floorplan that was shared with server parts).

It's pretty clear that Alder Lake was simply a rush job, and had to be implemented with the E cores they already had, despite never having planned for heterogenous cores to be part of their product roadmap.

Re: Introducing architecture variants

#96

Post by WhyNotHugo »

jeffbee wrote: post #94
rock_artist wrote: post #93

So if it got it right, This is mostly a way to have branches within a specific release for various levels of CPUs and their support of SIMD and other modern opcodes. And if I have it right, The main advantage should come with package manager and open sourced software where the compiled binaries would be branched to benefit and optimize newer CPU features. Still, this would be most noticeable mostly for apps that bene…

I would expect compression, encryption, and codecs to have the least noticeable benefit because these already do runtime dispatch to routines suited to the CPU where they are running, regardless of the architecture level targeted at compile time.

OTOH, you can remove the runtime dispatching logic entirely if you compile separate binaries for each architecture variant.

Especially the binaries for the newest variant, since they can entirely conditionals/branching for all older variants.

Re: Introducing architecture variants

#97

Post by [deleted] »

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.

[deleted]

Re: Introducing architecture variants

#98

Post by jeffbee »

WhyNotHugo wrote: post #96
jeffbee wrote: post #94

Earlier quoted context omitted.

I would expect compression, encryption, and codecs to have the least noticeable benefit because these already do runtime dispatch to routines suited to the CPU where they are running, regardless of the architecture level targeted at compile time.

OTOH, you can remove the runtime dispatching logic entirely if you compile separate binaries for each architecture variant. Especially the binaries for the newest variant, since they can entirely conditionals/branching for all older variants.

That's a lot of surgery. These libraries do not all share one way to do it. For example zstd will switch to static BMI2 dispatch if it was targeting Haswell or later at compile time, but other libraries don't have that property and will need defines.

Re: Introducing architecture variants

#99

Post by zozbot234 »

Denvercoder9 wrote: post #82
zozbot234 wrote: post #16

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

Even if technically possible, it's unlikely this will be used to support any of the variants you mentioned in Debian. Both i386 and armel are effectively dead: i386 is reduced to a partial architecture only for backwards compatibility reasons, and armel has been removed entirely from development of the next release.

What you said is correct wrt. official support, but Debian also has an unofficial ports infrastructure that could be repurposed towards enabling Debian for older architecture variants.

Re: Introducing architecture variants

#100

Post by squeaky-clean »

Pet_Ant wrote: post #49
gpm wrote: post #47

Earlier quoted context omitted.

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.

> If you're negotiating deals worth billions of dollars, or even just millions, I'd strongly suggest not doing so with a hangover. ...have you met salespeople? Buying lap dances is a legitimate business expense for them. You'd be surprised how much personal rapport matters and facts don't. In all fairness, I only know about 8 and 9 figure deals, maybe at 10 and 11 salespeople grow ethics...

Well sure, because you want the person trying buy something from you for a million dollars to have a hangover.
Post reply on HN