Using C in SymPy to improve speed?

[Tilo RC]

Hi all,

Just out of curiosity I was wondering if core functionality of SymPy could be implemented in C/C++ or some other fast language. I would imagine this would greatly improve speed.

Is there some benefit to using Python for everything?

Sincerely,

Tilo

[Jason Moore]

Dear Tilo,

This has been attempted several times throughout the history of SymPy, some with more success than others:

https://github.com/pearu/sympycore

https://github.com/certik/sympyx

https://github.com/symengine/symengine

https://github.com/oscarbenjamin/rust_protosym

Jason

moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a8389e50-818c-4011-8018-597f6b3db6b0n%40googlegroups.com.

[Oscar Benjamin]

If you pip install python-flint then it will be used to make some
things in SymPy faster. Compare e.g. this with python-flint installed
vs not installed:

In [2]: %time p = Poly(x + 1)**1000
CPU times: user 202 ms, sys: 88 μs, total: 202 ms
Wall time: 200 ms

In [3]: %time r = p.factor_list()
CPU times: user 42.6 s, sys: 3.9 ms, total: 42.6 s
Wall time: 42.6 s

With python-flint:

In [3]: %time p = Poly(x + 1)**1000
CPU times: user 1.99 ms, sys: 172 μs, total: 2.17 ms
Wall time: 2.19 ms # 100x faster

In [4]: %time r = p.factor_list()
CPU times: user 35.1 ms, sys: 0 ns, total: 35.1 ms
Wall time: 35.1 ms # 1000x faster

This is the result of using python-flint which wraps the FLINT library:

https://python-flint.readthedocs.io/en/latest/
https://flintlib.org/

This is still a work in progress. I expect that the next SymPy release
will use python-FLINT for multivariate polynomials which will make a
more noticeable difference and will mean that it is used for
polynomial domain elements and therefore many matrix operations as
well.

The initial PR for multivariate polynomials does not have any actual
content in it yet:

https://github.com/sympy/sympy/pull/26793

A lot of upstream progress has happened though:

https://github.com/flintlib/python-flint/pull/132
https://github.com/flintlib/python-flint/pull/164
https://github.com/flintlib/python-flint/pull/190
https://github.com/flintlib/python-flint/pull/191
https://github.com/flintlib/python-flint/pull/192
https://github.com/flintlib/python-flint/pull/216
https://github.com/flintlib/python-flint/pull/225

There are many more features in FLINT and python-flint that are not
yet used in SymPy as well that can speed up all sorts of things like
Arb to speed up evalf and so on.

--
Oscar

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AjzMvJrj40cwOOLeF%2BQSo0gM87dBWjhzxRhki29JL_Jhg%40mail.gmail.com.

[Sangyub Lee]

>  Is there some benefit to using Python for everything?

Although we use Flint, for instance, they are still left with optional dependency.
And there are some reasons behind duplicating some algorithms.

C binary distributions are dependent on platforms,
for example, X86 and ARM and also dependent on operating systems,
but SymPy works at least everywhere where Python interpreter can run,
and the distribution of SymPy is much more easier than others.

There are benefits of using pure python script, specific for Python users.
For example, it is easy to extend SymPy by subclassing, or at least we let users to do by figure out something from the implementation.
However, binding with C++ object is not very smooth

>>> from symengine import Basic
>>> class Foo(Basic):
...     pass
...
>>> Foo(123)
Segmentation fault (core dumped)

[Aaron Meurer]

With modern build distributions like wheels and conda,
having a compiled dependency isn't really a big deal. Quite a few
packages are compiled and it isn't a problem. Yes it implies different
maintenance tasks and requires people who understand how those things
work, but it can be worth it for the performance gains. The benefit is
you'd be able to get rid of the pure Python code that does the same
thing only slower.

The only reason we can't make flint a hard dependency of SymPy is the
license. If it were relicensed to BSD or MIT I would say we should
just do it.


Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a04525d6-6900-469f-8dcf-7f9726fc9c83n%40googlegroups.com.

[Francesco Bonazzi]

In my opinion, we should follow Wolfram Mathematica's design. Define an efficient pattern matching core and write the algorithms as transformation rules.

We should take up and continue MatchPy and add support for C++ (or Rust) pattern matching compilation through code generation.

Remember that Rust is now a valid and more user-friendly alternative to C++ when speed and memory efficiency is the issue.