Στις 08-03-2017, ημέρα Τετ, και ώρα 19:53 +0100, ο/η John Paul Adrian Glaubitz έγραψε: > Actually, it is. ATLAS is one of these libraries which contain lots > of CPU optimization code and if you really want to use ATLAS for > actual number crunching, you want to build it from source. It is > very common practice in the scientific work. I am a graduated > physicist > who used to do number crunching on such clusters and I also happened > to maintain several of such clusters for work. Good, I'm also a physicist though now my line of work almost entirely revolves around SIMD optimizations in several architectures (Intel, ARM, Power and S390x ZVector), running highly parallel performance- critical software (not Physics related since a long time ago). So I also do have a pretty good idea of what I'm talking about. In any case, I will agree that Atlas is one of the special cases where you compile from source, but my original point was against the original bug report and Firefox, which isn't a special case. A typical user should not have to rebuild Firefox to get a decent performance increase. > I am still waiting for the section from the policy. You cannot make > these > bold statements and then not come up with the necessary prove. Not policy, but how about this: https://www.debian.org/Bugs/Developer#severities and this: https://www.debian.org/ports/powerpc/ Currently the systems listed there are assumed to be supported. The statements are not bold, they are facts, my guess is that many developer would reply pretty much the same. > I assume you are aware of the fact that Debian's i386 port requires > at > least an i686 CPU these days. How does that fit with your line of > arguments? According to your logic, all packages would be affected > by RC bugs because they stopped supporting i386 long time ago. The i386 port minimum requirements have been increased on a steady basis. And it's also a fact that runtime detection works much better there, while at the same time, a simple google search revealed quite a few bug reports on i386 even for enabling SSE2 (which should be considered default on most CPUs by now). I don't see how altivec should be different. The difference is that we're still supporting almost 20 year old hardware -or pretend to support. > I'm sorry, but this argument contradicts the current practice. Does it? Look below: > Again, look at i386. I did. And I found just from a very quick search #812989, #792594, #852356, and I guess there are probably many more like those. So I don't see your point. > So, you actually don't bother at all and don't want to go through > any efforts of testing, yet you insist on your stance. Odd. No, you got half of it. I support the use of Altivec, properly. I'm testing Altivec code, on Altivec hardware, I don't test Altivec code on non-altivec hardware, or altivec detection for that matter, not anymore. And I'm actually tired of pushing for distro-wide enablement by default. Anyway, if you're going to continue the discussion just to prove that altivec should be supported, yes, I completely agree, but I disagree on the way you propose to do it, enable it until someone complains. Please allow me to quote the phrase which triggered my reply: "But it has been like that for ages and no one has complained so far" If we go your route and noone complains for a long time, that means noone bothered to run the software in that very old hardware and we're just limiting the performance for the rest of our users -who have supporting hardware, for absolutely no good reason. If someone complains immediately (as they did for ppc64) then that means people are actually still using powerpc port on non-altivec hardware. What I'm actually suggesting -now and have been for a long time- is that we should be more sincere and just admit we cannot support every possible configuration and we should try to at least support the top range of the hardware as best as we can, and maybe even give a decent speed bump by enabling altivec throughout, so in essence I'm advocating -yet once more, to just declare non-altivec hardware as unsupported and be done with it. Users of older hardware should just upgrade or use an older version. Regards Konstantinos
Attachment:
signature.asc
Description: This is a digitally signed message part