February 2021 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Fortran macOS Linkage Warning
by Jacob Faibussowitsch 15 Feb '21

15 Feb '21

I think this problem ultimately stems from the fact that gcc/g++ and gfortran are not from the same people on macOS. It seems like clang is configured to build for 11.0 target, whilst gcc defaults to newest available target. And indeed if I change my compile command there is no warning: mkdir -p build && gfortran -c -o ./build/conftest.o conftest.F90 && gcc-10 -o ./build/libconftest.dylib ./build/conftest.o -dynamiclib -undefined dynamic_lookup && rm -rf ./build Note I now call gcc-10 as the linker which is the __actual__ gcc (not clang in a trench coat). Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Feb 15, 2021, at 11:46, Jacob Faibussowitsch <jacob.fai(a)gmail.com> wrote: > > Ok so if I pass -mmacosx-version-min=11.2 to the linker the warning disappears... > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >> On Feb 15, 2021, at 11:41, Jacob Faibussowitsch <jacob.fai(a)gmail.com <mailto:[email protected]>> wrote: >> >> I can reproduce the warning compiling just that simple code you listed. This is the compile command: >> >> mkdir -p build && gfortran -c -o ./build/conftest.o conftest.F90 && gcc -o ./build/libconftest.dylib ./build/conftest.o -dynamiclib -undefined dynamic_lookup && rm -rf ./build >> >> And error: >> ld: warning: object file (./build/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) >> >> Note I recently uninstalled and reinstalled command line tools too, which does not seem to have fixed it. >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >> >>> On Feb 15, 2021, at 11:30, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >>> >>> Here is the compile command and the warning: >>> >>>>>>>>> >>> ===== Checking linker >>> Executing: gfortran -c -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o -I/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.F90 >>> Successful compile: >>> Source: >>> function foo(a) >>> real:: a,x,bar >>> common /xx/ x >>> x=a >>> foo = bar(x) >>> end >>> Executing: gcc -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/libconftest.dylib -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o >>> Possible ERROR while running linker: >>> stderr: >>> ld: warning: object file (/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) >>> Accepted FC PIC code without compiler flag >>> ============================================================================================= >>> <<<<<< >>> >>> Its likely due to the way brew built gfortran. You can try compiling a simple test code and see if you can reproduce this warning. >>> >>> There is a related issue at: >>> >>> https://github.com/spack/spack/issues/21644 <https://github.com/spack/spack/issues/21644> >>> >>> Satish >>> >>> >>> On Sat, 13 Feb 2021, Jacob Faibussowitsch wrote: >>> >>>> Hello All, >>>> >>>> I’ve been getting these warnings for weeks, at first I figured it was due to gfortran brew package not being updated for Big Sur, but since it has persisted through a few gfortran brew updates I’m thinking it may be petsc related. This is on clean build on master. >>>> >>>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o) was built for newer macOS version (11.2) than being linked (11.0) >>>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-src/fsrc/f90_fwrap.o) was built for newer macOS version (11.2) than being linked (11.0) >>>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/objects/f2003-src/fsrc/optionenum.o) was built for newer macOS version (11.2) than being linked (11.0) >>>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/fsrc/somefort.o) was built for newer macOS version (11.2) than being linked (11.0) >>>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-mod/petscsysmod.o) was built for newer macOS version (11.2) than being linked (11.0) >>>> >>>> Best regards, >>>> >>>> Jacob Faibussowitsch >>>> (Jacob Fai - booss - oh - vitch) >>>> Cell: (312) 694-3391 >>>> >> >

1 0

Re: [petsc-dev] Fortran macOS Linkage Warning
by Jacob Faibussowitsch 15 Feb '21

15 Feb '21

Ok so if I pass -mmacosx-version-min=11.2 to the linker the warning disappears... Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Feb 15, 2021, at 11:41, Jacob Faibussowitsch <jacob.fai(a)gmail.com> wrote: > > I can reproduce the warning compiling just that simple code you listed. This is the compile command: > > mkdir -p build && gfortran -c -o ./build/conftest.o conftest.F90 && gcc -o ./build/libconftest.dylib ./build/conftest.o -dynamiclib -undefined dynamic_lookup && rm -rf ./build > > And error: > ld: warning: object file (./build/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) > > Note I recently uninstalled and reinstalled command line tools too, which does not seem to have fixed it. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > >> On Feb 15, 2021, at 11:30, Satish Balay <balay(a)mcs.anl.gov <mailto:[email protected]>> wrote: >> >> Here is the compile command and the warning: >> >>>>>>>> >> ===== Checking linker >> Executing: gfortran -c -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o -I/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.F90 >> Successful compile: >> Source: >> function foo(a) >> real:: a,x,bar >> common /xx/ x >> x=a >> foo = bar(x) >> end >> Executing: gcc -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/libconftest.dylib -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o >> Possible ERROR while running linker: >> stderr: >> ld: warning: object file (/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) >> Accepted FC PIC code without compiler flag >> ============================================================================================= >> <<<<<< >> >> Its likely due to the way brew built gfortran. You can try compiling a simple test code and see if you can reproduce this warning. >> >> There is a related issue at: >> >> https://github.com/spack/spack/issues/21644 <https://github.com/spack/spack/issues/21644> >> >> Satish >> >> >> On Sat, 13 Feb 2021, Jacob Faibussowitsch wrote: >> >>> Hello All, >>> >>> I’ve been getting these warnings for weeks, at first I figured it was due to gfortran brew package not being updated for Big Sur, but since it has persisted through a few gfortran brew updates I’m thinking it may be petsc related. This is on clean build on master. >>> >>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o) was built for newer macOS version (11.2) than being linked (11.0) >>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-src/fsrc/f90_fwrap.o) was built for newer macOS version (11.2) than being linked (11.0) >>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/objects/f2003-src/fsrc/optionenum.o) was built for newer macOS version (11.2) than being linked (11.0) >>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/fsrc/somefort.o) was built for newer macOS version (11.2) than being linked (11.0) >>> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-mod/petscsysmod.o) was built for newer macOS version (11.2) than being linked (11.0) >>> >>> Best regards, >>> >>> Jacob Faibussowitsch >>> (Jacob Fai - booss - oh - vitch) >>> Cell: (312) 694-3391 >>> >

1 0

Re: [petsc-dev] Fortran macOS Linkage Warning
by Satish Balay 15 Feb '21

15 Feb '21

ok - gfortran is using: > COLLECT_GCC_OPTIONS='-o' '/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.compilers/conftest' '-v' '-Wall' '-ffree-line-length-0' '-Wno-unused-dummy-argument' '-g' '-mmacosx-version-min=11.2.0' '-asm_macosx_version_min=11.2' '-shared-libgcc' '-mtune=core2' Likely -mmacosx-version-min=11.2.0 option is causing this issue. I do not know why brew gfortran is using this option. Satish On Mon, 15 Feb 2021, Jacob Faibussowitsch wrote: > I can reproduce the warning compiling just that simple code you listed. This is the compile command: > > mkdir -p build && gfortran -c -o ./build/conftest.o conftest.F90 && gcc -o ./build/libconftest.dylib ./build/conftest.o -dynamiclib -undefined dynamic_lookup && rm -rf ./build > > And error: > ld: warning: object file (./build/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) > > Note I recently uninstalled and reinstalled command line tools too, which does not seem to have fixed it. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 > > > On Feb 15, 2021, at 11:30, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > > Here is the compile command and the warning: > > > >>>>>>> > > ===== Checking linker > > Executing: gfortran -c -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o -I/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.F90 > > Successful compile: > > Source: > > function foo(a) > > real:: a,x,bar > > common /xx/ x > > x=a > > foo = bar(x) > > end > > Executing: gcc -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/libconftest.dylib -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o > > Possible ERROR while running linker: > > stderr: > > ld: warning: object file (/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) > > Accepted FC PIC code without compiler flag > > ============================================================================================= > > <<<<<< > > > > Its likely due to the way brew built gfortran. You can try compiling a simple test code and see if you can reproduce this warning. > > > > There is a related issue at: > > > > https://github.com/spack/spack/issues/21644 > > > > Satish > > > > > > On Sat, 13 Feb 2021, Jacob Faibussowitsch wrote: > > > >> Hello All, > >> > >> I’ve been getting these warnings for weeks, at first I figured it was due to gfortran brew package not being updated for Big Sur, but since it has persisted through a few gfortran brew updates I’m thinking it may be petsc related. This is on clean build on master. > >> > >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o) was built for newer macOS version (11.2) than being linked (11.0) > >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-src/fsrc/f90_fwrap.o) was built for newer macOS version (11.2) than being linked (11.0) > >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/objects/f2003-src/fsrc/optionenum.o) was built for newer macOS version (11.2) than being linked (11.0) > >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/fsrc/somefort.o) was built for newer macOS version (11.2) than being linked (11.0) > >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-mod/petscsysmod.o) was built for newer macOS version (11.2) than being linked (11.0) > >> > >> Best regards, > >> > >> Jacob Faibussowitsch > >> (Jacob Fai - booss - oh - vitch) > >> Cell: (312) 694-3391 > >> > >

1 0

Re: [petsc-dev] Fortran macOS Linkage Warning
by Jacob Faibussowitsch 15 Feb '21

15 Feb '21

I can reproduce the warning compiling just that simple code you listed. This is the compile command: mkdir -p build && gfortran -c -o ./build/conftest.o conftest.F90 && gcc -o ./build/libconftest.dylib ./build/conftest.o -dynamiclib -undefined dynamic_lookup && rm -rf ./build And error: ld: warning: object file (./build/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) Note I recently uninstalled and reinstalled command line tools too, which does not seem to have fixed it. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Feb 15, 2021, at 11:30, Satish Balay <balay(a)mcs.anl.gov> wrote: > > Here is the compile command and the warning: > >>>>>>> > ===== Checking linker > Executing: gfortran -c -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o -I/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.F90 > Successful compile: > Source: > function foo(a) > real:: a,x,bar > common /xx/ x > x=a > foo = bar(x) > end > Executing: gcc -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/libconftest.dylib -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o > Possible ERROR while running linker: > stderr: > ld: warning: object file (/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) > Accepted FC PIC code without compiler flag > ============================================================================================= > <<<<<< > > Its likely due to the way brew built gfortran. You can try compiling a simple test code and see if you can reproduce this warning. > > There is a related issue at: > > https://github.com/spack/spack/issues/21644 > > Satish > > > On Sat, 13 Feb 2021, Jacob Faibussowitsch wrote: > >> Hello All, >> >> I’ve been getting these warnings for weeks, at first I figured it was due to gfortran brew package not being updated for Big Sur, but since it has persisted through a few gfortran brew updates I’m thinking it may be petsc related. This is on clean build on master. >> >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o) was built for newer macOS version (11.2) than being linked (11.0) >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-src/fsrc/f90_fwrap.o) was built for newer macOS version (11.2) than being linked (11.0) >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/objects/f2003-src/fsrc/optionenum.o) was built for newer macOS version (11.2) than being linked (11.0) >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/fsrc/somefort.o) was built for newer macOS version (11.2) than being linked (11.0) >> ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-mod/petscsysmod.o) was built for newer macOS version (11.2) than being linked (11.0) >> >> Best regards, >> >> Jacob Faibussowitsch >> (Jacob Fai - booss - oh - vitch) >> Cell: (312) 694-3391 >>

1 0

Re: [petsc-dev] Fortran macOS Linkage Warning
by Satish Balay 15 Feb '21

15 Feb '21

Here is the compile command and the warning: >>>>>> ===== Checking linker Executing: gfortran -c -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o -I/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.F90 Successful compile: Source: function foo(a) real:: a,x,bar common /xx/ x x=a foo = bar(x) end Executing: gcc -o /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/libconftest.dylib -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress /var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o Possible ERROR while running linker: stderr: ld: warning: object file (/var/folders/9w/7dlszmmn6q1gd5yf3r9n79bc0000gn/T/petsc-dk9aiv7x/config.setCompilers/conftest.o) was built for newer macOS version (11.2) than being linked (11.0) Accepted FC PIC code without compiler flag ============================================================================================= <<<<<< Its likely due to the way brew built gfortran. You can try compiling a simple test code and see if you can reproduce this warning. There is a related issue at: https://github.com/spack/spack/issues/21644 Satish On Sat, 13 Feb 2021, Jacob Faibussowitsch wrote: > Hello All, > > I’ve been getting these warnings for weeks, at first I figured it was due to gfortran brew package not being updated for Big Sur, but since it has persisted through a few gfortran brew updates I’m thinking it may be petsc related. This is on clean build on master. > > ld: warning: object file (master-arch-darwin-c-debug/obj/sys/classes/bag/f2003-src/fsrc/bagenum.o) was built for newer macOS version (11.2) than being linked (11.0) > ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-src/fsrc/f90_fwrap.o) was built for newer macOS version (11.2) than being linked (11.0) > ld: warning: object file (master-arch-darwin-c-debug/obj/sys/objects/f2003-src/fsrc/optionenum.o) was built for newer macOS version (11.2) than being linked (11.0) > ld: warning: object file (master-arch-darwin-c-debug/obj/sys/fsrc/somefort.o) was built for newer macOS version (11.2) than being linked (11.0) > ld: warning: object file (master-arch-darwin-c-debug/obj/sys/f90-mod/petscsysmod.o) was built for newer macOS version (11.2) than being linked (11.0) > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > Cell: (312) 694-3391 >

1 0

Re: [petsc-dev] error with flags PETSc uses for determining AVX
by Jed Brown 15 Feb '21

15 Feb '21

Pierre Jolivet <pierre(a)joliv.et> writes: > 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…). I'm not opposed to an -march=native default, but configure should be loud about it and we should be proactive about contacting all the packagers we know of.

1 0

Re: [petsc-dev] error with flags PETSc uses for determining AVX
by Pierre Jolivet 15 Feb '21

15 Feb '21

> On 15 Feb 2021, at 1:41 AM, Barry Smith <bsmith(a)petsc.dev> wrote: > > > >> On Feb 14, 2021, at 4:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> Barry Smith <bsmith(a)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

1 0

Re: [petsc-dev] error with flags PETSc uses for determining AVX
by Barry Smith 14 Feb '21

14 Feb '21

> On Feb 14, 2021, at 4:04 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)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.

1 0

Re: [petsc-dev] error with flags PETSc uses for determining AVX
by Jed Brown 14 Feb '21

14 Feb '21

Jacob Faibussowitsch <jacob.fai(a)gmail.com> writes: >> working out dispatch in MatCreate_XXX() instead of for each function. > > Or use compiler extensions for multiversioned functions (I recall GCC has something similar): > https://clang.llvm.org/docs/AttributeReference.html#target <https://clang.llvm.org/docs/AttributeReference.html#target> Yes, if you want multiple kernel variants to live in the same source file. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ta… I believe you can do something like the following to specialize "portable" code. static inline void f_portable(size_t n, double *x) { for (size_t i=0; i<n; i++) x[i] += 1.; } void f_haswell(size_t n, double *x) __attribute__((__target__("arch=haswell"))) { f_portable(n, x); } void f_skylakeavx512(size_t n, double *x) __attribute__((__target__("arch=skylake-avx512"))) { f_portable(n, x); }

1 0

Re: [petsc-dev] error with flags PETSc uses for determining AVX
by Jacob Faibussowitsch 14 Feb '21

14 Feb '21

> working out dispatch in MatCreate_XXX() instead of for each function. Or use compiler extensions for multiversioned functions (I recall GCC has something similar): https://clang.llvm.org/docs/AttributeReference.html#target <https://clang.llvm.org/docs/AttributeReference.html#target> Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391 > On Feb 14, 2021, at 17:07, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)petsc.dev> writes: > >>> On Feb 14, 2021, at 12:13 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> >>> Barry Smith <bsmith(a)petsc.dev> writes: >>> >>>>> This is a reasonable message to print on the screen, but I don’t think this is a reasonable flag to impose by default. >>>>> You are basically asking all package managers to add a new flag (-march=generic) which was previously not needed. >>>> >>>> This is a tough constraint, package managers should not have to do anything to get portability but users get great performance without needing to be sophisticated. Seems to put the burden on the unsophisticated folks (all users) and not on the sophisticated folks (packages). >>> >>> The sophisticated folks are us, the upstream developers who know what needs to be optimized for specific hardware (src/mat/impls/) and what does not (most of the rest of PETSc). We've been typical self-centered scientific software developers who just assume people who care about performance will build a custom library for each machine they run on. >> >> I'm still bit confused. We need to build fat binaries otherwise the stuff in src/mat/impls/ will either be not portable or will be generic and potentially slower, right? Are you saying it is not worth building fat binaries for most of the source? So we mark either by directory or file where we want fat binaries built? > > Yes, binaries only need multiple versions for specific parts (kernels that benefit from vectorization). That keeps them smaller and the build fast. We can do a better job than "fat" compiler flags by working out dispatch in MatCreate_XXX() instead of for each function.

1 0