Incompatability of svn 3868 distutils with v10.0 Intel compilers and MKL9.1
I recently built NumPy & SciPy from svn sources using Intel's icc 10.0, ifort 10.0, and mkl 9.1 under openSUSE 10.2. In the process, I discovered and worked around four bugs (they are just quick hacks, not proper fixes; for example, some of them break compatibilty with earlier versions of Intel compilers and MKL) in NumPy svn 3868 distutils. Bug#1: distutils/system_info.py contains the lines: else: lapack_libs = self.get_libs('lapack_libs',['mkl_lapack32','mkl_lapack64']) This will fail when MKL 9.1 is used because Intel changed the names of both 'mkl_lapack32' and 'mkl_lapack64' to 'mkl_lapack'. My work-around was to change the line to: lapack_libs = self.get_libs('lapack_libs',['mkl_lapack']) Bug#2: distutils/fcompiler/intel.py has several lines like this: 'version_cmd' : ['<F77>', None], A work-around posted by George Nurser is to change all such lines to: (may break on Visual compilers) 'version_cmd' : ['<F77>', '-V'], Bug#3: distutils/ccompiler.py has the line: compiler_class['intel'] = ('intelccompiler','IntelCCompiler', "Intel C Compiler for 32-bit applications") Unfortunately, in 10.0 Intel changed the result of icc -V to: Intel(R) C Compiler for applications running on IA-32, Version 10.0 Build 20070426 Package ID: l_cc_p_10.0.023 Copyright (C) 1985-2007 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY My work-around was to change the above to: compiler_class['intel'] = ('intelccompiler','IntelCCompiler', "Intel(R) C Compiler for applications running on IA-32") Bug#4: distutils/fcompiler/intel.py has the same id string problem that ccompiler.py had. ifort -V returns: Intel(R) Fortran Compiler for applications running on IA-32, Version 10.0 Build 20070426 Package ID: l_fc_p_10.0.023 I changed version_match = intel_version_match('32-bit') to version_match = intel_version_match('IA-32') #5 This is not a bug, but it's important to change distutils/intelccompiler.py from cc_exe = 'icc' to match the flags for your processor. For my Core 2 Duo, the line below works: cc_exe = 'icc -g -fomit-frame-pointer -xT -fast' After these changes, NumPy and SciPy built successfully, but scipy.test() returns a number of errors. The error reports are on the SciPy-dev list at the end of the thread: "Compiling scipy with Intel ifort & MKL" Perhaps this will help someone... -rex
cc_exe = 'icc -g -fomit-frame-pointer -xT -fast'
Just some comments on that : - in release mode, you should not use '-g', it slows down the execution of your program - -fast uses -xT for the moment ;) - -fomit-pointer is the default as soon as there is no -O0 or -g Matthieu
Matthieu Brucher <matthieu.brucher@gmail.com> [2007-06-14 00:39]:
cc_exe = 'icc -g -fomit-frame-pointer -xT -fast'
Just some comments on that : - in release mode, you should not use '-g', it slows down the execution of your
I didn't look it up; it was carried over from an example. I agree.
program - -fast uses -xT for the moment ;)
So it does. I missed it. :(
- -fomit-pointer is the default as soon as there is no -O0 or -g
Didn't know this. I hope to put some detailed openSUSE 10.2 specific build instructions from source (both for gcc and Intel software) on the SciPy wiki, and your corrections are helpful. Thanks. -rex -- "Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing ever happened." --Winston Churchill
Hello all On Thu, 14 Jun 2007, Matthieu Brucher wrote:
cc_exe = 'icc -g -fomit-frame-pointer -xT -fast'
Just some comments on that : - in release mode, you should not use '-g', it slows down the execution of your program
Do you have a reference that explains this in more detail? I thought -g just added debug information without changing the generated code? Regards, Albert
On Thu, Jun 14, 2007 at 04:17:04PM +0200, Albert Strasheim wrote:
Hello all
On Thu, 14 Jun 2007, Matthieu Brucher wrote:
cc_exe = 'icc -g -fomit-frame-pointer -xT -fast'
Just some comments on that : - in release mode, you should not use '-g', it slows down the execution of your program
Do you have a reference that explains this in more detail? I thought -g just added debug information without changing the generated code?
I had a peek at the icc manual. For icc, -g by itself implies -O0 and -fno-omit-frame-pointer, so it will be slower. However, -g -O2 -fomit-frame-pointer shouldn't be any slower than without the -g. For gcc, -g does what you said. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
Do you have a reference that explains this in more detail? I thought -g just added debug information without changing the generated code?
My understanding was that there was debug info added - well, in release mode, it is not worth it, impossible to debug -, and these added data can impact performance in jumps, loading times, ... Matthieu
participants (4)
-
Albert Strasheim -
David M. Cooke -
Matthieu Brucher -
rex