[petsc-dev] error with flags PETSc uses for determining AVX

[Pierre Jolivet]

> On 15 Feb 2021, at 1:41 AM, Barry Smith <bsmith at petsc.dev> wrote:
> 
> 
> 
>> On Feb 14, 2021, at 4:04 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> Barry Smith <bsmith at petsc.dev> writes:
>> 
>>>  My feeling is 90+% of users don't care about portability, they want to get fast performance on the machine they are compiling with (or a collection of machines they have around).  
>> 
>> This is an exclusionary view of users. PETSc could and would be used in more places if it was easy to install, e.g., if "pip install petsc" was a 3-second binary install instead of several minutes that requires compilers.
> 
>  You misunderstood my statement, or I phrased it poorly. For those building PETSc themselves on their system using configure I don't think they care about building a library that is portable, that is that they can copy to any machine in the world and use. They want it to run fast on the machine(s) they are building on. Hence I think for users who build it themselves configure should lean for performance not portability. 
> 
>  Yes, having nice prebuilts (with as much performance as realistically possible in a portable library) is desirable. 
> 
>  Barry
> 
>  This is why I think configure should use native and those (making portable packages) should have to indicate they want portability. I hate to see everyone who builds PETSc themselves (which is many) get lousy performance just so package developers don't need to indicate to PETSc's configure they want portability. Thus a flag like --with-portable or something is desirable, where it is off by default. If we get to the point where we have both the performance and the portability with any build then, of course, we will not need such a flag anymore. But one step at a time.
> 

I’m playing the Devil’s advocate since the beginning, we’ve had a --enable-generic (off by default) which turns -march=native into -march=generic for 20+ years (I’m seeing references to PPC7450 and Intel Coppermine in our configure…).
We turn this flag on when building our .exe/.pkg/.deb.
I just think you’ll have to find a very very efficient way to advertise this change, because let’s face it, very few people outside of upstream developers read the changelog, and so people may start bundling up PETSc without this additional flag, and could potentially get spammed by end-users having a hard time figuring out why they get illegal instruction errors.
On some occasions we have such a message, but PETSc stands much lower in the software stack than our library so it’s likely it's bundled (instead of used on the same architecture as the compile node) way more often, IMHO (I guess you know the figure better than me…).

Thanks,
Pierre