Re: [PyOpenGL-Users] Perl vs. Python OpenGL bindings benchmarks

[Aleksandar B. S. <asa...@gm...>]

On 6/4/07, Mike C. Fletcher <mcf...@vr...> wrote:
> Aleksandar B. Samardzic wrote:
> > There was a set of benchmark results posted recently, comparing Perl
> > OpenGL (POGL) bindings performance with performance of some other
> > OpenGL bindings; results of comparison between Perl and Python OpenGL
> > bindings could be found here:
> >   http://graphcomp.com/pogl.cgi?v=0111s3B2&r=s3m3
> > PyOpenGL is claimed to be largely inferior in performance, especially
> > regarding using vertex array functionality.  Python benchmark code is
> > somewhat improved in the meantime, and PyOpenGL version 3, instead of
> > version 2, is used to retest, but claimed low PyOpenGL performance is
> > still there.  I was able to compare PyOpenGL based benchmark results
> > with Perl SDL based OpenGL binding results, and PyOpenGL perforance is
> > superior on my machine (as expected, because after all PyOpenGL in
> > version 3 is really thin layer above OpenGL C code); however I'm
> > unable to compile POGL properly, and run POGL based benchmarks on my
> > machine.  I do expect however, becauseof above mentioned reason, that
> > PyOpenGL performance must be at least in range with POGL performance,
> > thus I'd suggest to anyone interested to try  to run both benchmarks
> > on its machine, and to send results to POGL team; of course, further
> > improvements in Python benchmark code would be welcome too.
> >
> Actually, I would be *very* surprised if PyOpenGL is anywhere near the
> same speed.
>
> PyOpenGL does a lot more than just wrap the C call.  In particular, it
> adds a glGetError call after *every* call to provide Python-like
> exception-on-error semantics instead of requiring explicit error checks
> in the code.  The current 3.0.0a6 version also does a logging-enabling
> call for every function (I'm thinking of making that feature default to
> off, though it would mean less informative error messages).
>
> That said, I couldn't get their benchmark code to run in PyOpenGL
> ("PyBench" doesn't seem to be the pybench module I'm familiar with), and
> didn't have enough time to try fixing it before checking to see if there
> are any gross issues with it.
>
> As for the vertex array functionality; we do a *lot* of Python-side code
> to do a vertex translation.  The PyOpenGL 3.x line has a far more
> flexible engine for the array sources than 2.x did, allowing run-time
> plugging of new array data-types.  The cost of that is some performance
> penalty on passing each array.  Larger arrays push average that expense
> out over the whole array, so a 10,000 point array would have almost no
> appreciable overhead (and would likely be faster than PyOpenGL 2.x),
> while passing in hundreds of 3 or 4 element arrays would show a huge
> overhead compared to PyOpenGL 2.x (which did all the array conversions
> in C, but often wound up silently copying the arrays).

Take a look say into benchmark() function in trislam_pyopengl_ctp.py -
 benchmark consist of same drawing sequence rendered either 100 times
or for 10 seconds, whatever takes less.  For vertex arrays (for
example, draw_quads_va() function), drawing sequence consists
practically of glVertexPointer() and glDrawArrays() calls; further,
array of vertex coordinates that is passed to glVertexPointer() is
prepared beforehand (before benchmark() function loop entered).  Now I
guess you, as PyOpenGL primary developer, may know better, but if
array of vertex coordinates is already ctypes based array (and I sent
some tiny patches, so trislam_pyopengl_ctp.py is benchmark version
that is ctypes based now), then from what I can see in PyOpenGL code,
overhead has to be negligible...

On the other side, I do think that alike benchmark could be very
useful in pointing to performance bottlenecks of a wrapper; thus,
while it is indeed very simple benchmark, I guess PyOpenGL could only
benefit if you find some time, sometimes, to play with trislam.

Regards,
Alex