Re: Changing default -march landscape

On Thu, Jun 13, 2024 at 8:15 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Yeah, I think it's completely unreasonable to push this on packagers and just say "this is your problem now". If we do that, we can assume the only people to get any benefit from these optimizations are those that use a fully managed cloud service like azure or RDS.

It would also benefit distros that have decided to move their baseline
micro-arch level right now, probably without any additional action
from the maintainers assuming that gcc defaults to -march=*-v2 etc.
The cloud vendors' internal distros aren't really special in that
regard are they?

Hmm, among Linux distros, maybe it's really only Debian that isn't
moving or talking about moving the baseline yet? (Are they?)

> They can do it, but we need to tell them how and when. And if we intend for packagers to be part of the solution we need to explicitly bring them into the discussion of how to do it, at a fairly early stage (and no, we can't expect them to follow every thread on hackers).

OK let me CC Christoph and ask the question this way: hypothetically,
if RHEL users' PostgreSQL packages became automatically faster than
Debian users' packages because of default -march choice in the
toolchain, what would the Debian project think about that, and what
should we do about it? The options discussed so far were:

1. Consider a community apt repo that is identical to the one except
targeting the higher microarch levels, that users can point a machine
to if they want to.
2. Various ideas for shipping multiple versions of the code at a
higher granularity than we're doing to day (a callback for a single
instruction! the opposite extreme being the whole executable +
libraries), probably using some of techniques mentioned at
https://wiki.debian.org/InstructionSelection.

I would guess that 1 is about 100x easier but I haven't looked into it.