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

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.

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