PyOpenGL Hacking at HackLab
Written by
on
in
Snaking.
Soni and I got an invitation to the opening party for HackLab in Toronto,but I was out of town at a client site that night. However, the club has an open house on Tuesday nights, so I decided to drop in this evening to check them out. Spent much of the time talking with Sam, who is writing his own language, discussing the various strengths and problems of Python, Lisp, Prolog, C, C++ etceteras. Sam invited me back on Thursday for the Python night.
Spent the evening working on PyOpenGL/OpenGLContext. I wrote a tiny C extension that gets the data-pointer from a numpy array, which seemed to speed frame-rates by about 2x, sigh. The creation of a separate "ctypes" object to get the (integer) pointer for the array is all that optimized. If the numpy array just had a ".data" attribute that was the pointer-as-integer I could use that, but for some reason it seems to use a property instead. If I could find a way to optimize away the ctypes null pointer object creation as well I could probably get another significant boost (these functions are called hundreds of thousands of times/minute).
Also found a few hot-spots in, for example, the routing code, where it looks like there may be some algorithmic failures... the routing code is just so fast I hadn't noticed them particularly. The other huge slowdown is in the tree-traversal code. I'm seeing millions of isinstance calls from that, which can likely be optimized substantially.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Ryan May on 11/12/2008 9:36 a.m. #
This can also get the address as an integer, I'm not sure if it's also implemented as a property (though it is 3 lookups):
array.__array_interface__['data][0]
My testing in IPython with timeit says that the above statement is almost 3x faster than:
array.ctypes.data
Mike Fletcher on 11/13/2008 10:20 a.m. #
I *think* the difference is that it's just creating a simple dictionary instead of an object with an initializer. The C accelerator module I wrote just pulls out the bald integer, so I've made that the default when it's available, but I'll switch to the __array_interface__ implementation being the preferred Python-level default implementation. Thanks for the information!