Hi guys,
thanks for your replies. 250ns sounded like a lot, and apparently it was. I
can't reproduce it anymore.
Thanks for the confirmation that API and ABI modes should have the same
performance. I looked at the jitlog, and both api, abi and cast pointer
seem to produce exactly the same code (a
Hi Carl Friedrich,
On Wed, 26 Sep 2018 at 22:28, Carl Friedrich Bolz-Tereick wrote:
> Couldn't that slowness of getattr be fixed by making the lib objects eg use
> module dicts or something?
If we use the out-of-line API mode then ``lib`` is an RPython object,
but if we use the in-line ABI mode
Hi Armin,
Couldn't that slowness of getattr be fixed by making the lib objects eg use
module dicts or something?
Cheers,
Carl Friedrich
On September 26, 2018 9:47:10 PM GMT+02:00, Armin Rigo
wrote:
>Hi Dimitri,
>
>On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev
> wrote:
>> In my mi
Hi again,
On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev
wrote:
> In my microbenchmarks its has pretty much the same call performance as when
> using cffi ABI mode (dumping the functions to a shared library first) and is
> around 250ns per call slower than when using API mode.
>
> I
Hi Dimitri,
On Wed, 26 Sep 2018 at 21:19, Dimitri Vorona via pypy-dev
wrote:
> In my microbenchmarks its has pretty much the same call performance as when
> using cffi ABI mode (dumping the functions to a shared library first) and is
> around 250ns per call slower than when using API mode.
I d
Hi all,
I am JIT-generating functions in my code and call them by first
ffi.cast'ing them to a function pointer.
In my microbenchmarks its has pretty much the same call performance as when
using cffi ABI mode (dumping the functions to a shared library first) and
is around 250ns per call slower th
