Aleksandra Fedorova wrote:
On Fri, Jan 10, 2020 at 4:29 PM Chris Adams <linux(a)cmadams.net> wrote:
> Once upon a time, Aleksandra Fedorova <alpha(a)bookwar.info> said:
> > Similarly to what Josh said, we want to setup an environment for
> > experiments. It doesn't mean that things we experiment on are going to
> > be merged in Fedora. And it definitely doesn't mean that whatever we
> > did in the experimental environment can bypass the approval process.
I, too, find it absolutely unacceptable that you are now trying to push an
unacceptable (and rightfully rejected) system-wide change through via the
salami tactic. There is nothing "self-contained" about your change proposal,
it is clearly designed to be the first step of a system-wide change.
In addition, this first step is itself not "self-contained": Your buildroot
will contain all packages in the entire distribution, and (depending on how
exactly it is implemented) potentially slow down all builds or have other
system-wide side effects (notification spam etc.).
> > It is not a backdoor for rejected change, it is a way to
> > iterate on the rejected change to see if we can come up with a version
> > of it, which won't be rejected.
No such version can exist. The change was rejected because its fundamental
concept is unacceptable to begin with. Therefore, all your "improved"
versions will be rejected as well, unless FESCo decides to ignore all the
overwhelmingly negative feedback and do a 180° U-turn on the issue.
> So... I guess my objections are all based on the proposal as
> which doesn't sound to me like what you are describing. What the
> proposal says is all about rebuilding Fedora with the rejected baseline
> change, and showing that it is better to get the community to accept the
> original change. It also uses the term "older machines" (which is still
I have adjusted the description of the change in a way that I think
clarifies this part. Please check if it is better now.
Even with its current wording, I am still opposed to:
and any other Change that wants to introduce or test introducing a
requirement on SSE3 or newer.
The only reasonable way to use these architecture extensions is runtime
detection in specific packages. I am convinced that such runtime detection
in a handful packages should be enough to provide the desired improvements
(in fact, some of them already support this and are already make use of this
right now! E.g., OpenBLAS), without breaking compatibility with existing
Therefore, the development efforts should be spent on identifying the
packages where runtime detection of vector instruction sets makes sense and
does not exist yet and adding such runtime detection to those packages (and
ONLY to those packages where it makes sense, because doing this to all
packages would just increase their size and lead to no noticeable
performance improvement whatsoever).
I think the current change is important to Fedora also as a showcase
that we, as a project, care not only about the internal distribution
matters but in some large developments in the "outside world".
That we can also provide a venue for, for example, hardware vendors to
show their newest work.
And runtime detection is the way to go there. It means you can use all the
speedup from new CPU generations without breaking all existing (older, but
often still sold or even still manufactured!) ones.
The rejection is a valuable feedback here, it highlights that it is
not enough to just push a new hardware spec to the market to get it
adopted. But we can also try to find a way how actually it _can_ be
I do not think things can be done any better on the hardware end. (Well,
technically, it might be possible to backport new instruction sets with
microcode updates, but it is unrealistic to expect CPU vendors to do that,
and it would also not lead to the expected performance improvements, because
adding, e.g., 512-bit vector instructions to a CPU that only has 256-bit
vector units would only mean that the microcode would have to split each
operation to emulate the 512-bit instruction set.) The better way has to be
done on the software end, and it already exists there, it is called runtime