|
|
|
|
| C vs Perl | Perl vs Python | POGL vs SDL | Windows vs Linux |
POGL Benchmarks - Perl vs Python
These benchmarks were adopted from Geoff Broadwell's SDL Trislam benchmarks, and rewritten
in Python by Bob Free.
These benchmarks were performed on an Debian Ubuntu/Dapper system:
3Ghz Intel Pentium D
1G Memory
nVidia GeForce 6800 GT/AGP/SSE2
nVidia v97.55 driver
These benchmarks require an OpenGL installation and GLUT.
The Perl benchmarks also require Perl,
POGL 0.55_1 or newer,
and the Time::HiRes module;
the Python benchmarks require Python and the PyOpenGL module.
Note: These benchmarks were run using the latest stable binary packages for Debian (PyOpenGL 2.0.1.09) -
it has been suggested that PyOpenGL 3.0.0a6 is much faster.
Our recent tests indicate that v3 is between 3% to 4X slower than v2 - see below.
Rendering simple GL_TRIANGLES or GL_QUADS, POGL averaged 26% faster than PyOpenGL
Using tristrips, POGL averaged 21% faster than PyOpenGL
Using quadstrips, POGL averaged 40% faster than PyOpenGL
POGL measured over 270X faster than PyOpenGL when using Vertex Arrays
POGL w/ OGA measured 175X faster than PyOpenGL w/ ctypes
Display lists provided comparable performance between POGL and PyOpenGL
We were not able to identify VBO support in PyOpenGL for comparison
PyOpenGL v3 provides no improved performance over v2, at this time
This is a snippet of a note posted by Mike Fletcher on PyOpenGL's SourceForge mailing list:
Trislam: Perl OpenGL (POGL)
|
|
Trislam: Python OpenGL (PyOpenGL)
|
Trislam: POGL w/ OpenGL::Array (OGA)
|
|
Trislam: PyOpenGL w/ ctypes
|
Trislam: PyOpenGL v2
|
|
Trislam: PyOpenGL v3
|
Python tends to focus more on code aesthetics than performance; as a result,
Python OpenGL developers continue to struggle with overcoming Python's array handling
performance issues.
PyOpenGL v1 used native array handling, which is known to have significant performance issues;
PyOpenGL v2 switched to SWIG, a C wrapper interface, which brought some improvements -
however, the interface between Python's arrays and SWIG continued to be a bottleneck.
At the suggestion of some Python developers, we introducing the use of ctypes
(a Python Foreign Function Interface module) into the Python version of our Trislam
benchmark, and found a considerable performance improvement (145% in some cases).
That said, POGL using the analogous OpenGL::Array (OGA) was still 175X faster.
PyOpenGL v3 (still in alpha) has introduced the use of NumPy (Numerical Python) arrays,
which holds the promise of further performance improvements. However, as of ths writing,
the current tested release (3.0.0a6) is considerably slower than v2. As noted above,
PyOpenGL's author indicates that he added error-logging to v3 after each call.
The author further notes that PyOpenGL/NumPy does data copy/conversion in order to provide
data type flexibility, which could explain the disparity between Vertex Array benchmarks.
In other words, PyOpenGL incurs a cost by attempting to provide cleaner Python code through
data type abstraction.
Note: If you must use Python for OpenGL, the POGL team strongly recommends the use of ctypes.
Pre-built packages are available for ctypes 0.9 - however, in order to use PyOpenGL v3,
you will need at least 1.0.1, which must be built from source on many platforms.
ctypes is included in the latest Python builds, if you build Python from source.
In addition to these performance issues, Perl provides a number of other advantages over Python:
Perl is much simpler to port to/from C/C++/Java
Perl has a much larger repository of open source libraries
Perl has much stronger/faster string handling (dynamic shader programs)
Perl simplifies embedding values within text blocks
Python has no define'd global constants
Python has no forward referencing/prototypes
Python has no simple method of retrieving a dictionary/hash element's key
Python's print has no global method for enabling unbuffered I/O
Python's formatted print requires lists to be first converted to tuples
Python's print has no means to suppress both trailing newlines and spaces
Python has no ifdef method (short of reformatting) to block out prototype code
Please report errors in this code or in Python feature statements above to the
POGL team.
Much thanks to Geoffrey Broadwell for assistance with his Trislam benchmark.
Thanks to Taro Ogawa (float division) and Aleksandar Samardzic (ctypes)
for an excellent review, comments and suggestions for improvements on this
Python benchmark code.
This benchmark source is available on this site
|
|
|
|
|
|
