Adding cython target

[ncave]

@dbrattli Just out of curiosity, how much of an effort would you say it will be to target cpython cython?

[alfonsogarciacaro]

@dbrattli Can correct me if I'm wrong, but my understanding is cpython is already targeted as it's the most common implementation. There was a discussion somewhere about using PyPy which is supposed to have better performance than cpython.

[ncave]

My bad, I meant cython, I've updated the title.
I guess what I meant was squeezing the full performance from cython, using cdef, types, etc.

[dbrattli]

@ncave I haven't looked at cython yet, but I'll check it out. Travelling this weekend, so may take a few days before I know more. Would the idea be to compile modules like e.g List.fs, Array.fs, Map.fs etc from the fable library to cpython extensions modules using cython? If that is possible then I would imagine it could speed up fable-library considerably. E.g have a fable flag to target cython --cython and then get c-like performance from e.g List.fs.

[dbrattli]

A few links for more information:

• https://github.com/cython/cython
• https://cython.readthedocs.io/en/latest/
• https://github.com/cython/cython/wiki
• https://www.infoworld.com/article/3250299/what-is-cython-python-at-the-speed-of-c.html
• https://learning.oreilly.com/library/view/cython/9781491901731/
• http://docs.cython.org/en/latest/src/tutorial/pure.html

From the info-world article:

Cython limitations

Keep in mind that Cython isn’t a magic wand. It doesn’t automatically turn every instance of poky Python code into sizzling-fast C code. To make the most of Cython, you must use it wisely—and understand its limitations

Little speedup for conventional Python code

When Cython encounteres Python code it can’t translate completely into C, it transforms that code into a series of C calls to Python’s internals. This amounts to taking Python’s interpreter out of the execution loop, which gives code a modest 15 to 20 percent speedup by default. Note that this is a best-case scenario; in some situations, you might see no performance improvement, or even a performance degradation.

[dbrattli]

@ncave Using an augmenting .pxd looks very interesting: http://docs.cython.org/en/latest/src/tutorial/pure.html#augmenting-pxd

[dbrattli]

@ncave My investigations so far shows that this should be more or less trivial. Cython supports and PEP-484 type annotations i.e same style of type annotations we are using right now, so we don't need a separate Cython AST or printer. We can also start with small changes and improve as we go along:

Cython’s approach is incremental. That means a developer can begin with an existing Python application, and speed it up by making spot changes to the code, rather than rewriting the whole application from the ground up.

We would need to add a cython mode to fable, and there will be a few places where we need to match between the different modes i.e run makeNumberTypeAnnotation or makeCythonNumberTypeAnnotation. As @alfonsogarciacaro would say, this will make testing a lot harder, but if parts of fable-library is cython compiled (Array.fs, List.fs, string.py, ...) then we would have enough testing during the normal test run IMO.

One part we need to figure out is if we should require the use cython by default for e.g fable-library since this will require that a c-compiler is available when using fable. This might be another argument for making pre-built versions of fable-library available on PyPI (think NuGet) so that users of fable do not need to compile fable-library themselves.

[dbrattli]

But getting the code optimized is not trivial. Tried with Array.fs. The yellow lines are code that has not been optimized and will run at normal python speed:

[ncave]

@dbrattli

figure out is if we should require the use cython by default for e.g fable-library

Perhaps a separate language target (lang=Cython and FABLE_COMPILER_CYTHON), similar to how TypeScript uses the same fable-library source, but generates fable-library-ts. Not sure how feasible it will be to branch using compiler directives, if it get too hairy, perhaps a fable-library split would be better (and can be distributed separately and/or bundled with the Fable tool).

The yellow lines are code that has not been optimized

Is that with .pxd or without?

[dbrattli]

@ncave Yes, that's a good idea with a separate language. The fable-library will also be different since it would need to be .pyx files using c-function calls when possible (cimport). Perhaps even take a direct dependency on numpy since Cython and numpy plays very well together. Then we would need to use a [<Cython>] attribute to mark functions as being cdef native to distinqush them from functions that are callable from Python. The use-case would be to create simpler module that are callable from Python. Eventually when things gets more mature and we have more experience we could translate parts of fable-library-py using Cython for improved speed. But I don't think we should start there. The above example used a .pyx file. The problem is that any reference to fable-library brings us back into Python again, so we need a fable-library-pyx.

[dbrattli]

@ncave But if Cython is a bit of an effort (not trivial) both to create, maintain and use, then it reminds me that quite a few Python extensions these days are written in Rust e.g Pydantic V2 with Pydantic-core that looks to be using PyO3. So before we start adding Cython, we should consider if using Rust is perhaps a better and more modern alternative? It would be interesting to see how difficult it would be to use PyO3 from Fable Rust to create Python extensions!? Perhaps we could generate fable-library-py using Fable Rust 😀

Python and Rust occupy seemingly opposite ends of the language spectrum ... In theory, these languages shouldn't compete; they should cooperate. And in practice, they can. Rust can benefit from Python's ease of use, and Python can benefit from Rust's speed and safety.

Links:

• https://github.com/PyO3/pyo3
• https://www.infoworld.com/article/3664124/how-to-use-rust-with-python-and-python-with-rust.html
• https://towardsdatascience.com/nine-rules-for-writing-python-extensions-in-rust-d35ea3a4ec29

[ncave]

@dbrattli I just thought it would be interesting to have another target for generating better performing native binaries, that's all.
The memory management and impl choices will be different between C and Rust generated code, so it's hard to say without testing which one will perform better.

[dbrattli]

I'm not sure if the difference really matters since both Cython and Rust would easily outperform Python 😁 They both need to generate Python-extensions, so if the starting point is F# then the developer experience should more or less be the same. I tried looking at Fable-Rust but could not figure out how to add #[pyfunction] attributes. So started playing with Cython again. I think both could be interesting to experiment with. Initial scaffolding at #3238 (wip)

[dbrattli]

For Cython I need to decide if a function, parameter or return type should be a C-type or a Python-type. The idea is to have Python types as default and use e.g [<Cython>] to flag that the entity should be a C-type / function.

[<Cython>]
let add([<Cython>]a, b) : [<return: Cython>] uint16 =
    a + b

Is there a way in Fable to get the return type attribute? @alfonsogarciacaro @ncave

[alfonsogarciacaro]

@dbrattli I've never used return attributes, but I guess you may access it from ReturnParamater.Attributes in MemberFunctionOrValue.

[dbrattli]

Thanks, that worked. I've never used return attributes myself. Actually, surprised it was even possible.

[ncave]

@dbrattli

The idea is to have Python types as default and use e.g [] to flag that the entity should be a C-type / function.

I guess you're doing this for interoperability with other Python code, but is it possible to also have another mode where cdef and C-types are the defaults (for self-contained projects/binaries)? Admittedly I've spent very little time looking at cython, so I'm sure there are reasons you need parameter-level attribute overrides.

[dbrattli]

Yes, @ncave there are two kinds of function definitions in Cython:

1. Python functions are defined using the def statement, as in Python. They take Python objects as parameters and return Python objects. But parameters can still be declared as C-parameters and Cython will automatically convert them for you.

2. C functions are defined using the cdef statement in Cython syntax or with the @cfunc decorator. They take either Python objects or C values as parameters, and can return either Python objects or C values.

def spam(int i, char *s):
    ...

cdef int eggs(unsigned long l, float f):
    ...

From F# that would be:

let spam(i: int, [<Cython>] s: string) =
    ...

[<Cython>]
let eggs([<Cython>] l: uint32, [<Cython>]f: float32) : int = 
    ...

But I guess I could think of this the other way around, i.e use a [<Python>] attribute in case you want to use Python compatible objects. If not specified, you will get C-type objects.

[<Python>]
let spam([<Python>] i; int, s: string) =
    ...

let eggs(l: uint32, f: float32) : int = 
    ...

That looks better, and I guess we can fall-back to Python object if there's no C-type conversion available. What do you think?

[ncave]

@dbrattli Yes, perhaps using a [<Python>] attribute when needed, and fall-back to Python object if there's no C-type conversion available may give you better defaults for lang=Cython, as presumably there would be less need to add attributes to F# funcs / parameters.

[dbrattli]

@ncave Another option is to use similar interop e.g for calling F# from JS, Python, ... and say that only delegate types will be compiled as Python. So if you want to call your Cython function from Python you need to wrap it in a Func. Then translate the parameters where there's a mapping to C-types (or included from a .pyx file) and the rest will become Python objects. Perhaps we would not need any attributes?