The PyPy version is faster, as the article and commenters point out, because the PyPy JIT can inline a call across a module boundary. GCC can do something like this with -fwhole-program, but that doesn't work on shared libraries.
Has any work gone into inlining (probably only very simple) functions when linking against a shared library? Something like the "add" function clearly has no side effects if you were to look at the asm in the shared library, but it might be hard for the compiler to figure that out in any more complicated cases... perhaps by adding an annotation to the shared object file? It seems doable, at least.
But by definition shared libraries are shared code you are going to load at run time. What if between the time your app was compiled and the time your app was run the add function in the shared library changed? You would have the wrong version of the function inlined.
Comments
The PyPy version is faster, as the article and commenters point out, because the PyPy JIT can inline a call across a module boundary. GCC can do something like this with -fwhole-program, but that doesn't work on shared libraries.
Has any work gone into inlining (probably only very simple) functions when linking against a shared library? Something like the "add" function clearly has no side effects if you were to look at the asm in the shared library, but it might be hard for the compiler to figure that out in any more complicated cases... perhaps by adding an annotation to the shared object file? It seems doable, at least.
But by definition shared libraries are shared code you are going to load at run time. What if between the time your app was compiled and the time your app was run the add function in the shared library changed? You would have the wrong version of the function inlined.
Ah, true... what I said makes no sense. Thanks.
Of course that doesn't speak to the fact that a smarter dynamic loading capability couldn't inline at runtime. That is what they are doing after all.