[Python-Dev] New calling convention to avoid temporarily tuples when calling functions

[Brett Cannon]

I just wanted to say I'm excited about this and I'm glad someone is taking
advantage of what Argument Clinic allows for and what I know Larry had
initially hoped AC would make happen!

I should also point out that Serhiy has a patch for faster keyword argument
parsing thanks to AC: http://bugs.python.org/issue27574 . Not sure how your
two patches would intertwine (if at all).

On Mon, 8 Aug 2016 at 15:26 Victor Stinner <victor.stinner at gmail.com> wrote:

> Hi,
>
> tl;dr I found a way to make CPython 3.6 faster and I validated that
> there is no performance regression. I'm requesting approval of core
> developers to start pushing changes.
>
> In 2014 during a lunch at Pycon, Larry Hasting told me that he would
> like to get rid of temporary tuples to call functions in Python. In
> Python, positional arguments are passed as a tuple to C functions:
> "PyObject *args". Larry wrote Argument Clinic which gives more control
> on how C functions are called. But I guess that Larry didn't have time
> to finish his implementation, since he didn't publish a patch.
>
> While trying to optimize CPython 3.6, I wrote a proof-of-concept patch
> and results were promising:
> https://bugs.python.org/issue26814#msg264003
> https://bugs.python.org/issue26814#msg266359
>
> C functions get a C array "PyObject **args, int nargs". Getting the
> nth argument become "arg = args[n];" at the C level. This format is
> not new, it's already used internally in Python/ceval.c. A Python
> function call made from a Python function already avoids a temporary
> tuple in most cases: we pass the stack of the first function as the
> list of arguments to the second function. My patch generalizes the
> idea to C functions. It works in all directions (C=>Python, Python=>C,
> C=>C, etc.).
>
> Many function calls become faster than Python 3.5 with my full patch,
> but even faster than Python 2.7! For multiple reasons (not interesting
> here), tested functions are slower in Python 3.4 than Python 2.7.
> Python 3.5 is better than Python 3.4, but still slower than Python 2.7
> in a few cases. Using my "FASTCALL" patch, all tested function calls
> become faster or as fast as Python 2.7!
>
> But when I ran the CPython benchmark suite, I found some major
> performance regressions. In fact, it took me 3 months to understand
> that I didn't run benchmarks correctly and that most benchmarks of the
> CPython benchmark suite are very unstable. I wrote articles explaining
> how benchmarks should be run (to be stable) and I patched all
> benchmarks to use my new perf module which runs benchmarks in multiple
> processes and computes the average (to make benchmarks more stable).
>
> At the end, my minimum FASTCALL patch (issue #27128) doesn't show any
> major performance regression if you run "correctly" benchmarks :-)
> https://bugs.python.org/issue27128#msg272197
>
> Most benchmarks are not significant, 14 are faster, and only 4 are slower.
>
> According to benchmarks on the "full" FASTCALL patch, the slowdown are
> temporary and should become quickly speedup (with further changes).
>
> My question is now: can I push fastcall-2.patch of the issue #27128?
> This patch only adds the infrastructure to start working on more
> useful optimizations, more patches will come, I expect more exciting
> benchmark results.
>
> Overview of the initial FASTCALL patch, see my first message on the issue:
> https://bugs.python.org/issue27128#msg266422
>
> --
>
> Note: My full FASTCALL patch changes the C API: this is out of the
> scope of my first simple FASTCALL patch. I will open a new discussion
> to decide if it's worth it and if yes, how it should be done.
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160808/8d5c2a5c/attachment.html>