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
D-44780 Bochum
Phone: +49 (234) 32-24380
Fax: +49 (234) 32-04380
Email:[email protected]
Web Page:https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/
fechtelkord/
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST
at:http://www.mail-archive.com/[email protected]/index.html
--
Dr. Michael Fechtelkord
Institut für Geologie, Mineralogie und Geophysik
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum
Phone: +49 (234) 32-24380
Fax: +49 (234) 32-04380
Email:[email protected]
Web
Page:https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
--
-----------------------------------------------------------------------
Peter Blaha, Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-158801165300
Email: [email protected]
WWW: http://www.imc.tuwien.ac.at WIEN2k: http://www.wien2k.at
-------------------------------------------------------------------------
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
