Performance

[simonbyrne]

What can we do to make this fast? At the moment, calling j.sin is 10x slower than math.sin or numpy.sin.

I'm guessing that this is due to type inference issues with the PyCall.jl callback. Is there a way we could provide annotations or hints for individual functions?

[stevengj]

It's going to be hard to eliminate the overhead of the type introspection and conversions for such a small function as sin.

I'm not sure I understand the purpose here? You shouldn't call lots of small Julia functions from Python if you care about performance. You should call a few expensive functions.

[simonbyrne]

My (possibly quixotic) purpose was thinking about how we can make Julia an easy-to-use replacement for C for writing Python backend code. Where is the overhead, and what could we do to make it slimmer?

[stevengj]

@simonbyrne, but users normally only write Python backend code in C or Cython or whatever for big, expensive functions. That's why everything in NumPy is vectorized, after all. And for big, expensive function, the function-call overhead shouldn't matter.

Part of the overhead comes in converting the argument to a Julia type. Since PyCall does not know what kind of Python object you are passing, it has to convert(PyAny, args)... on the tuple of arguments. This, in turn, needs to check what Julia type it should try to convert to. The way this is done is a naive list of if statements right now … it could be improved a lot if we used e.g. some kind of hash table to memoize the results based on the PyObject_Type.

Of course, something like sin could be made faster (but much less flexible) if we only check for one or two possible types. And you could avoid the dynamic dispatch on the Julia side too.

[simonbyrne]

@jekbradbury Are you able to provide a small reproducible example (say in a gist) of the issue you mentioned here? My guess is that the bottleneck might be converting between Python and Julia dictionaries, but it would be useful to have some hard data.

[StefanKarpinski]

If someone is willing to spell out the C API that's to be wrapped from Python, there's simply no technical reason why calling Julia can't be every bit as efficient as calling C is. If they don't want to bother with that, sure, we can allow it to work with more overhead, but I don't think we should be settle for being second best at this.

[ihnorton]

This need to define/specify C-ish interfaces in various forms keeps coming up.

If someone is willing to spell out the C API that's to be wrapped from Python

What is missing is the automatic generation of the correct .h file with the function prototypes. While this can be done manually, that is a tedious and error prone task.

The downside is that Julia packages would have to define a Python interface.

I get that it's inconvenient in the "exploratory" context (perhaps the caching idea can make up some difference there). But for library use-cases I think people would warm to the idea instantly if it could be done once for Julia/Python/C/whatever "backends", and especially if it was exploited by the compiler to facilitate LLVM-free binaries and shared libraries.

[stevengj]

There are two separate issues here:

• Make the "generic" pyjulia calling faster. (Maybe by adding more caching to PyCall, and making pyjulia module loading lazier.)

• Provide a lower-level pyjulia interface that allows you to specify argument types etcetera. This could be implemented by adding a function PyCall.pyfunction(f, argtypes...) to PyCall that takes a Julia object f and returns a callable Python object wrapping f which expects the specified argument types. You would then call this function from pyjulia and cache the result (in your Python code) to construct an "optimized" Python/Julia wrapper. Additional glue could be added on the Python side to make this syntactically easier if needed.

• LLVM-free libraries are a totally different ball of wax. You can do that now using [static compilation](https://github.com/JuliaComputing/static-julia and then call the result via a Python C FFI without using pyjulia at all, but my impression is that the set of Julia code that can be statically compiled is quite restricted at the moment.

[stevengj]

PyCall now provides the pyfunction API that I mentioned above to allow more control (and more performance) in the argument conversions.

You should be able to access this on the Python side, simply by calling PyCall.pyfunction (or PyCall.pyfunctionret) from Python, to create optimized wrapper functions for Julia functions where the argument (and return types) can be specified manually.