affects on extended modules
Curtis Jensen
cjensen at bioeng.ucsd.edu
Thu Dec 27 20:02:17 EST 2001
Kragen Sitaker <kragen at pobox.com> wrote in message news:<83pu5zrvbl.fsf at panacea.canonical.org>...
> 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.
I have been unable to find any references to dynamically loaded
objects being slower than statically linked objects. I understand
that there is an initial cost when the library is loaded that wouldn't
be there in the static case, though, I don't know why it would be
slower after that. Can you please provide some references for this,
or explain why this would be? Thanks.
--
Curtis Jensen
More information about the Python-list
mailing list