affects on extended modules

[Kragen Sitaker]

Curtis Jensen <cjensen at bioeng.ucsd.edu> writes:
> We have created a python interface to some core libraries of our own
> making.  We also have a C interface to these same libraries.  However,
> the the python interface seems to affect the speed of the extended
> libraries.  ie.  some library routines have their own benchmark code,
> and the time of exection from the start of the library routine to the
> end of the library routine (not including any python code execution),
> takes longer than it's C counterpart.

In the Python version, the code is in a Python extension module,
right?  A .so or .dll file?  Is it also in the C counterpart?  (If
that's not it, can you provide more details on how you compiled and
linked the two?)

In general, referring to dynamically loaded things through symbols ---
even from within the same file --- tends to be slower than referring
to things that aren't dynamically loaded.

What architecture are you on?  If you're on the x86, maybe Numeric is
being stupid and allocating things that aren't maximally aligned.  But
you'd probably notice a pretty drastic difference in that case.

... or maybe Numeric is being stupid and allocating things in a way
that causes cache-line contention.

Hope this helps.