By Eric Jones eric@enthought.com
locals()
The weave package provides tools for including C/C++ code
within
in Python code. This offers both another level of optimization to those
who need it, and an easy way to modify and extend any supported
extension libraries such as wxPython and hopefully VTK soon. Inlining
C/C++ code within Python generally
results in speed ups of 1.5x to 30x speed-up over algorithms written in
pure
Python (However, it is also possible to slow things down...). Generally
algorithms that require a large number of calls to the Python API don't
benefit
as much from the conversion to C/C++ as algorithms that have inner
loops completely convertable to C.
There are three basic ways to use weave. The weave.inline()
function executes C code directly within Python, and weave.blitz()
translates Python NumPy expressions to C++ for fast execution. blitz()
was the original reason weave was built. For those
interested in building extension
libraries, the ext_tools module provides classes for
building extension modules within Python.
Most of weave's functionality should work on Windows
and Unix, although some of its functionality requires gcc
or a similarly modern C++ compiler that handles templates well. Up to
now, most testing has been done on Windows 2000 with Microsoft's C++
compiler (MSVC) and with gcc (mingw32 2.95.2 and 2.95.3-6). All tests
also pass on Linux (RH 7.1 with gcc 2.96), and I've had reports that it
works on Debian also (thanks Pearu).
The inline and blitz provide new
functionality to Python (although I've recently learned about the PyInline project which may
offer similar functionality to inline). On the other
hand, tools for building Python extension modules already exists (SWIG,
SIP, pycpp, CXX, and others). As of yet, I'm not sure where weave
fits in this spectrum. It is closest in flavor to CXX in that it makes
creating new C/C++ extension modules pretty easy. However, if you're
wrapping a gaggle of legacy functions or classes, SWIG and friends are
definitely the better choice. weave is set up so that you
can customize how Python types are converted to C types in weave.
This is great for inline(), but, for wrapping legacy
code, it is more flexible to specify things the other way around --
that is how C types map to Python types. This weave does
not do. I guess it would be possible to build such a tool on top of weave,
but with good tools like SWIG around, I'm not sure the effort produces
any new capabilities. Things like function overloading are probably
easily implemented in weave and it might be easier to mix
Python/C code in function calls, but nothing beyond this comes to mind.
So, if you're developing new extension modules or optimizing Python
functions in C, weave.ext_tools() might be the tool for
you. If you're wrapping legacy code, stick with SWIG.
The next several sections give the basics of how to use weave.
We'll discuss what's happening under the covers in more detail later
on. Serious users will need to at least look at the type conversion
section to understand how Python variables map to C/C++ types and how
to customize this behavior. One other note. If you don't know C or C++
then these docs are probably of very little help to you. Further, it'd
be helpful if you know something about writing Python extensions. weave
does quite a bit for you, but for anything complex, you'll need to do
some conversions, reference counting, etc.
Note: weave is actually part of the SciPy package. However, it also works
fine as a standalone package (you can check out the sources using svn
co http://svn.scipy.org/svn/scipy/trunk/Lib/weave weave and install as
python setup.py install). The examples here are given as if it is used
as a stand alone package. If you are using from within scipy, you can
use from scipy import weave and the examples will work
identically.
I use 2.1.1. Probably 2.0 or higher should work.
weave uses distutils to actually
build extension modules, so it uses whatever compiler was originally
used to build Python. weave itself requires a C++
compiler. If you used a C++ compiler to build Python, your probably
fine.
On Unix gcc is the preferred choice because I've done a little
testing with it. All testing has been done with gcc, but I expect the
majority of compilers should work for inline and ext_tools.
The one issue I'm not sure about is that I've hard coded things so that
compilations are linked with the stdc++ library. Is
this standard across Unix compilers, or is this a gcc-ism?
For blitz(), you'll need a reasonably recent
version of gcc. 2.95.2 works on windows and 2.96 looks fine on Linux.
Other versions are likely to work. Its likely that KAI's C++ compiler
and maybe some others will work, but I haven't tried. My advice is to
use gcc for now unless your willing to tinker with the code some.
On Windows, either MSVC or gcc ( mingw32) should work.
Again, you'll need gcc for blitz() as the MSVC compiler
doesn't handle templates well.
I have not tried Cygwin, so please report success if it works for you.
The python NumPy module from here.
is required for blitz() to work and for numpy.distutils
which is used by weave.
There are currently two ways to get weave. Fist, weave
is part of SciPy and installed automatically (as a sub-
package) whenever SciPy is installed. Second, since weave
is useful outside of the scientific community, it has been setup so
that it can be
used as a stand-alone module.
The stand-alone version can be downloaded from here. Instructions for installing should be found there as well. setup.py file to simplify installation.
weave is installed, fire up python and run its unit
tests.
This takes a while, usually several minutes. On Unix with remote file systems, I've had it take 15 or so minutes. In the end, it should run about 180 tests and spew some speed results along the way. If you get errors, they'll be reported at the end of the output. Please report erros that you find. Some tests are known to fail at this point.>>> import weave >>> weave.test() runs long time... spews tons of output and a few warnings . . . .............................................................. ................................................................ .................................................. ---------------------------------------------------------------------- Ran 184 tests in 158.418s OK>>>
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again, there will
be a much shorter delay in the fractions of seconds range. This is
because weave stores a catalog of all previously compiled
functions in an on disk cache. When it sees a string that has been
compiled, it loads the already compiled module and executes the
appropriate function.
Note: If you try the printf example in a GUI shell such
as IDLE, PythonWin, PyShell, etc., you're unlikely to see the output.
This is because the C code is writing to stdout, instead of to the GUI
window. This doesn't mean that inline doesn't work in these
environments -- it only means that standard out in C is not the same as
the standard out for Python in these cases. Non input/output functions
will work as expected.
Although effort has been made to reduce the overhead associated with
calling inline, it is still less efficient for simple code snippets
than using equivalent Python code. The simple printf
example is actually slower by 30% or so than using Python print
statement. And, it is not difficult to create code fragments that are
8-10 times slower using inline than equivalent Python. However, for
more complicated algorithms, the speed up can be worth while --
anywhwere from 1.5- 30 times faster. Algorithms that have to manipulate
Python objects (sorting a list) usually only see a factor of 2 or so
improvement. Algorithms that are highly computational or manipulate
NumPy arrays can see much larger improvements. The examples/vq.py file
shows a factor of 30 or more improvement passed 180 tests and spew some speed results
along the way. If you get errors, they'll be reported at the end of the
output. Please report erros that you find. Some tests are
known to fail at this point.
If you only want to test a single module of the package, you can do this by running test() for that specific module.
Testing Notes:>>> import weave.scalar_spec >>> weave.scalar_spec.test() ....... ---------------------------------------------------------------------- Ran 7 tests in 23.284s
I've had some test fail on windows machines where I have msvc, gcc-2.95.2 (in c:\gcc-2.95.2), and gcc-2.95.3-6 (in c:\gcc) all installed. My environment has c:\gcc in the path and does not have c:\gcc-2.95.2 in the path. The test process runs very smoothly until the end where several test using gcc fail with cpp0 not found by g++. If I check os.system('gcc -v') before running tests, I get gcc-2.95.3-6. If I check after running tests (and after failure), I get gcc-2.95.2. ??huh??. The os.environ['PATH'] still has c:\gcc first in it and is not corrupted (msvc/distutils messes with the environment variables, so we have to undo its work in some places). If anyone else sees this, let me know - - it may just be an quirk on my machine (unlikely). Testing with the gcc- 2.95.2 installation always works.
If you run the tests from PythonWin or some other GUI tool,
you'll get a ton of DOS windows popping up periodically as weave
spawns the compiler multiple times. Very annoying. Anyone know how to
fix this?
wxPython tests are not enabled by default because importing wxPython on a Unix machine without access to a X-term will cause the program to exit. Anyone know of a safe way to detect whether wxPython can be imported and whether a display exists on a machine?
weave/example
directory and also from the test scripts. Without more information
about what the test actually do, their value is limited. Still, their
here for the curious. Look at the example scripts for more specifics
about what problem was actually solved by each run. These examples are
run under windows 2000 using Microsoft Visual C++ and python2.1 on a
850 MHz PIII laptop with 320 MB of RAM.
Speed up is the improvement (degredation) factor of weave
compared to conventional Python functions. The blitz()
comparisons are shown
compared to NumPy.
|
inline and ext_tools |
|
|
Algorithm |
Speed up |
| binary search | 1.50 |
| fibonacci (recursive) | 82.10 |
| fibonacci (loop) | 9.17 |
| return None | 0.14 |
| map | 1.20 |
| dictionary sort | 2.54 |
| vector quantization | 37.40 |
|
blitz -- double precision |
|
|
Algorithm |
Speed up |
| a = b + c 512x512 | 3.05 |
| a = b + c + d 512x512 | 4.59 |
| 5 pt avg. filter, 2D Image 512x512 | 9.01 |
| Electromagnetics (FDTD) 100x100x100 | 8.61 |
The benchmarks shown blitz in the best possible light.
NumPy (at least on my machine) is significantly worse for double
precision than it is for single precision calculations. If your
interested in single precision results, you can pretty much divide the
double precision speed up by 3 and you'll
be close.
inline() compiles and executes C/C++ code on the fly.
Variables in the local and global Python scope are also available in
the C/C++ code. Values are passed to the C/C++ code by assignment much
like variables are passed into a standard Python function. Values are
returned from the C/C++ code through a special argument called
return_val. Also, the contents of mutable objects can be changed within
the C/C++ code and the changes remain after the C code exits and
returns to Python. (more on this later)
Here's a trivial printf example using inline():
>>> import weave >>> a = 1 >>> weave.inline('printf("%d\\n",a);',['a']) 1
In this, its most basic form, inline(c_code, var_list)
requires two arguments. c_code is a string of valid C/C++
code. var_list is a list of variable names that are
passed from Python into C/C++. Here we have a simple printf
statement that writes the Python variable a to the
screen. The first time you run this, there will be a pause while the
code is written to a .cpp file, compiled into an extension module,
loaded into Python, cataloged for future use, and executed. On windows
(850 MHz PIII), this takes about 1.5 seconds when using Microsoft's C++
compiler (MSVC) and 6-12 seconds using gcc (mingw32 2.95.2). All
subsequent executions of the code will happen very quickly because the
code only needs to be compiled once. If you kill and restart the
interpreter and then execute the same code fragment again,