-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[performance] GraalPython is slow when running Cython #411
Comments
Profiling didn't reveal too much. It's spending a large chunk of time in There's somewhere where we use child_attrs = property(fget=operator.attrgetter('subexprs'))
#instead of
# @property
# def child_attrs(self):
# return self.subexprs changing that made things a bit faster, but not dramatically so. And that's as far as I got |
GraalVM seems to have an option |
Yes I gave those a quick go - they were what pointed out I've attached some example output though |
I've improved things on our CI by turning off the JIT with the options But we're clearly doing something what doesn't agree with how GraalPython optimizes things. |
If turning off the JIT helps, then it sounds like a deoptimization loop bug (in graalpy). You're most likely doing nothing wrong (unless you're constantly generating new code and evaling it). I'll try to investigate. |
Thanks. I don't think it's Quick warning - if you do |
It should actually use the Python-any wheel that we distribute on PyPI, i.e. not try to build anything locally. |
I've been working on getting GraalPython tested on the Cython CI. It mostly works but it's really slow.
One aspect of this is the time spent running Cython itself. Note that this is pure Python code (so it doesn't involve any interaction with your C API emulation, which I know isn't considered a fast path) - while Cython has the option of compiling itself for speed I haven't done so here for the sake of the report.
For the sake of a demo I've just done checked out the cython repository from github and done
that just runs cython on a bunch of its own files (but only to the c code generation stage, it doesn't invoke any C compilers).
Some results:
The upshot is that GraalPython is about 8 times slower than CPython, (and also uses 3 cores of my CPU most of that time while CPython is largely single-threaded).
I've included PyPy just as another data-point. It's also slower for this case (although not quite as slow as GraalPython) so we're clearly doing something that isn't JIT friendly....
I haven't done any profiling beyond this basic measurement (yet).
I do realise this is essentially an enormous code-dump with the complaint "it's slow", which is never a style of bug report that I'm very impressed with when I'm on the receiving end.
The text was updated successfully, but these errors were encountered: