On Thu, Jul 12, 2018 at 4:54 AM Jeroen Demeyer wrote:
>
> On 2018-07-11 10:50, Victor Stinner wrote:
> > As you wrote, the
> > cost of function costs is unlikely the bottleneck of application.
>
> With that idea, METH_FASTCALL is not needed either. I still find it very
> strange that nobody seems
On 2018-07-11 10:50, Victor Stinner wrote:
As you wrote, the
cost of function costs is unlikely the bottleneck of application.
With that idea, METH_FASTCALL is not needed either. I still find it very
strange that nobody seems to question all the crazy existing
optimizations for function calls
On 2018-07-11 10:27, Antoine Pitrou wrote:
I agree PEP 580 is extremely complicated and it's not obvious what the
maintenance burden will be in the long term.
But the status quo is also very complicated! If somebody would write a
PEP describing the existing implementation of builtin_function_o
On 2018-07-11 00:48, Victor Stinner wrote:
About your benchmark results:
"FASTCALL unbound method(obj, 1, two=2): Mean +- std dev: 42.6 ns +- 29.6 ns"
That's a very big standard deviation :-(
Yes, I know. My CPU was overheating and was slowed down. But that seemed
to have happened for a smal
On 11 July 2018 at 18:50, Victor Stinner wrote:
> I'm skeptical about "50% gain": I want to see a working implementation
> and reproduce benchmarks myself to believe that :-) As you wrote, the
> cost of function costs is unlikely the bottleneck of application.
>
> Sorry, I didn't read all these PE
2018-07-11 2:12 GMT+02:00 INADA Naoki :
> If my idea has 50% gain and current PEP 580 has only 5% gain,
> why we should accept PEP 580?
> But no one know real gain, because there are no realistic application
> which bottleneck is calling overhead.
I'm skeptical about "50% gain": I want to see a wo
On Wed, 11 Jul 2018 09:12:11 +0900
INADA Naoki wrote:
>
> Without example application, I can't consider PEP 580 seriously.
> Microbenchemarks doesn't attract me.
> And PEP 576 seems much simpler and straightforward way to expose
> FASTCALL.
I agree PEP 580 is extremely complicated and it's not o
First of all, please don't be so defensive.
I just say I need example target application. I don't against to PEP 580.
Actually speaking, I lean to PEP 580 than PEP 576, although I wonder if
some part of PEP 580 can be simplified or postponed.
But PEP 580 is very complicated. I need enough evid
INADA Naoki schrieb am 11.07.2018 um 02:01:
> On Wed, Jul 11, 2018 at 7:47 AM Victor Stinner wrote:
>> I proposed something simpler, but nobody tried to implement it.
>> Instead of calling the long and complex PyArg_Parse...() functions,
>> why not generating C code to parse arguments instead? The
INADA Naoki schrieb am 11.07.2018 um 02:12:
> On Tue, Jul 10, 2018 at 10:20 PM Antoine Pitrou wrote:
>> On Tue, 10 Jul 2018 21:59:28 +0900
>> INADA Naoki wrote:
>>>
>>> Then, the function is called from another C extension like this:
>>>
>>> PyObject_CallFunction(func, "n", 42);
>>>
>>> Currently,
On Tue, Jul 10, 2018 at 10:20 PM Antoine Pitrou wrote:
>
> On Tue, 10 Jul 2018 21:59:28 +0900
> INADA Naoki wrote:
> >
> > Then, the function is called from another C extension like this:
> >
> > PyObject_CallFunction(func, "n", 42);
> >
> > Currently, we create temporary long object for passing
On Wed, Jul 11, 2018 at 7:47 AM Victor Stinner wrote:
>
> 2018-07-10 14:59 GMT+02:00 INADA Naoki :
> > PyObject_CallFunction(func, "n", 42);
> >
> > Currently, we create temporary long object for passing argument.
> > If there is protocol for exposeing format used by PyArg_Parse*, we can
> > bypas
About your benchmark results:
"FASTCALL unbound method(obj, 1, two=2): Mean +- std dev: 42.6 ns +- 29.6 ns"
That's a very big standard deviation :-( Are you using CPU pinning and
other technics explaining in my doc?
http://perf.readthedocs.io/en/latest/run_benchmark.html#how-to-get-reproductible-
2018-07-10 14:59 GMT+02:00 INADA Naoki :
> PyObject_CallFunction(func, "n", 42);
>
> Currently, we create temporary long object for passing argument.
> If there is protocol for exposeing format used by PyArg_Parse*, we can
> bypass temporal Python object and call myfunc_impl directly.
I'm not sure
On 2018-07-10 14:59, INADA Naoki wrote:
Currently, we create temporary long object for passing argument.
If there is protocol for exposeing format used by PyArg_Parse*, we can
bypass temporal Python object and call myfunc_impl directly.
Indeed, I already mentioned this at
https://www.python.org
On Tue, 10 Jul 2018 21:59:28 +0900
INADA Naoki wrote:
>
> Then, the function is called from another C extension like this:
>
> PyObject_CallFunction(func, "n", 42);
>
> Currently, we create temporary long object for passing argument.
> If there is protocol for exposeing format used by PyArg_Par
On Tue, Jul 10, 2018 at 8:55 PM Jeroen Demeyer wrote:
>
> OK, I tried with --duplicate 200 and you can see the results at
> https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
>
> In short, the timings with and without PEP 580 are roughly the same
> (which is to be expected). Interes
OK, I tried with --duplicate 200 and you can see the results at
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
In short, the timings with and without PEP 580 are roughly the same
(which is to be expected). Interestingly, a small but significant
improvement can be seen when ca
18 matches
Mail list logo
