> On 15 Feb 2021, at 1:41 AM, Barry Smith <[email protected]> wrote:
>
>
>
>> On Feb 14, 2021, at 4:04 PM, Jed Brown <[email protected]> wrote:
>>
>> Barry Smith <[email protected]> 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
