Aleksandra Fedorova wrote: > Hi, Chris, > > On Fri, Jan 10, 2020 at 4:29 PM Chris Adams <linux@xxxxxxxxxxx> wrote: >> >> Once upon a time, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> 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 safely >> > 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 written, >> 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 >> misleading). > > 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: https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update 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 hardware. 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 > done better. 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 detection. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
