Mailman 3 December 2005 - SciPy-Dev

linear_least_squares problem
by Alan G Isaac Dec. 11, 2005

Dec. 11, 2005

The basic_lite the function linear_least_squares begins with the statements: a = asndarray(a) b = asndarary(b) The first produces an error: File "C:\Python24\lib\site-packages\scipy\basic\basic_lite.py", line 414, in linear_least_squares a = asndarray(a) NameError: global name 'asndarray' is not defined The second is in any case misspelled. Changing both to asarray allows the function to work; is it the right solution? Alan Isaac

1 0

Arange has been sped up
by Travis Oliphant Dec. 11, 2005

Dec. 11, 2005

Friends, I've just sped up arange using individual filling loops like numarray does -- and added (untested) complex arange functionality. The benchmarks are showing a marked improvement in the arange function for scipy over its previous performance. Thanks for the testing. Remember this is with a debug-build for scipy on an AMD chip. Python 2.4.2 (#1, Nov 14 2005, 21:26:13) [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] Optimization flags: -g -Wall -Wstrict-prototypes CPU info: getNCPUs has_3dnow has_3dnowext has_mmx is_32bit is_AMD is_singleCPU Numeric-24.2 numarray-1.5.1 scipy-core-0.8.2.1627 benchmark size = 10 (vectors of length 1048576) label Numeric numarray scipy.base 1 0.1377 0.0505 0.02734 2 0.1017 0.1063 0.09208 3 0.07226 0.07828 0.0825 4 0.4258 0.2689 0.1533 5 0.1126 0.1079 0.08457 6 0.0719 0.07721 0.08304 7 0.3053 0.3167 0.1547 8 0.1958 0.1964 0.1075 9 2.259 2.829 1.775 10 2.221 2.925 1.811 11 1.725 2.329 1.438 TOTAL 7.628 9.285 5.81 For all but lines 3 and 6, scipy_core is apparently doing better on my system. These are lines calling x % y and scipy_core implements the remainder the same way that Python does (thus needing extra checking) which I expect accounts for its tiny slowness -Travis

3 2

Re: [SciPy-dev] [SciPy-user] gcc error
by Travis Oliphant Dec. 10, 2005

Dec. 10, 2005

Steve Schmerler wrote: >Thanx for the *fast* _dotblas.c update :). But compiling scipy I get > >######################################################################################################################################### > >python scipy/setup.py install > >[...] > > > Thanks for the note. I changed something to get rid of a compiler warning but changed it badly. I apologize for the mistake. The recent tree instability was brought about by my moving the function pointers out of the type descr structure so that the PyArray_Descr structure just has a pointer to a function-pointer table. Type descriptors are dynamic and can get copied around and this will save a little-bit of unnecessary jostling. This has C-API issues for those who used direct access to the function pointers in the descr table. Now, you reach them through the member named 'f'. Thus what was descr->cast is now descr->f->cast. -Travis

1 0

unable to build scipy svn version 1481
by Darren Dale Dec. 10, 2005

Dec. 10, 2005

I just updated from svn, and am unable to build quadpack. i686-pc-linux-gnu-gcc: Lib/integrate/_quadpackmodule.c In file included from Lib/integrate/_quadpackmodule.c:6: Lib/integrate/__quadpack.h: In function `quadpack_qagse': Lib/integrate/__quadpack.h:141: error: too many arguments to function `dqagse_' Lib/integrate/__quadpack.h: In function `quadpack_qagie': Lib/integrate/__quadpack.h:219: error: too many arguments to function `dqagie_' Lib/integrate/__quadpack.h: In function `quadpack_qagpe': Lib/integrate/__quadpack.h:314: error: too many arguments to function `dqagpe_' Lib/integrate/__quadpack.h: In function `quadpack_qawoe': Lib/integrate/__quadpack.h:420: error: too many arguments to function `dqawoe_' Lib/integrate/__quadpack.h: In function `quadpack_qawfe': Lib/integrate/__quadpack.h:521: error: too many arguments to function `dqawfe_' Lib/integrate/__quadpack.h: In function `quadpack_qawce': Lib/integrate/__quadpack.h:610: error: too many arguments to function `dqawce_' Lib/integrate/__quadpack.h: In function `quadpack_qawse': Lib/integrate/__quadpack.h:690: error: too many arguments to function `dqawse_' In file included from Lib/integrate/_quadpackmodule.c:6: Lib/integrate/__quadpack.h: In function `quadpack_qagse': Lib/integrate/__quadpack.h:141: error: too many arguments to function `dqagse_' Lib/integrate/__quadpack.h: In function `quadpack_qagie': Lib/integrate/__quadpack.h:219: error: too many arguments to function `dqagie_' Lib/integrate/__quadpack.h: In function `quadpack_qagpe': Lib/integrate/__quadpack.h:314: error: too many arguments to function `dqagpe_' Lib/integrate/__quadpack.h: In function `quadpack_qawoe': Lib/integrate/__quadpack.h:420: error: too many arguments to function `dqawoe_' Lib/integrate/__quadpack.h: In function `quadpack_qawfe': Lib/integrate/__quadpack.h:521: error: too many arguments to function `dqawfe_' Lib/integrate/__quadpack.h: In function `quadpack_qawce': Lib/integrate/__quadpack.h:610: error: too many arguments to function `dqawce_' Lib/integrate/__quadpack.h: In function `quadpack_qawse': Lib/integrate/__quadpack.h:690: error: too many arguments to function `dqawse_' error: Command "i686-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/lib/python2.4/site-packages/scipy/base/include -I/usr/include/python2.4 -c Lib/integrate/_quadpackmodule.c -o build/temp.linux-i686-2.4/Lib/integrate/_quadpackmodule.o" failed with exit status 1 -- Darren S. Dale, Ph.D. dd55(a)cornell.edu

1 0

Segmentation fault
by Nils Wagner Dec. 10, 2005

Dec. 10, 2005

scipy.test(1,10) results in a segfault. Here comes the backtrace check_basic (scipy.io.array_import.test_array_import.test_numpyio) ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076175008 (LWP 15562)] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x421e4861 in numpyio_tofile (self=0x0, args=0x45ac5b6c) at numpyiomodule.c:324 #2 0x0811eb56 in PyCFunction_Call (func=0x402b91ac, arg=0x45ac5b6c, kw=0x0) at methodobject.c:93 #3 0x080c74ed in PyEval_EvalFrame (f=0x81f0cec) at ceval.c:1499 #4 0x080c8551 in PyEval_EvalFrame (f=0x82ca60c) at ceval.c:3640 #5 0x080c8bb4 in PyEval_EvalCodeEx (co=0x402c7b60, globals=0x402b8b54, locals=0x0, args=0x45903858, argcount=2, kws=0x85dbf18, kwcount=0, defs=0x402ce9f8, defcount=1, closure=0x0) at ceval.c:2736 #6 0x0811de51 in function_call (func=0x402d1224, arg=0x4590384c, kw=0x45ad4d74) at funcobject.c:548 #7 0x0805935e in PyObject_Call (func=0x402d1224, arg=0x4590384c, kw=0x45ad4d74) at abstract.c:1756 #8 0x080c4a4d in PyEval_EvalFrame (f=0x8290b04) at ceval.c:3835 #9 0x080c8bb4 in PyEval_EvalCodeEx (co=0x402c7ba0, globals=0x402b8b54, locals=0x0, args=0x459037d8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #10 0x0811dda2 in function_call (func=0x402d125c, arg=0x459037cc, kw=0x0) at funcobject.c:548 #11 0x0805935e in PyObject_Call (func=0x402d125c, arg=0x459037cc, kw=0x0) at abstract.c:1756 #12 0x08064bd4 in instancemethod_call (func=0x3, arg=0x459037cc, kw=0x0) at classobject.c:2447 #13 0x0805935e in PyObject_Call (func=0x45aefd4c, arg=0x45b0774c, kw=0x0) at abstract.c:1756 #14 0x08097c47 in slot_tp_call (self=0x45add74c, args=0x45b0774c, kwds=0x0) at typeobject.c:4536 #15 0x0805935e in PyObject_Call (func=0x45add74c, arg=0x45b0774c, kw=0x0) at abstract.c:1756 #16 0x080c4c5e in PyEval_EvalFrame (f=0x81e6dfc) at ceval.c:3766 #17 0x080c8bb4 in PyEval_EvalCodeEx (co=0x402cc160, globals=0x402b8b54, locals=0x0, args=0x459038f8, argcount=2, kws=0x8616a30, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #18 0x0811de51 in function_call (func=0x402d1614, arg=0x459038ec, kw=0x45ad4cec) at funcobject.c:548 #19 0x0805935e in PyObject_Call (func=0x402d1614, arg=0x459038ec, kw=0x45ad4cec) at abstract.c:1756 #20 0x080c4a4d in PyEval_EvalFrame (f=0x84436bc) at ceval.c:3835 #21 0x080c8bb4 in PyEval_EvalCodeEx (co=0x402cc1a0, globals=0x402b8b54, locals=0x0, args=0x45903838, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #22 0x0811dda2 in function_call (func=0x402d164c, arg=0x4590382c, kw=0x0) at funcobject.c:548 #23 0x0805935e in PyObject_Call (func=0x402d164c, arg=0x4590382c, kw=0x0) at abstract.c:1756 #24 0x08064bd4 in instancemethod_call (func=0x3, arg=0x4590382c, kw=0x0) at classobject.c:2447 #25 0x0805935e in PyObject_Call (func=0x458fda7c, arg=0x45af554c, kw=0x0) at abstract.c:1756 #26 0x08097c47 in slot_tp_call (self=0x459092cc, args=0x45af554c, kwds=0x0) at typeobject.c:4536 #27 0x0805935e in PyObject_Call (func=0x459092cc, arg=0x45af554c, kw=0x0) at abstract.c:1756 #28 0x080c4c5e in PyEval_EvalFrame (f=0x822257c) at ceval.c:3766 #29 0x080c8551 in PyEval_EvalFrame (f=0x820d4ec) at ceval.c:3640 #30 0x080c8bb4 in PyEval_EvalCodeEx (co=0x402b47e0, globals=0x402b835c, locals=0x0, args=0x82b20b8, ---Type <return> to continue, or q <return> to quit--- argcount=3, kws=0x82b20c4, kwcount=0, defs=0x402d4038, defcount=2, closure=0x0) at ceval.c:2736 #31 0x080c5f67 in PyEval_EvalFrame (f=0x82b1f6c) at ceval.c:3650 #32 0x080c8bb4 in PyEval_EvalCodeEx (co=0x4566cb20, globals=0x4026c824, locals=0x4026c824, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #33 0x080c8de5 in PyEval_EvalCode (co=0x4566cb20, globals=0x4026c824, locals=0x4026c824) at ceval.c:484 #34 0x080f7c26 in PyRun_InteractiveOneFlags (fp=0x4024d720, filename=0x8124263 "<stdin>", flags=0xbfffed04) at pythonrun.c:1265 #35 0x080f7e89 in PyRun_InteractiveLoopFlags (fp=0x4024d720, filename=0x8124263 "<stdin>", flags=0xbfffed04) at pythonrun.c:695 #36 0x080f7fb0 in PyRun_AnyFileExFlags (fp=0x4024d720, filename=0x8124263 "<stdin>", closeit=0, flags=0xbfffed04) at pythonrun.c:658 #37 0x08055917 in Py_Main (argc=0, argv=0xbfffedd4) at main.c:484 #38 0x08054fc8 in main (argc=1, argv=0xbfffedd4) at python.c:23 Nils

1 0

_dotblas.c:71: error: structure has no member named `dotfunc'
by Nils Wagner Dec. 10, 2005

Dec. 10, 2005

I am using the latest svn versions of core and scipy python setup.py install yields gcc: scipy/corelib/blasdot/_dotblas.c scipy/corelib/blasdot/_dotblas.c: In function `dotblas_alterdot': scipy/corelib/blasdot/_dotblas.c:71: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:72: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:75: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:76: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:79: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:80: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:83: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:84: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In function `dotblas_restoredot': scipy/corelib/blasdot/_dotblas.c:104: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:108: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:112: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:116: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In function `dotblas_alterdot': scipy/corelib/blasdot/_dotblas.c:71: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:72: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:75: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:76: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:79: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:80: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:83: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:84: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c: In function `dotblas_restoredot': scipy/corelib/blasdot/_dotblas.c:104: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:108: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:112: error: structure has no member named `dotfunc' scipy/corelib/blasdot/_dotblas.c:116: error: structure has no member named `dotfunc' error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DATLAS_INFO="\"3.7.11\"" -Iscipy/corelib/blasdot -I/usr/local/include/atlas -Iscipy/base/include -Ibuild/src/scipy/base -Iscipy/base/src -I/usr/local/include/python2.4 -c scipy/corelib/blasdot/_dotblas.c -o build/temp.linux-i686-2.4/scipy/corelib/blasdot/_dotblas.o" failed with exit status 1 removed scipy/base/__svn_version__.py removed scipy/base/__svn_version__.pyc removed scipy/f2py/__svn_version__.py removed scipy/f2py/__svn_version__.pyc

1 0

Re: [SciPy-dev] [SciPy-user] FFT troubles
by Travis Oliphant Dec. 9, 2005

Dec. 9, 2005

Rob Managan wrote: > I get > > running build_clib > customize UnixCCompiler > ... > customize GnuFCompiler using build_ext > building 'scipy.fftpack._fftpack' extension > compiling C sources > gcc options: '-fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -Wall > -Wstrict-prototypes' > compile options: '-Ibuild/src > -I/Users/managan/Documents/local/lib/python2.4/site-packages/scipy/base/include > -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c' > /usr/local/bin/g77 -undefined dynamic_lookup -bundle > build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/Lib/fftpack/_fftpackmodule.o > build/temp.darwin-7.9.0-Power_Macintosh-2.4/Lib/fftpack/src/zfft.o > build/temp.darwin-7.9.0-Power_Macintosh-2.4/Lib/fftpack/src/drfft.o > build/temp.darwin-7.9.0-Power_Macintosh-2.4/Lib/fftpack/src/zrfft.o > build/temp.darwin-7.9.0-Power_Macintosh-2.4/Lib/fftpack/src/zfftnd.o > build/temp.darwin-7.9.0-Power_Macintosh-2.4/build/src/fortranobject.o > -L/usr/local/lib/gcc/powerpc-apple-darwin7.9.0/3.4.4 > -Lbuild/temp.darwin-7.9.0-Power_Macintosh-2.4 -ldfftpack -lg2c > -lcc_dynamic -o > build/lib.darwin-7.9.0-Power_Macintosh-2.4/scipy/fftpack/_fftpack.so > running install_lib > > I don't see the -lrfftw -lfftw options on the compile line so I > wonder if I am actually linking against fftw?? Well that's interesting... That could signal a problem with the fftpack supplied with full scipy... You can check to see if your system is picking up fftw using: python -c "import scipy.distutils.system_info as sds; print sds.get_info('fftw')" The output of that will show you more. -Travis

1 0

Re: [SciPy-dev] [SciPy-user] Benchmark data
by Travis Oliphant Dec. 9, 2005

Dec. 9, 2005

Robert Kern wrote: >When we start to seriously look at this, we should consider using liboil >to implement these optimizations. > > Hey, great find, that looks just like the kind of thing we'll want at some point. One way this could be done is just like the dotblas extension module so that if liboil is found on your system, an extension module is loaded that replaces the respective inner-loops of the affected functions. Alternatively, at compile time, the right functions could be inserted in the ufunc function table to begin with... -Travis

2 2

fft segfault, 64 Bit Opteron
by Arnd Baecker Dec. 9, 2005

Dec. 9, 2005

Hi Travis, some more info on the segfault for fft when running scipy.test(10,10). Looks similar to the other one, but is a different place: Multi-dimensional Fast Fourier Transform =================================================== | real input | complex input --------------------------------------------------- size | scipy | Numeric | scipy | Numeric --------------------------------------------------- 100x100 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912507335168 (LWP 2965)] DOUBLE_subtract (args=0x1620400, dimensions=0x7fffffed722c, steps=0x16bd550, func=0x2aaab7bce000) at umathmodule.c:1959 1959 *((double *)op)=*((double *)i1) - *((double *)i2); (gdb) bt #0 DOUBLE_subtract (args=0x1620400, dimensions=0x7fffffed722c, steps=0x16bd550, func=0x2aaab7bce000) at umathmodule.c:1959 #1 0x00002aaaabd421fd in PyUFunc_GenericFunction (self=0x719520, args=0x2aaab600c830, mps=0x2) at ufuncobject.c:1569 #2 0x00002aaaabd44c69 in ufunc_generic_call (self=0x719520, args=0x2aaab600c830) at ufuncobject.c:2553 #3 0x0000000000417808 in PyObject_CallFunction (callable=0x719520, format=0x67fffffd796 <Address 0x67fffffd796 out of bounds>) at abstract.c:1756 #4 0x00002aaaabba68f7 in array_subtract (m1=0x67fffffd796, m2=0x7fffffed722c) at arrayobject.c:2261 #5 0x00000000004145a7 in binary_op1 (v=0x159a530, w=0x162f490, op_slot=8) at abstract.c:371 #6 0x000000000041500e in PyNumber_Subtract (v=0x159a530, w=0x162f490) at abstract.c:422 #7 0x0000000000474c9e in PyEval_EvalFrame (f=0xf741c0) at ceval.c:1144 #8 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaabd233b0, globals=0x7fffffed722c, locals=0x16bd550, args=0xf741c0, argcount=2, kws=0xf736b8, kwcount=0, defs=0x2aaaae93ce28, defcount=1, closure=0x0) at ceval.c:2736 #9 0x00000000004788f7 in PyEval_EvalFrame (f=0xf734b0) at ceval.c:3650 #10 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaab944e30, globals=0x7fffffed722c, locals=0x16bd550, args=0xf734b0, argcount=2, kws=0x834010, kwcount=0, defs=0x2aaaab967a88, defcount=2, closure=0x0) at ceval.c:2736 #11 0x00000000004788f7 in PyEval_EvalFrame (f=0x833e20) at ceval.c:3650 #12 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaab68f6c00, globals=0x7fffffed722c, locals=0x16bd550, args=0x833e20, argcount=1, kws=0x6f1490, kwcount=0, defs=0x2aaab68f5b28, defcount=1, closure=0x0) at ceval.c:2736 #13 0x00000000004788f7 in PyEval_EvalFrame (f=0x6f12e0) at ceval.c:3650 #14 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaab95c810, globals=0x7fffffed722c, locals=0x16bd550, args=0x6f12e0, argcount=2, kws=0xb32110, kwcount=0, defs=0x2aaaab9643a8, defcount=1, closure=0x0) at ceval.c:2736 #15 0x00000000004c6099 in function_call (func=0x2aaaab969758, arg=0x2aaab5425128, kw=0xfab4e0) at funcobject.c:548 #16 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #17 0x00000000004772ea in PyEval_EvalFrame (f=0x894f90) at ceval.c:3835 #18 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaab95c880, globals=0x7fffffed722c, locals=0x16bd550, args=0x894f90, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #19 0x00000000004c6099 in function_call (func=0x2aaaab9697d0, arg=0x2aaab54215a8, kw=0x0) at funcobject.c:548 #20 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #21 0x0000000000420ee0 in instancemethod_call (func=0x1620400, arg=0x2aaab54215a8, kw=0x0) at classobject.c:2447 #22 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #23 0x00000000004777d9 in PyEval_EvalFrame (f=0x833780) at ceval.c:3766 #24 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaaab42340, globals=0x7fffffed722c, locals=0x16bd550, args=0x833780, argcount=2, kws=0x0, kwcount=0, defs=0x2aaaab964168, defcount=1, closure=0x0) at ceval.c:2736 #25 0x00000000004c6099 in function_call (func=0x2aaaab96b668, arg=0x2aaab5421488, kw=0x0) at funcobject.c:548 #26 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #27 0x0000000000420ee0 in instancemethod_call (func=0x1620400, arg=0x2aaab5421488, kw=0x0) at classobject.c:2447 #28 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #29 0x000000000044fd80 in slot_tp_call (self=0x2aaab68f5d10, args=0x2aaab693ef90, kwds=0x0) at typeobject.c:4536 #30 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #31 0x00000000004777d9 in PyEval_EvalFrame (f=0x6d3dc0) at ceval.c:3766 #32 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaab95e2d0, globals=0x7fffffed722c, locals=0x16bd550, args=0x6d3dc0, argcount=2, kws=0xf51060, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #33 0x00000000004c6099 in function_call (func=0x2aaaab96a050, arg=0x2aaab5421680, kw=0xf4d590) at funcobject.c:548 #34 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 #35 0x00000000004772ea in PyEval_EvalFrame (f=0xc00a80) at ceval.c:3835 #36 0x000000000047ad2f in PyEval_EvalCodeEx (co=0x2aaaab95e340, globals=0x7fffffed722c, locals=0x16bd550, args=0xc00a80, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2736 #37 0x00000000004c6099 in function_call (func=0x2aaaab96a0c8, arg=0x2aaab5421518, kw=0x0) at funcobject.c:548 #38 0x0000000000417700 in PyObject_Call (func=0x1620400, arg=0x7fffffed722c, kw=0x16bd550) at abstract.c:1756 HTH, Arnd

3 8

Re: [SciPy-dev] [SciPy-user] Benchmark data
by Travis Oliphant Dec. 9, 2005

Dec. 9, 2005

Gerard Vermeulen wrote: >On Fri, 09 Dec 2005 03:14:49 -0700 >Travis Oliphant <oliphant.travis(a)ieee.org> wrote: > > >>I'd like people to try out scipy core in SVN. I made improvements to the >>buffered ufunc section of code that I think will make a big difference >>in the recently published benchmarks. >> >> >> > >Hi Travis, > >indeed, it made a big difference (for big arrays scipy is now fastest on some >statements). > >Below are my benchmark results on my DIY python, see >http://www.scipy.org/mailinglists/mailman?fn=scipy-user/2005-December/00605… > >On my system and for large arrays (>4096), numarray is still fastest, scipy moved >to second and Numeric is third. >Numeric is still fastest for small arrays, scipy is second, numarray is third. > > Numeric will always be faster for small-enough arrays, I think, because it doesn't have the ufunc overhead. I just don't want it to be a lot faster. We can improve the limiting scalar case in scipy_core using separate scalar math. It looks like we are doing reasonably well. >Invoking: python bench.py 12 >Importing test to scipy >Importing base to scipy >Importing basic to scipy >Python 2.4.2 (#1, Dec 4 2005, 08:21:04) >[GCC 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)] >Optimization flags: -DNDEBUG -O3 -march=i686 >CPU info: getNCPUs=2 has_mmx has_sse has_sse2 is_32bit is_Intel is_Pentium is_PentiumIV >Numeric-24.2 >numarray-1.5.0 >scipy-core-0.8.1.1617 >benchmark size = 12 (vectors of length 16777216) >label Numeric numarray scipy.base > 1 0.4127 0.07423 0.3927 > 2 0.2734 0.2321 0.3234 > 3 0.1975 0.1821 0.2733 > 4 0.8747 0.5371 0.5588 > 5 0.2896 0.2342 0.2737 > 6 0.2066 0.1731 0.2718 > 7 0.8761 0.6286 0.5524 > 8 0.6546 0.4556 0.4533 > 9 9.488 7.566 8.717 > 10 9.506 8.064 8.745 > 11 7.879 6.301 7.305 >TOTAL 30.66 24.45 27.87 > > As mentioned before, it looks like the optimizer is doing something nice on your system. One issue is arange which could definitely be made faster by having different "fillers" for different types. I'm still astonished by the markedly different numbers you seem to get than others have shown. Is this all -O3 optimization kicking in? The other issue is the sin and cosine functions. They don't have their own inner loops. They call a generic inner loop with a "function-pointer" data. Perhaps the optimizer can't do as much with that or it needs to written with an optimizer in mind. Ultimately, though, I'd like to see some of the inner loops to take advantage of SSE (and equivalent) instructions if the number of iterations is large-enough. So, yes, I think we could get faster. But, I'd first like to get more data from more machines and compiler flags to determine where the slowness is really coming from. It might be good, for example, to break up one of lines 9, 10, and 11 so that at least one sin and cos calculation is done alone. Thanks, -Travis

1 0