[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Laurence Marks
laurence.marks at gmail.com
Fri Dec 27 16:37:09 CET 2024
Try removing -pad
---
Emeritus Professor Laurence Marks (Laurie)
www.numis.northwestern.edu
https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en
"Research is to see what everybody else has seen, and to think what nobody
else has thought" Albert Szent-Györgyi
On Fri, Dec 27, 2024, 15:15 Gavin Abo <gabo13279 at gmail.com> wrote:
> As seen below, the timing of dstart looks like it got better using -O. I
> came across a comment that Intel Fortran does not default to
> -standard-semantics unless you ask for it at:
>
>
> https://fortran-lang.discourse.group/t/strange-issue-with-ifx-compiler-and-assume-recursion/7013/3
>
> Giving that a try, dstart compiled with -O.
>
> *Timing with -O0*
>
> username at computername:~/wiendata/TiC$ x dstart
> C T F
> DSTART ENDS
> 2.733u 0.006s 0:02.74 99.6% 0+0k 0+368io 0pf+0w
> username at computername:~/wiendata/TiC$ cd $WIENROOT/SRC_dstart
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O0 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
> FPOPT = -O0 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP) $(OMP_SWITCHP)
>
> *Segmentation compile error with -O*
>
> username at computername:~/WIEN2k/SRC_dstart$ gedit Makefile
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
> FPOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP) $(OMP_SWITCHP)
> username at computername:~/WIEN2k/SRC_dstart$ make
> ...
> ifx -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume
> buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -qopenmp -c charge.f
> #0 0x00005d3831075b41
> #1 0x00005d38310da457
> #2 0x00005d38310da585
> #3 0x000005d840c45320
> #4 0x00005d38301faba0
> #5 0x00005d383240ef28
> #6 0x00005d38309e7b27
> #7 0x00005d38309e766c
> #8 0x00005d3830bb959a
> #9 0x00005d3830925253
> #10 0x00005d38307dc752
> #11 0x00005d3830569aac
> #12 0x00005d3830568c9d
> #13 0x00005d3830568bf1
> #14 0x00005d3830949fe2
> #15 0x00005d383050ec1c
> #16 0x00005d3830250e94
> #17 0x00005d3830250cb9
> #18 0x00005d38301c7241
> #19 0x00005d38301c6f71
> #20 0x00005d38302dd34a
> #21 0x00005d38302dd121
> #22 0x00005d38307fa8a9
> #23 0x00005d3831012cfa
> #24 0x00005d3831010a37
> #25 0x00005d3830fbc64b
> #26 0x00005d3831198704
> #27 0x000005d840c2a1ca
> #28 0x000005d840c2a28b __libc_start_main + 139
> #29 0x00005d3830df319e
>
> charge.f: error #5633: **Internal compiler error: segmentation violation
> signal raised** Please report this error along with the circumstances in
> which it occurred in a Software Problem Report. Note: File and line given
> may not be explicit cause of this error.
> compilation aborted for charge.f (code 3)
> ...
>
> *Compile with -O and -standard-semantics*
>
> username at computername:~/WIEN2k/SRC_dstart$ gedit Makefile
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH) -standard-semantics
> FPOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP) $(OMP_SWITCHP)
> -standard-semantics
> username at computername:~/WIEN2k/SRC_dstart$ make
> ...
> username at computername:~/WIEN2k/SRC_dstart$ cp dstart ../dstart
> username at computername:~/WIEN2k/SRC_dstart$ cp dstart_mpi ../dstart_mpi
> username at computername:~/WIEN2k/SRC_dstart$ cd ~/wiendata/TiC
>
> *Timing with **-O and -standard-semantics*
>
> username at computername:~/wiendata/TiC$ x dstart
> DSTART ENDS
> 0.732u 0.008s 0:00.74 98.6% 0+0k 0+368io 0pf+0w
>
> Kind Regards,
> Gavin
> WIEN2k user
>
> On 12/27/2024 1:59 AM, Peter Blaha wrote:
>
> I'd expect this slow code is due to the switching off of optimization
> (-O0), and not due to a general problem of ifx with complex numbers.
>
> If you do -O0 globally, the code will obviously be MUCH slower, exactly as
> you have found out.
>
> Compilation with ifx would need a "special" strategy, compiling only the
> routines where optimization fails with -O0, all the rest with -O, like:
>
> Makefile with -O
> make
> compile the routine where it fails by hand:
> ifx -O0 .... -c failing_routine.f
> make
>
> continue the 2 lines above until it finishes. As far as I remember, -O0
> was required only for non-time-critical routines.
>
> Obviously, this is only a solution for experts. I'll see if I can come up
> with more specific Makefiles for ifx, where the problematic routines are
> compiled automatically without optimization.
>
> In any case, it would be interesting to see, if the code produced by this
> scheme is (almost) as fast as the ifort code.
>
> Best regards
> Peter
>
>
>
> Am 26.12.2024 um 12:10 schrieb Michael Fechtelkord via Wien:
>
> Hello all,
>
>
> thanks Gavin for your efforts concerning the ifx compiler and the complete
> compilation of the code.
>
>
> The compilation of the code with ifx is much faster, but the compiled
> WIEN2k code is much faster when compiled with ifort 2021.13.1.
>
> I have run a NMR calculation of KAlF4 with ifx and ifort compiled code and
> the ifort compiled code takes half of the time of the ifx compiled code (16
> minutes vs. 28 minutes).
>
> This is due to the fact that the handling of complex data is still better
> done with ifort compiled code. I read a few postings concerning this fact
> and I think this is still valid for the current version of ifx.
>
>
> https://community.intel.com/t5/Intel-Fortran-Compiler/IFX-vs-IFORT-
> performance-difference/m-p/1472018#M165800
>
>
> Happy Christmas to all!
>
> Michael
>
>
> Am 21.12.2024 um 18:02 schrieb Gavin Abo:
>
>
> Thanks for the hint about using -O0 when using ifx 2025.0.4.
>
> I compiled WIEN2k 24.1 with it, and it built without errors. I was even
> able to compile elpa with it.
>
> I documented the steps I used should others be interested in them and put
> them in a file that should be at:
>
> https://github.com/gsabo/WIEN2k-Docs/blob/main/
> WIEN2k24.1_Ubuntu22.04_Install_with_OneAPI(ifx).pdf
>
> The TiC example also ran fine. Screenshots of it are in another file
> here:
>
> https://github.com/gsabo/WIEN2k-Docs/blob/main/
> WIEN2k24.1%20TiC%20Example(ifx).pdf
>
> Gavin
> WIEN2k user
> On 10/30/2024 7:03 AM, Michael Fechtelkord via Wien wrote:
>
>
> I just compiled the WIEN2k code with ifx (2025.0.0) again, regarding
> Peter's recommendations .. and only a few errors remain now (all compiled
> without optimisation using -O0 flag) :
>
>
> SRC_3ddens/compile.msg:make: *** [Makefile:65: 3ddens] Fehler 1
> SRC_reformat/compile.msg:reformat.c:3:1: Fehler: Rückgabetyp ist auf »int«
> voreingestellt [-Wimplicit-int]
> SRC_reformat/compile.msg:make: *** [Makefile:40: reformat.o] Fehler 1
>
> SRC_3ddens
> ifx -o ./3ddens modules.o fft_modules.o 3ddens.o setfft2.o stern.o
> rotdef.o rotato.o rotat.o charge.o calculate_neighbours.o ylm.o radial.o
> sum.o interp.
> o gener.o vnorm.o latgen.o rotate.o reduc.o write_xsf.o write_stm.o
> primitive_cell.o read_struct.o atom_sphere_dens.o -L/usr/local/lib64
> -lfftw3 -lfftw3
> _omp -O0 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include
> -DFFTW3 -DFFTW_OMP
> -I/usr/local/include -qopenmp -L/opt/intel/oneapi/mkl/2025.0/lib/ -
> lpthread -lm -ldl -liomp5
> /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/ bin/ld:
> 3ddens.o: in function `dfftw_init_threads_.t1225p':
> ifx24sU4Q.i:(.text+0xf797): undefined reference to `dfftw_init_threads_'
> /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/ bin/ld:
> 3ddens.o: in function `dfftw_plan_with_nthreads_.t1230p':
> ifx24sU4Q.i:(.text+0xf7b7): undefined reference to
> `dfftw_plan_with_nthreads_'
> make: *** [Makefile:65: 3ddens] Fehler 1
>
> SRC_reformat
> rm -f reformat.o
> cc -c reformat.c
> reformat.c:3:1: Fehler: Rückgabetyp ist auf »int« voreingestellt [-
> Wimplicit-int]
> 3 | main(argc,argv)
> | ^~~~
> make: *** [Makefile:40: reformat.o] Fehler 1
>
>
> Best regards,
>
> Michael
>
> --
> Dr. Michael Fechtelkord
>
> Institut für Geologie, Mineralogie und Geophysik
> Ruhr-Universität Bochum
> Universitätsstr. 150
> <https://www.google.com/maps/search/Universit%C3%A4tsstr.+150?entry=gmail&source=g>
> D-44780 Bochum
>
> Phone: +49 (234) 32-24380
> Fax: +49 (234) 32-04380
> Email:Michael.Fechtelkord at ruhr-uni-bochum.de
> Web Page:https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/
> fechtelkord/
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
> --
> Dr. Michael Fechtelkord
>
> Institut für Geologie, Mineralogie und Geophysik
> Ruhr-Universität Bochum
> Universitätsstr. 150
> <https://www.google.com/maps/search/Universit%C3%A4tsstr.+150?entry=gmail&source=g>
> D-44780 Bochum
>
> Phone: +49 (234) 32-24380
> Fax: +49 (234) 32-04380
> Email:Michael.Fechtelkord at ruhr-uni-bochum.de
> Web Page:
> https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241227/dae3ae82/attachment.htm>
More information about the Wien
mailing list