Hi, It took a whole weekend to get Scipy working with the Intel compiler. Now all scipy tests pass (except test_shapiro) also with ifc. However, few functions from special.cephes still cause python to crash (see test methods starting with _check). I'll get back to it later when special module has more tests that actually test the correctness cephes functions results. Currently when cephes functions (built with gcc) return results then I am not always sure that they are correct, in same cases I have even been unable to call these functions without getting domain errors (see test methods starting with __check). Anyway, guide lines how to build scipy with ifc can be found in INSTALL.txt. Unfortunately, the building process is not as straightforward as one would wish: 1) there is binary incompability between ifc and g77 generated codes so that ATLAS and LAPACK libraries *must* be compiled with ifc. 2) in some cases ifc optimization is too good so that LAPACK functions ?lamch fail for that; see INSTALL.txt for a workaround. Finally, Intel Fortran Compiler 5.0 is not supported because scipy build fails with internal compiler error when debugging flags are enabled. Regards, Pearu
Pearu Peterson wrote:
Hi,
It took a whole weekend to get Scipy working with the Intel compiler. Now all scipy tests pass (except test_shapiro) also with ifc.
However, few functions from special.cephes still cause python to crash (see test methods starting with _check). I'll get back to it later when special module has more tests that actually test the correctness cephes functions results. Currently when cephes functions (built with gcc) return results then I am not always sure that they are correct, in same cases I have even been unable to call these functions without getting domain errors (see test methods starting with __check).
Anyway, guide lines how to build scipy with ifc can be found in INSTALL.txt. Unfortunately, the building process is not as straightforward as one would wish: 1) there is binary incompability between ifc and g77 generated codes so that ATLAS and LAPACK libraries *must* be compiled with ifc. 2) in some cases ifc optimization is too good so that LAPACK functions ?lamch fail for that; see INSTALL.txt for a workaround.
Pearu, I thought I would chip in with my sugestions for ATLAS and LAPACK since I've built and tested those with ifc/icc (version 6). I would suggest building ATLAS with icc (the Intel C compiler). You can build it with gcc and link it to ifc code, but it makes life easier to use icc. I'm not sure of the speed difference between icc and gcc on ATLAS (one person said icc was slower, one said it was faster). Here are the ootions I used with icc on ATLAS: -O3 -unroll -align -tpp6 -axK -Xa Typically I modify the makefile that ATLAS creates to make sure it is correct. As for LAPACK, you have to use a couple of options to make sure the precision is correct. In particular, '-mp -pc64 -fp_port'. There is a speed lose compared to not using the flags, but I'd rather have correct answers today :) The flags I used for ifc are : -O2 -tpp6 -prefetch -align -unroll -Vaxlib -mp -pc64 -fp_port -xK -axK BTW, these flags are for an Athlon or a PIII. Also, don't forget to use the '-Vaxlib' flag during linking. Finally, after you build the LAPACK library it was recommended to me to go back and recompile xerbla.f, slamch.f, and dlamch.f using no optimization ('-O0'). Then relink the libs (I erase the final libs, recompile these 3 routines, and then run 'make libs' again). So far this process allows ATLAS to pass all of the tests and for LAPACK to pass all the tests as well. Thanks for all of your hard work this weekend! Jeff
Finally, Intel Fortran Compiler 5.0 is not supported because scipy build fails with internal compiler error when debugging flags are enabled.
Regards, Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
-- Jeff Layton Senior Engineer Lockheed-Martin Aeronautical Company - Marietta Aerodynamics & CFD "Is it possible to overclock a cattle prod?" - Irv Mullins This email may contain confidential information. If you have received this email in error, please delete it immediately, and inform me of the mistake by return email. Any form of reproduction, or further dissemination of this email is strictly prohibited. Also, please note that opinions expressed in this email are those of the author, and are not necessarily those of the Lockheed-Martin Corporation.
On Mon, 21 Oct 2002, Jeff Layton wrote:
I thought I would chip in with my sugestions for ATLAS and LAPACK since I've built and tested those with ifc/icc (version 6).
Your suggestions are welcome!
I would suggest building ATLAS with icc (the Intel C compiler). You can build it with gcc and link it to ifc code, but it makes life easier to use icc.
Hmm, actually what comes to using ATLAS in Scipy, I saw no downside of using gcc, in fact, I didn't even need to bother with this matter (I haven't installed icc either).
I'm not sure of the speed difference between icc and gcc on ATLAS (one person said icc was slower, one said it was faster).
Yes, both persons might be right: ATLAS is basically developed with gcc and optimized for that. On the other hand, icc, at least in principle, should be faster on intel processors as they know better... So, I would not recommend either of them until seeing some benchmark results.
Here are the ootions I used with icc on ATLAS:
-O3 -unroll -align -tpp6 -axK -Xa
Typically I modify the makefile that ATLAS creates to make sure it is correct.
I think, -align is set default. -O3 -unroll are good. Other options are CPU specific, hence users choice.
As for LAPACK, you have to use a couple of options to make sure the precision is correct. In particular, '-mp -pc64 -fp_port'.
-pc64 is default. Though, to get identical results with gcc, one should use -pc80 when it matters. -mp -fp_port I guess using these flags depends on applications. So, I would let users to deside about these flags. Sofar, I haven't seen any anomalies if these flags are missing.
There is a speed lose compared to not using the flags, but I'd rather have correct answers today :) The flags I used for ifc are :
-O2 -tpp6 -prefetch -align -unroll -Vaxlib -mp -pc64 -fp_port -xK -axK
BTW, these flags are for an Athlon or a PIII. Also, don't forget to use the '-Vaxlib' flag during linking.
Hmm, is '-Vaxlib' really necessary? Linkage works fine here without -Vaxlib when using ifc 6 and gcc 3.1.1. ifc -help says: -Vaxlib link with portability library I guess it doesn't matter when building locally. I don't think that we should distribute scipy binaries compiled with Intel compilers, at least not in near future. Also there might be some legal matters with respect distributing Intel binaries.
Finally, after you build the LAPACK library it was recommended to me to go back and recompile xerbla.f, slamch.f, and dlamch.f using no optimization ('-O0').
Recompiling these files (didn't know that about xerbla.f before) with -O0 is absolutely required.
Then relink the libs (I erase the final libs, recompile these 3 routines, and then run 'make libs' again). So far this process allows ATLAS to pass all of the tests and for LAPACK to pass all the tests as well. Thanks for all of your hard work this weekend!
Thanks for your notes! I'll update INSTALL.txt accordingly. Pearu
I'm not sure of the speed difference between icc and gcc on ATLAS (one person said icc was slower, one said it was faster).
Yes, both persons might be right: ATLAS is basically developed with gcc and optimized for that. On the other hand, icc, at least in principle, should be faster on intel processors as they know better... So, I would not recommend either of them until seeing some benchmark results.
It probably depends on your specific application (one was GEMM and one was GETRF).
Here are the ootions I used with icc on ATLAS:
-O3 -unroll -align -tpp6 -axK -Xa
Typically I modify the makefile that ATLAS creates to make sure it is correct.
I think, -align is set default. -O3 -unroll are good. Other options are CPU specific, hence users choice.
As for LAPACK, you have to use a couple of options to make sure the precision is correct. In particular, '-mp -pc64 -fp_port'.
-pc64 is default. Though, to get identical results with gcc, one should use -pc80 when it matters.
-mp -fp_port I guess using these flags depends on applications. So, I would let users to deside about these flags. Sofar, I haven't seen any anomalies if these flags are missing.
I'm not totally sure about LAPACK (if these options are required). However for ScaLAPACK I had to use these options or the tests would not pass. Another person also mentioned these options (I think it was Tim Prince on the Fortran newsgroup - I'll have to google for his posting again).
There is a speed lose compared to not using the flags, but I'd rather have correct answers today :) The flags I used for ifc are :
-O2 -tpp6 -prefetch -align -unroll -Vaxlib -mp -pc64 -fp_port -xK -axK
BTW, these flags are for an Athlon or a PIII. Also, don't forget to use the '-Vaxlib' flag during linking.
Hmm, is '-Vaxlib' really necessary? Linkage works fine here without -Vaxlib when using ifc 6 and gcc 3.1.1. ifc -help says:
-Vaxlib link with portability library
You're right. It may have been just for ScaLAPACK and not LAPACK nor ATLAS.
I guess it doesn't matter when building locally. I don't think that we should distribute scipy binaries compiled with Intel compilers, at least not in near future. Also there might be some legal matters with respect distributing Intel binaries.
Most definitely. Thanks! Jeff -- Jeff Layton Senior Engineer Lockheed-Martin Aeronautical Company - Marietta Aerodynamic & CFD Phone: 770-494-8341 Fax: 770-494-3055 email: jeffrey.b.layton@lmco.com "Is it possible to overclock a cattle prod?" - Irv Mullins This email may contain confidential information. If you have received this email in error, please delete it immediately, and inform me of the mistake by return email. Any form of reproduction, or further dissemination of this email is strictly prohibited. Also, please note that opinions expressed in this email are those of the author, and are not necessarily those of the Lockheed-Martin Corporation.
participants (2)
-
Jeff Layton -
Pearu Peterson