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

[Mike C. F. <mcf...@vr...>]

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, because of 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).

Have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com