Compiling Python on Linux with Intel's icc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling Python on Linux with Intel's icc

Alex Leach
Dear Python Devs,

I've been attempting to compile a fully functional version of Python 2.7 using
Intel's C compiler, having built supposedly optimal versions of numpy and
scipy, using Intel Composer XE and Intel's Math Kernel Library. I can build a
working Python binary, but I'd really appreciate if someone could check my
compile options, and perhaps suggest ways I could further optimise the build.

*** COMPILE FAILURE - ffi64.c ***

I've managed to compile everything in the python distribution except for
Modules/_ctypes/libffi/src/x86/ffi64.c. So to get the compilation to actually
work, I've had to use the config option '--with-system-ffi'. If someone could
suggest a patch for ffi64.c, I'd happily test it, as I've been unable to fix the
code myself! The problem is with register_args, which uses GCC's __int128_t,
but this doesn't exist when using icc.

The include guard to use could be:-
#ifdef __INTEL_COMPILER
...
#else
...
#endif

I've tried using this guard around the register_args struct, at the top of
ffi64.c, and where I see register_args used, around lines 592-616, according to
the suggestion at http://software.intel.com/en-
us/forums/showthread.php?t=56652, but have been unable to get a working
solution... A patch would be appreciated!

*** Tests ***

After compilation, there's a few tests that are consistently failing, mainly
involved with floating point precision: test_cmath, test_math and test_float.  
Also, I wrote a very short script to test the time of for loop execution and
integer multiplication. This script (below) has nearly always completed faster
using the default Ubuntu Python rather than my own build.

Obviously, I was hoping to get a faster python, but the size of the final
binary is almost twice the size of the default Ubuntu version (5.2MB cf.
2.7MB), which I thought might cause a startup overhead that leads to slower
execution times when running such a basic script.


*** TEST SCRIPT ***
$ cat ~/bin/timetest.py

RANGE = 10000

print "running {0}^2 = {1} for loop iterations".format( RANGE,RANGE**2 )

for i in xrange(RANGE):
    for j in xrange(RANGE):
        i * j


*** TIMES ***

## ICC-compiled python ##
$ time ./python ~/bin/timetest.py
running 10000^2 = 100000000 for loop iterations

real    0m2.767s
user    0m2.720s
sys     0m0.008s


## System python ##
$ time python ~/bin/timetest.py
running 10000^2 = 100000000 for loop iterations

real    0m2.781s
user    0m2.776s
sys     0m0.000s

Oh... My python appears to run faster than gcc's now - checked this a few
times now, mine's staying faster... :) I've compiled and re-compiled python
dozens of times now, but it's still failing some tests...


*** Build Environment ***

Ubuntu 10.10 server kernel (`uname -r`=3.0.0-16-server) with KDE 4.7.4

$ tail ~/.bashrc

#### Custom Commands
export PATH=$PATH:/usr/local/cuda/bin:$HOME/bin
export PYTHONPATH=$HOME/bin:/usr/lib/pymodules/python2.7
export PYTHONSTARTUP=$HOME/.pystartup
export
LD_LIBRARY_PATH=/lib64:/usr/lib64:/usr/local/lib:/usr/local/cuda/lib64:/usr/local/cuda/lib
# Load Intel compiler and library variables.
source /usr/intel/bin/compilervars.sh intel64
source /usr/intel/impi/4.0.3/bin/mpivars.sh intel64
source /usr/intel/tbb/bin/tbbvars.sh intel64

$ env | grep 'PATH\|FLAGS'
MANPATH=/usr/intel/impi/4.0.3.008/man:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/intel/impi/4.0.3.008/man:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/intel/impi/4.0.3.008/man:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/intel/composer_xe_2011_sp1.9.293/man/en_US:/usr/local/man:/usr/local/share/man:/usr/share/man:/usr/intel/man:::
LIBRARY_PATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/../compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21
FPATH=/usr/intel/composer_xe_2011_sp1.9.293/mkl/include:/usr/intel/composer_xe_2011_sp1.9.293/mkl/include
LD_LIBRARY_PATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/impi/4.0.3.008/ia32/lib:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/../compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/biol/arb/lib:/lib64:/usr/lib64:/usr/local/lib:/usr/local/cuda/lib64:/usr/local/cuda/lib:/usr/intel/composer_xe_2011_sp1.9.293/debugger/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/lib/intel64
CPATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/include:/usr/intel/composer_xe_2011_sp1.9.293/mkl/include:/usr/intel/composer_xe_2011_sp1.9.293/tbb/include
NLSPATH=/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64/locale/%l_%t/%N:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64/locale/%l_%t/%N:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64/locale/%l_%t/%N:/usr/intel/composer_xe_2011_sp1.9.293/debugger/intel64/locale/%l_%t/%N
PATH=/usr/intel/impi/4.0.3.008/ia32/bin:/usr/intel/composer_xe_2011_sp1.9.293/bin/intel64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/intel/bin:/usr/local/cuda/bin:/usr/local/cuda/bin:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/bin/intel64
PYTHONPATH=/usr/lib/pymodules/python2.7/
WINDOWPATH=7
QT_PLUGIN_PATH=$HOME/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/

*** Download, configure and Build instructions ***
$ hg clone -r 2.7 http://hg.python.org/cpython
Since...
$ hg update -r 2.7

*** Generate Profile-Guided Optimisation stuff with first build ***
$ make distclean && mkdir PGO
$ CC=icc AR=xiar LD=xild CXX=icpc \
   CPPFLAGS+="-I/usr/include \
        -I/usr/include/x86_86-linux-gnu \
        -I/usr/src/linux-headers-3.0.0-16-server/include/" \
   CFLAGS+="-O3 \
        -fomit-frame-pointer \
        -shared-intel \
        -fpic \
        -prof-gen \
        -prof-dir $PWD/PGO \
        -fp-model precise \
        -fp-model source \
        -xHost \
        -ftz"
   ./configure --with-system-ffi --with-libc="-lirc" --with-libm="-limf"
$ make -j9

*** Use the PGO-generated information in new build ***
$ make clean
$ CC=icc AR=xiar LD=xild CXX=icpc \
   CPPFLAGS+="-I/usr/include \
        -I/usr/include/x86_86-linux-gnu \
        -I/usr/src/linux-headers-3.0.0-16-server/include/" \
   CFLAGS+="-O3 \
        -fomit-frame-pointer \
        -shared-intel \
        -fpic \
        -prof-use \
        -prof-dir $PWD/PGO \
        -fp-model precise \
        -fp-model source \
        -xHost \
        -ftz \
        -fomit-frame-pointer" \
   ./configure --with-system-ffi --with-libc="-lirc" --with-libm="-limf"
$ make -j9
...

$ make test
building dbm using gdbm

Python build finished, but the necessary bits to build these modules were not
found:
_bsddb             bsddb185           dl              
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the
module's name.

find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -l
/usr/local/src/pysrc/cpython/Lib/unittest/util.py:2: ImportWarning: Not
importing directory '/usr/local/src/pysrc/cpython/Lib/collections': missing
__init__.py
  from collections import namedtuple, OrderedDict
== CPython 2.7.3rc1 (2.7:5c52e7c6d868+, Feb 29 2012, 22:10:22) [GCC Intel(R)
C++ gcc 4.6 mode]
==   Linux-3.0.0-16-server-x86_64-with-debian-wheezy-sid little-endian
==   /usr/local/src/pysrc/cpython/build/test_python_16278
Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1,
division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0,
no_user_site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0,
unicode=0, bytes_warning=0, hash_randomization=0)

.........

test_cmath
test test_cmath failed -- Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_cmath.py", line 352, in
test_specific_values
    msg=error_message)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_cmath.py", line 94, in
rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: acos0000: acos(complex(0.0, 0.0))
Expected: complex(1.5707963267948966, -0.0)
Received: complex(1.5707963267948966, 0.0)
Received value insufficiently close to expected value.
...
test_curses skipped -- Use of the `curses' resource not enabled
...
test_float
test test_float failed -- Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_float.py", line 1273, in
test_from_hex
    self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_float.py", line 983, in
identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: 0.0 not identical to 2.2250738585072014e-308
.....
test test_strtod failed -- multiple errors occurred; run in verbose mode for
details
......


347 tests OK.
5 tests failed:
    test_cmath test_float test_gdb test_math test_strtod
1 test altered the execution environment:
    test_distutils
37 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gl test_imageop test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib
    test_ossaudiodev test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
4 skips unexpected on linux2:
    test_bsddb test_bsddb3 test_tk test_ttk_guionly
make: *** [test] Error 1







*** Drill down to test_strtod error ***

$ ./python
Python 2.7.3rc1 (2.7:5c52e7c6d868+, Feb 29 2012, 22:10:22)
[GCC Intel(R) C++ gcc 4.6 mode] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import test_strtod
>>> test_strtod.test_main()
test_bigcomp (test.test_strtod.StrtodTests) ... FAIL
test_boundaries (test.test_strtod.StrtodTests) ... FAIL
test_halfway_cases (test.test_strtod.StrtodTests) ... ok
test_parsing (test.test_strtod.StrtodTests) ... FAIL
test_particular (test.test_strtod.StrtodTests) ... FAIL
test_short_halfway_cases (test.test_strtod.StrtodTests) ... ok
test_underflow_boundary (test.test_strtod.StrtodTests) ... FAIL

======================================================================
FAIL: test_bigcomp (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 214, in
test_bigcomp
    self.check_strtod(s)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 105, in
check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: Incorrectly rounded str->float conversion for 81608e-328:
expected 0x0.0000000000002p-1022, got 0x0.0p+0

======================================================================
FAIL: test_boundaries (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 191, in
test_boundaries
    self.check_strtod(s)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 105, in
check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: Incorrectly rounded str->float conversion for
22250738585072002149149e-330: expected 0x0.ffffffffffffep-1022, got 0x0.0p+0

======================================================================
FAIL: test_parsing (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 243, in
test_parsing
    self.check_strtod(s)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 105, in
check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: Incorrectly rounded str->float conversion for -6.E-310:
expected -0x0.06e7344a56502p-1022, got -0x0.0p+0

======================================================================
FAIL: test_particular (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 393, in
test_particular
    self.check_strtod(s)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 105, in
check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: Incorrectly rounded str->float conversion for
12579816049008305546974391768996369464963024663104e-357: expected
0x0.90bbd7412d19fp-1022, got 0x0.0p+0

======================================================================
FAIL: test_underflow_boundary (test.test_strtod.StrtodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 205, in
test_underflow_boundary
    self.check_strtod(s)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 105, in
check_strtod
    "expected {}, got {}".format(s, expected, got))
AssertionError: Incorrectly rounded str->float conversion for
24703282292062327208828439643411068618252990130716238221279284125033775363572e-400:
expected 0x0.0000000000001p-1022, got 0x0.0p+0

----------------------------------------------------------------------
Ran 7 tests in 0.280s

FAILED (failures=5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/src/pysrc/cpython/Lib/test/test_strtod.py", line 396, in
test_main
    test_support.run_unittest(StrtodTests)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_support.py", line 1094, in
run_unittest
    _run_suite(suite)
  File "/usr/local/src/pysrc/cpython/Lib/test/test_support.py", line 1077, in
_run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred


*** Binary size and linked libraries ***
## My Intel build ##
$ ls -l ./python && ldd ./python
-rwxrwxr-x 1 user user 5.2M 2012-02-29 22:10 ./python
        linux-vdso.so.1 =>  (0x00007fffde1ec000)
        libirc.so =>
/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64/libirc.so
(0x00007fe5f0f30000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fe5f0cde000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe5f0ada000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
(0x00007fe5f08d7000)
        libimf.so =>
/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64/libimf.so
(0x00007fe5f050b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe5f0287000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fe5f0071000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe5efcd1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe5f107e000)
        libintlc.so.5 =>
/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64/libintlc.so.5
(0x00007fe5efb85000)

## System build ##
$ ls -lhH /usr/bin/python && ldd /usr/bin/python
-rwxr-xr-x 1 root root 2.7M 2011-10-04 22:26 /usr/bin/python
        linux-vdso.so.1 =>  (0x00007fff509ff000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f3e339b0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3e337ab000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1
(0x00007f3e335a8000)
        libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x00007f3e33357000)
        libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x00007f3e32fa7000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3e32d8f000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3e32b0b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e3276b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3e33c03000)


*** Conclusion (finally!) ***
The Intel Python build looks very promising, but I don't yet trust it to the
extent that I'd to go ahead and install it or use it in place of the system
build. None of the errors look too alarming though, so I'm confident that I
could actually get this to work, with the right help.

If someone could help me pass these final tests and compile the ffi64.c module,
that'd be amazing!

I hope to hear back from you,
Kind regards,
Alex

ps. Sorry how long this email turned out!
pps. I'd be happy to write up the fully working solution on a wiki or
somewhere, if anyone has any suggestions where?

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Stefan Krah-3
Hi,

Alex Leach <[hidden email]> wrote:
> I've managed to compile everything in the python distribution except for
> Modules/_ctypes/libffi/src/x86/ffi64.c.

There is an issue for this:

http://bugs.python.org/issue4130


> After compilation, there's a few tests that are consistently failing, mainly
> involved with floating point precision: test_cmath, test_math and test_float.

I think you have to compile with "-fp-model strict".


In general, please submit suspected bugs on http://bugs.python.org/
(after searching the archives) and post things like speed comparisons on
[hidden email].


Stefan Krah


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach
In reply to this post by Alex Leach
Stefan Krah <stefan at bytereef.org> wrote:

> Alex Leach <albl500 at york.ac.uk> wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
> 
> There is an issue for this:
> 
> http://bugs.python.org/issue4130

Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only had one post (from you I see), and no proposed fix. The link you posted there is the same link I posted (somewhere) in my previous email...

> > After compilation, there's a few tests that are consistently failing, mainly
> > involved with floating point precision: test_cmath, test_math and test_float.
> 
> I think you have to compile with "-fp-model strict".
> 

Thanks, I'll give that a go and will report back!

> 
> In general, please submit suspected bugs on http://bugs.python.org/
> (after searching the archives) and post things like speed comparisons on> python-list at python.org.
> 

Thanks again. My only other concern is with distutils, as it doesn't support icc on a Xeon.
However, numpy.distutils is almost compatible. I've had to make some mods to the flags in numpy.distutils.intelccompiler and numpy.distutils.fcompiler.intel, but it would be nice if this support was also included in the standard distutils...
Can the numpy version be used in place of the standard distutils? Again, there's probably a more proper place to ask... I'll suggest patches for these numpy modules to the numpy devs, but it would be nice if the core python distutils supported icc too.

Thanks for your time!
Kind regards,
Alex

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach
In reply to this post by Alex Leach
Stefan Krah <stefan at bytereef.org> wrote:

> Alex Leach <albl500 at york.ac.uk> wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
>
> There is an issue for this:
>
> http://bugs.python.org/issue4130

Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only
had one post (from you I see), and no proposed fix. The link you posted there
is the same link I posted (somewhere) in my previous email...

> > After compilation, there's a few tests that are consistently failing,
mainly
> > involved with floating point precision: test_cmath, test_math and
test_float.
>
> I think you have to compile with "-fp-model strict".
>

Thanks, I'll give that a go and will report back!

>
> In general, please submit suspected bugs on http://bugs.python.org/
> (after searching the archives) and post things like speed comparisons on>
python-list at python.org.
>

Thanks again. My only other concern is with distutils, as it doesn't support
icc on a Xeon. However, numpy.distutils is almost compatible. I've had to make
some mods to the flags in numpy.distutils.intelccompiler and
numpy.distutils.fcompiler.intel, but it would be nice if this support was also
included in the standard distutils...

Can the numpy version be used in place of the standard distutils? Again,
there's probably a more proper place to ask... I'll suggest patches for these
numpy modules to the numpy devs, but it would be nice if the core python
distutils supported icc too.

Thanks for your time!
Kind regards,
Alex
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach
In reply to this post by Alex Leach
Stefan Krah <stefan at bytereef.org> wrote:

> Alex Leach <albl500 at york.ac.uk> wrote:
> > I've managed to compile everything in the python distribution except for
> > Modules/_ctypes/libffi/src/x86/ffi64.c.
>
> There is an issue for this:
>
> http://bugs.python.org/issue4130

Yes, I saw that bug report, but it looked dormant. It is. In 4 years it's only
had one post (from you I see), and no proposed fix. The link you posted there
is the same link I posted (somewhere) in my previous email...

> > After compilation, there's a few tests that are consistently failing,
mainly
> > involved with floating point precision: test_cmath, test_math and
test_float.
>
> I think you have to compile with "-fp-model strict".
>

Thanks, I'll give that a go and will report back!

>
> In general, please submit suspected bugs on http://bugs.python.org/
> (after searching the archives) and post things like speed comparisons on>
python-list at python.org.
>

Thanks again. My only other concern is with distutils, as it doesn't support
icc on a Xeon.

However, numpy.distutils is almost compatible. I've had to make some mods to
the flags in numpy.distutils.intelccompiler and
numpy.distutils.fcompiler.intel, but it would be nice if this support was also
included in the global distutils...

Can the numpy version be used in place of the standard distutils? Again,
there's probably a more proper place to ask... I'll suggest patches for these
numpy modules to the numpy devs, but it would be nice if the core python
distutils supported icc too.

Thanks for your time!
Kind regards,
Alex

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Éric Araujo
Hi,

Le 02/03/2012 11:55, Alex Leach a écrit :
> My only other concern is with distutils, as it doesn't support
> icc on a Xeon.

Could you expand on that?  distutils is supposed to support all
unix-like C compilers.

Regards
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach-2
In reply to this post by Alex Leach
> Éric Araujo <merwok at netwok.org> wrote:
>
> Could you expand on that?  distutils is supposed to support all
> unix-like C compilers.

Packages that use the numpy distutils can be built with the following
options:-

$ python setup.py config --compiler=intelem --fcompiler=intelem build --
compiler=intelem install

This allows distutils to set the appropriate compile flags. Modules built with
the normal distutils always raise warnings about unsupported flags,
e.g. -fwrapv.

icc needs to calm down a bit on certain floating point arithmetic
optimisations, needing some option like '-fp-model strict', as Stefan
suggested. '-xHost' is a good flag to use too, allowing icc to detect the CPU
type, and use appropriate optimisations.

The only way I can build modules now is by using environment variables,
e.g:-

$ CC=icc CXX=icpc LD=xild AR=xiar python setup.py config build build_ext

But this then uses gcc-specific flags when compiling.

Cheers,
Alex
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Stefan Krah-3
In reply to this post by Alex Leach
Alex Leach <[hidden email]> wrote:
> > http://bugs.python.org/issue4130
>
> Yes, I saw that bug report, but it looked dormant.

If a bug report is dormant, you have to wake it up by subscribing to the issue
and leaving a comment. The particular case is a low priority issue since icc
defines __GNUC__ and should therefore support the types in question.


Stefan Krah


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Antoine Pitrou
In reply to this post by Alex Leach
On Thu, 01 Mar 2012 18:39:19 +0000
Alex Leach <[hidden email]> wrote:
>
> Obviously, I was hoping to get a faster python, but the size of the final
> binary is almost twice the size of the default Ubuntu version (5.2MB cf.
> 2.7MB), which I thought might cause a startup overhead that leads to slower
> execution times when running such a basic script.

Did you compare the actual code sizes? The `size` command can help you
with that.

> *** TEST SCRIPT ***
> $ cat ~/bin/timetest.py
>
> RANGE = 10000
>
> print "running {0}^2 = {1} for loop iterations".format( RANGE,RANGE**2 )
>
> for i in xrange(RANGE):
>     for j in xrange(RANGE):
>         i * j

That's an extremely silly benchmark, unlikely to be representative of
any actual Python workload. I suggest you try a less-trivial benchmark
suite, such as: http://hg.python.org/benchmarks/

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach
On 02/03/2012 14:52, "Antoine Pitrou" <[hidden email]> wrote:


>
>Did you compare the actual code sizes? The `size` command can help you
>with that.

I'd never used `size` before... Thanks for the tip; looks like the Intel
build is actually smaller..? :/

# ICC version (`ls -lh` ==> 4.7MB)
$ size ./python
   text    data     bss     dec     hex filename
1659760  276904   63760 2000424  1e8628 ./python

# System version (`ls -lhH` ==>2.7MB)
$ size /usr/bin/python
   text    data     bss     dec     hex filename
2303805  427728   74808 2806341  2ad245 /usr/bin/python

I definitely don't get what's going on here! Does this information relate
to linked objects being in shared or static libs? Is this indicative
anything, either good or bad?



>
>That's an extremely silly benchmark, unlikely to be representative of
>any actual Python workload. I suggest you try a less-trivial benchmark
>suite, such as: http://hg.python.org/benchmarks/

lol, yes it is a silly benchmark! Still, when I first started compiling
python, without any optimisation options, this silly little script took up
to 6-8x more time to process than the default GCC version. (~17s cf. <3s).
And the script hardly took that long to write!

Thanks for the benchmark recommendation; I'll use that on the next build -
hopefully after passing the math tests!

Cheers,
Alex

>


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Antoine Pitrou
On Fri, 02 Mar 2012 16:29:39 +0000
Alex Leach <[hidden email]> wrote:

> >
> >Did you compare the actual code sizes? The `size` command can help you
> >with that.
>
> I'd never used `size` before... Thanks for the tip; looks like the Intel
> build is actually smaller..? :/
>
> # ICC version (`ls -lh` ==> 4.7MB)
> $ size ./python
>    text    data     bss     dec     hex filename
> 1659760  276904   63760 2000424  1e8628 ./python
>
> # System version (`ls -lhH` ==>2.7MB)
> $ size /usr/bin/python
>    text    data     bss     dec     hex filename
> 2303805  427728   74808 2806341  2ad245 /usr/bin/python
>
> I definitely don't get what's going on here! Does this information relate
> to linked objects being in shared or static libs? Is this indicative
> anything, either good or bad?

Mmmh, your system version might have been compiled with different
options, so you may want to compare with a hand-compiled gcc build. The
"text" column gives you the code size. Arguably, a smaller code size
will make the instruction cache more efficient.

cheers

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Stefan Krah-3
In reply to this post by Stefan Krah-3
Alex Leach <[hidden email]> wrote:
> Can you translate Intel's suggestion into a patch for ffi64?

Well probably, but this really belongs on the bug tracker. Also, as I said,
there are many issues with higher priority.


Stefan Krah


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: Compiling Python on Linux with Intel's icc

Alex Leach
Thought I'd tie this thread up with a successful method, as I've just compiled Python-2.7.3 and have got the benchmarks to run slightly faster than the system Python :D

** First benchmark **

metabuntu:benchmarks> python perf.py -r -b apps /usr/bin/python ../Python-2.7.3/python
Running 2to3...
INFO:root:Running ../Python-2.7.3/python lib/2to3/2to3 -f all lib/2to3_data
INFO:root:Running `['../Python-2.7.3/python', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3_data']` 5 times
INFO:root:Running /usr/bin/python lib/2to3/2to3 -f all lib/2to3_data
INFO:root:Running `['/usr/bin/python', 'lib/2to3/2to3', '-f', 'all', 'lib/2to3_data']` 5 times
Running html5lib...
INFO:root:Running ../Python-2.7.3/python performance/bm_html5lib.py -n 1
INFO:root:Running `['../Python-2.7.3/python', 'performance/bm_html5lib.py', '-n', '1']` 10 times
INFO:root:Running /usr/bin/python performance/bm_html5lib.py -n 1
INFO:root:Running `['/usr/bin/python', 'performance/bm_html5lib.py', '-n', '1']` 10 times
Running rietveld...
INFO:root:Running ../Python-2.7.3/python performance/bm_rietveld.py -n 100
INFO:root:Running /usr/bin/python performance/bm_rietveld.py -n 100
Running spambayes...
INFO:root:Running ../Python-2.7.3/python performance/bm_spambayes.py -n 100
INFO:root:Running /usr/bin/python performance/bm_spambayes.py -n 100

Report on Linux metabuntu 3.0.0-19-server #32-Ubuntu SMP Thu Apr 5 20:05:13 UTC 2012 x86_64 x86_64
Total CPU cores: 12

### html5lib ###
Min: 8.132508 -> 7.316457: 1.11x faster
Avg: 8.297318 -> 7.460066: 1.11x faster
Significant (t=11.15)
Stddev: 0.21605 -> 0.09843: 2.1950x smaller
Timeline: http://tinyurl.com/bqql4oa

### rietveld ###
Min: 0.297604 -> 0.276587: 1.08x faster
Avg: 0.302667 -> 0.279202: 1.08x faster
Significant (t=37.06)
Stddev: 0.00529 -> 0.00348: 1.5188x smaller
Timeline: http://tinyurl.com/brb3dk5

### spambayes ###
Min: 0.152264 -> 0.143518: 1.06x faster
Avg: 0.156512 -> 0.146559: 1.07x faster
Significant (t=6.66)
Stddev: 0.00847 -> 0.01232: 1.4547x larger
Timeline: http://tinyurl.com/d2dzz6k

The following not significant results are hidden, use -v to show them:
2to3.

( I just noticed the date's wrong in the above report... But I did run that just now, being April 14th 2012, ~1300GMT )



** Required patch **

Only file that breaks compilation is Modules/_ctypes/libffi/src/x86/ffi64.c
I uploaded a patch to http://bugs.python.org/issue4130 that corrects the __int128_t issue.



** Compilation method **

I used a two-step compilation process, with Profile-Guided Optimisation. Relevant environment variables are at the bottom.
In the build directory, make a separate directory for the PGO files.
 mkdir PGO
Then, configure command:-
CFLAGS="-O3 -fomit-frame-pointer -shared-intel -fpic -prof-gen -prof-dir $PWD/PGO -fp-model strict -no-prec-div -xHost -fomit-frame-pointer" \
        ./configure --with-libm="-limf" --with-libc="-lirc" --with-signal-module --with-cxx-main="icpc" --without-gcc --build=x86_64-linux-intel

Then I ran `make -j9` and `make test`. Running the tests ensures that (almost) every module is run at least once.
As the -prof-gen option was used, this means that PGO information is written to files in -prof-dir, when the binaries are running.
To give the code even more rigorous usage, I also ran the benchmark suite, which generates even more PGO information.
The results are useless though.

Then, need to do a `make clean`, and reconfigure.
This time, add "-ipo" to CFLAGS, enabling inter-procedural optimisation, and change "-prof-gen" for "-prof-use":-
CFLAGS="-O3 -fomit-frame-pointer -ipo -shared-intel -fpic -prof-use -prof-dir $PWD/PGO -fp-model strict -no-prec-div -xHost -fomit-frame-pointer" \
        ./configure --with-libm="-limf" --with-libc="-lirc" --with-signal-module --with-cxx-main="icpc" --without-gcc --build=x86_64-linux-intel
Then, of course make -j9 && make test

At this point, I produced the above benchmark results.



** Failed test summary **

I'm happy with most of them, except I don't get what the test_gdbm failure is on about..?
I should probably add --enable-curses to the configure command, and I wouldn't mind getting the network and audio modules to build,
but I can't see any relevant configure options nor find any missing dependencies. Any suggestions would be appreciated.

349 tests OK.
2 tests failed:
    test_cmath test_gdb
1 test altered the execution environment:
    test_distutils
37 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_dl test_gl test_imageop test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib
    test_ossaudiodev test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
2 skips unexpected on linux2:
    test_bsddb test_bsddb3

test test_cmath failed -- Traceback (most recent call last):
  File "/usr/local/src/pysrc/Python-2.7.3/Lib/test/test_cmath.py", line 352, in test_specific_values
    msg=error_message)
  File "/usr/local/src/pysrc/Python-2.7.3/Lib/test/test_cmath.py", line 94, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: acos0000: acos(complex(0.0, 0.0))
Expected: complex(1.5707963267948966, -0.0)
Received: complex(1.5707963267948966, 0.0)
Received value insufficiently close to expected value.

test test_gdb failed -- Traceback (most recent call last):
  File "/usr/local/src/pysrc/Python-2.7.3/Lib/test/test_gdb.py", line 639, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/usr/local/src/pysrc/Python-2.7.3/Lib/test/test_gdb.py", line 146, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: 'Traceback (most recent call last):\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1367, in invoke\n    move_in_stack(move_up=True)\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1347, in move_in_stack\n    iter_frame.print_summary()\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1255, in print_summary\n    line = pyop.current_line()\nAttributeError: \'PyIntObjectPtr\' object has no attribute \'current_line\'\nError occurred in Python command: \'PyIntObjectPtr\' object has no attribute \'current_line\'\nTraceback (most recent call last):\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1367, in invoke\n    move_in_stack(move_up=True)\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1347, in move_in_stack\n    iter_frame.print_summary()\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1255, in print_summary\n    line = pyop.current_line()\nAttributeError: \'PyIntObjectPtr\'
 object has no attribute \'current_line\'\nError occurred in Python command: \'PyIntObjectPtr\' object has no attribute \'current_line\'\nTraceback (most recent call last):\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1367, in invoke\n    move_in_stack(move_up=True)\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1347, in move_in_stack\n    iter_frame.print_summary()\n  File "/usr/local/src/pysrc/Python-2.7.3/python-gdb.py", line 1255, in print_summary\n    line = pyop.current_line()\nAttributeError: \'PyIntObjectPtr\' object has no attribute \'current_line\'\nError occurred in Python command: \'PyIntObjectPtr\' object has no attribute \'current_line\'\n' != ''



********

Next attempt:-
Gonna try with: --enable-curses, --enable-audio, --enable-network and --enable-ipv6. May as well do that now...
added above switches to configure command.
Also, switched -shared-intel for -static-intel, to compare benchmark times. This seems to hardly impact performance or file size...

CFLAGS="-O3 -fomit-frame-pointer -ipo -static-intel -fpic -prof-use -prof-dir $PWD/PGO -fp-model strict -no-prec-div -xHost -fomit-frame-pointer" \
        ./configure --with-libm="-limf" --with-libc="-lirc" --with-signal-module --with-cxx-main="icpc" --without-gcc --enable-curses --enable-ipv6 --enable-network --enable-audio --enable-gui --build=x86_64-linux-intel



** Test results **

This time I ran regrtest.py manually, to enable the networking and audio tests in particular:-
metabuntu:Python-2.7.3> ./python Lib/test/regrtest.py -uall

test_linuxaudiodev just hung, even after killing processes (pulseaudio) which were using /dev/dsp, so I added 'test_linuxaudiodev' to NOTTESTS in Lib/test/regrtest.py

361 tests OK.
3 tests failed:
    test_cmath test_gdb test_ossaudiodev
1 test altered the execution environment:
    test_distutils
23 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_dl test_gl test_imageop
    test_imgfile test_kqueue test_macos test_macostools test_msilib
    test_py3kwarn test_scriptpackages test_startfile test_sunaudiodev
    test_winreg test_winsound test_zipfile64
2 skips unexpected on linux2:
    test_bsddb test_bsddb3

I use ALSA over OSS, so I'm not really concerned about the OSS test failing.
Running test_linuxaudiodev manually hangs on test_play_sound_file. Tested with pulseaudio running, and not running. Test can only be terminated with KILL signal.
Adding some print statements to the test script, I found the test hangs on `self.dev.write(data)`. Not sure why though..?



** New benchmark **

metabuntu:benchmarks> python perf.py -r -b apps /usr/bin/python ../Python-2.7.3/python

Report on Linux metabuntu 3.0.0-19-server #32-Ubuntu SMP Thu Apr 5 20:05:13 UTC 2012 x86_64 x86_64
Total CPU cores: 12

### 2to3 ###
Min: 6.524408 -> 6.316394: 1.03x faster
Avg: 6.611613 -> 6.392400: 1.03x faster
Significant (t=5.05)
Stddev: 0.06477 -> 0.07228: 1.1159x larger
Timeline: http://tinyurl.com/bub35l9

### html5lib ###
Min: 7.916494 -> 7.212451: 1.10x faster
Avg: 8.025302 -> 7.304856: 1.10x faster
Significant (t=17.53)
Stddev: 0.07606 -> 0.10539: 1.3856x larger
Timeline: http://tinyurl.com/dy7296k

### rietveld ###
Min: 0.291469 -> 0.272601: 1.07x faster
Avg: 0.302746 -> 0.280126: 1.08x faster
Significant (t=15.86)
Stddev: 0.01126 -> 0.00874: 1.2885x smaller
Timeline: http://tinyurl.com/c5ys4bt

### spambayes ###
Min: 0.145370 -> 0.138528: 1.05x faster
Avg: 0.146689 -> 0.141168: 1.04x faster
Significant (t=11.27)
Stddev: 0.00147 -> 0.00468: 3.1885x larger
Timeline: http://tinyurl.com/d8rrp6g



** Relevant Environment Variables. (Maybe there's more, maybe less) **

N.B. I have all Intel stuff installed in /usr/intel. The default is /opt/intel though.

LIBRARY_PATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/../compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/../compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21
LD_LIBRARY_PATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/intel/impi/4.0.3.008/ia32/lib:/usr/intel/impi/4.0.3.008/intel64/lib:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/../compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/ipp/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/compiler/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mkl/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/usr/local/lib/boost:/biol/arb/lib:/lib64:/usr/lib64:/usr/local/lib:/usr/local/cuda/lib64:/usr/local/cuda/lib:/usr/intel/composer_xe_2011_sp1.9.293/debugger/lib/intel64:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/lib/intel64
CPATH=/usr/intel/composer_xe_2011_sp1.9.293/tbb/include:/usr/intel/composer_xe_2011_sp1.9.293/mkl/include:/usr/intel/composer_xe_2011_sp1.9.293/tbb/include:/usr/intel/composer_xe_2011_sp1.9.293/tbb/include:/usr/intel/composer_xe_2011_sp1.9.293/mkl/include:/usr/intel/composer_xe_2011_sp1.9.293/tbb/include
CPP=icc -E
PATH=/usr/intel/impi/4.0.3.008/ia32/bin:/usr/intel/impi/4.0.3.008/intel64/bin:/usr/intel/composer_xe_2011_sp1.9.293/bin/intel64:/usr/intel/impi/4.0.3.008/ia32/bin:/usr/intel/composer_xe_2011_sp1.9.293/bin/intel64:/home/albl500/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/intel/bin:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/bin/intel64:/home/albl500/SDKs/android-sdk-linux/tools:/biol/bin:/biol/arb/bin:/usr/local/cuda/bin:/home/albl500/bin:/usr/intel/composer_xe_2011_sp1.9.293/mpirt/bin/intel64
LD=xild
CXX=icpc
CC=icc


** Summary **

All seems okay to me, although using -no-prev-div (over IEEE floating point arithmetic) is slightly concerning, as I occasionally require very accurate floating point arithmetic.
I try to use numpy as much as possible for math operations though, so maybe it's not concerning at all... "-no-prec-div" and "-fp-model strict" I think are required to pass various math tests though.
Otherwise, I got errors about extremely small floats (<10^-300) being unequal to 0.

I hope this proves useful for anyone else trying to compile an optimised Python for an Intel system.

Cheers,
Alex

--
Alex Leach BSc. MRes.
Department of Biology
University of York
York YO10 5DD
United Kingdom
www: http://bioltfws1.york.ac.uk/~albl500
EMAIL DISCLAIMER: http://www.york.ac.uk/docs/disclaimer/email.htm
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com