affects on extended modules

[Curtis Jensen]

Kragen Sitaker wrote:
> 
> 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.

Thanks for the responce.  The C counterpart is directly linked together
into one large binary (yes, the python is using a dynamicaly linked
object file, a .so).  So, That might be the source of the problem.  I
can try and make a dynamicaly linked version of the C counterpart and
see how that affects the speed.  We are running on IRIX 6.5 machines
(mips).
Thanks.

-- 
Curtis Jensen
cjensen at bioeng.ucsd.edu
http://www-bioeng.ucsd.edu/~cjensen/
FAX (425) 740-1451