Fixing Python Performance with Rust

Since you can basically write C in Cython, it depends how far you take the cython optimization. You can just add a few types, or you can go nuts via scipy's BLAS interface https://github.com/RaRe-Technologies/gensim/blob/develop/gen...

In general, you can get to less overhead with Cython right now because it's a much more mature project and because you can be more flexible with defining the point where you drop from python to a faster alternative. I wouldn't use that Nim/Python lib in production unless you have time to help with its development. It's good for personal projects though.

My personal experience with cython (and why I'm less than lukewarm about it) is that it's about as much fun as C to write and only really helps wih he annoyance of dealing with PyObject. That's something that was not even required for the sourcemap lib.

Debugging and writing cython that is fast is feally not a very pleasant experience and the tooling is not great. Let alone that a real ecosystem exists. There is not even a good way to deal with dependencies at compile time.

I'm really not anfan of linking libpython if I can avoid it. More wheels to build and then its limited to cpython. Cffi is plenty fast.

Can you import that as a lib in Python to work in reverse? It seems to be a different use-case otherwise - using a Python library from Rust vs optimizing a hotspot within Python.

I only used nim for some side projects but the only times I saw this used anywhere is in FFI bindings.

That way you can mirror, say, C style while writing the bindings either manually or automatically and use them as if they were normal nim elsewhere.

Or how about Rust-FFI, C-FFI, C-API directly, Nim-to-C-API (pymod), Julia python module, ctypes, cython, libboost, and swig for a good measure.

There are examples of each of these compared to one or the other but it would be nice to see all of them compared in a few benchmarks.

FWIW, most languages that can generate native code can generate shared libraries, and will usually have instructions for how to call the libraries from other languages.

Here's how to do it Haskell, for example: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_gui...

That said, if optimization gets to the point where re-writing in a different language is a good idea, most people just jump to C or C++, or in this case Rust, because they're the fastest.

I think scaling is more about serving demand - whether you you use more resources on a single box, more resources by using more boxes or use the same resources more efficiently you're still scaling.

It's vertical almost by definition. I'll say it.

If you halve the memory and CPU usage of a given service (that's not IO bound), have you not improved it's vertical scalability?

Not sure what you mean about cython and the FFI. As far as I know, cython is tightly coupled to the CPython C API.

I agree that cython is a good option if you only care about CPython.

this is pretty important here, given that we already have a sourcemap library we built in Rust (for our sentry-cli tool)

That's very disingenuous as Armin Ronacher/mitsuhiko has done so much for Python.

If I understand the question correctly, you are saying:

1. There's a bunch of objects that need to pass down the ffi boundaries py->go 2. compute 3. There's a bunch of objects that need to pass up the ffi boundaries go->py 4. Python now continues as usual with a bunch of processed objects

In that case, yes this would be a problem. The way I'd resolve it is by planning the ffi boundaries accordingly. I'd make python do as less as possible, and pass just declarative "instructions" to go. In this case where's the file location and where's the sourcemap file location (and perhaps where to dump output to if that's the case). And go doing as much work as possible to make sure there's only a minimal number of objects passed back if any.

It may _feel_ like a hack but ultimately its the same approach if you were to make a "sourcemap server" making python code communicate with it over RPC.

If this is not the problem then I'd love an example of what you meant

I'm sceptical. I highly doubt GC matters here at all. The runtime restrictions might be the author's own requirements.

You can write DLL/dylib in D to work with Python: http://pyd.readthedocs.io/en/latest/functions.html

You can opt-out of D's GC. Turn on `-vgc` flag during compilation and replace GC'd code with non-GC'd code and you are not using any GC.

It's for C++ consumers of C libraries. Doesn't matter for Python <-> Rust.

`#[no_mangle]` is currently a bit overloaded; there's discussion of whether this is correct or not:

https://internals.rust-lang.org/t/precise-semantics-of-no-ma...

#[no_mangle] turns off the name mangling so it emits a symbol in the style C would. But AFAIK it doesn't force the function to use C calling conventions. As demonstrated in https://doc.rust-lang.org/book/ffi.html#calling-rust-code-fr... you probably still need the `extern` keyword on your function definition, e.g.

  #[no_mangle]
  pub extern unsafe fn lsm_view_from_json(bytes: *const u8, len: c_uint,
                                          err_out: *mut CError) -> *mut View
  {
    ...
  }

I'm referring to the definitions of the Rust functions.

As far as I know, `#[no_mangle]` disables name-mangling but doesn't change the ABI of a function. That's what `extern "C"` is for in Rust -- to declare a function with the C ABI. You can have a Rust ABI function with an unmangled name (what it looks is done in the post) and you can have a C ABI function in Rust with a mangled name (by using `extern "C"` but not `#[no_mangle]` -- for example for C callbacks).

Based on my limited understanding of C++, `extern "c"` in C++ is equivalent to using both `#[no_mangle]` and `pub extern "C"` in Rust. I would guess that much of the time failing to specify a C ABI would work out fine unless you try to accept or pass non-FFI types (enums, references, etc) but I'm not sure.

It's confusing as hell. There was a thread about the mixed up semantics somewhat recently on the internals forum: https://internals.rust-lang.org/t/no-no-mangle/3973 (edit: and also https://internals.rust-lang.org/t/precise-semantics-of-no-ma...).

If you look at the LLVM IR generated from https://is.gd/Hfup3X you can see that the extern "C" fn differs in that it's given a `nounwind` attribute, among other things.

Other people have said this, but as a concrete example of the difference between #[no_mangle] and extern: Rust does a thing called return value optimization (RVO), C does not. If you have the following library header:

    typedef struct { int x[500]; } bigthing;
    bigthing MyFunction();

and a program using that library:

    int main() {
        bigthing x = MyFunction();
    }

C has no choice but to have MyFunction allocate a couple kilobytes on the stack and have main copy the structure from the stack to where it should eventually go. The equivalent Rust code, however, can pass the address of the object x to MyFunction, as if it were actually void MyFunction(bigstruct &output).

If you have a #[no_mangle] but not extern function in Rust, the Rust compiler will generate code for that function that looks for this secret by-reference argument and fills it in. When you call it from C (or something that calls functions in a C-like manner, like Python's cffi), it won't be setting up the call like that at all, and it will expect to read the result off the stack like a C function would have done.

(I don't think there's a lot of use for #[no_mangle] without extern. The best I can think of is that, if you have a Rust application that dynamically loads a Rust library and runs a function from it, you don't have access to the mangling algorithm, once you find the function you'll call it according to the Rust ABI. But even that is risky since the Rust ABI can change between compiler versions; you're still better off shoveling things through the C ABI.)

Complexity.