clarification cffi vs _ffi_ vs _ffi vs libffi vs _rawffi vs rffi
there seems to be some confusion (could be all mine) between N terms related to FFI: are there both _ffi_ and _ffi, or is one of those a typo? extending page mentions libffi and not cffi, is it out of date, or is there a reason to stay away from cffi, although recommended in general faq page? in my own testing, I noticed that equivalent code cffi code is faster than ctypes, is there an explanation for this? thanks, d. docs in question: http://doc.pypy.org/en/latest/faq.html http://doc.pypy.org/en/latest/extending.html http://doc.pypy.org/en/latest/rffi.html
Hi Dima, On Wed, Nov 27, 2013 at 4:07 PM, Dima Tisnek <dimaqq@gmail.com> wrote:
there seems to be some confusion (could be all mine) between N terms related to FFI:
As a user of PyPy you only need to concern yourself with cffi and ctypes. The rest is all a number of more-or-less related internal sub-parts of PyPy or the RPython translation toolchain that all attempt to do accessing C-level functionality: rffi, _ffi, _rawffi. And libffi is the existing, non-PyPy-related, C library that is (sometimes) used by these other levels.
"rffi" is about writing RPython code, e.g. a special extension module for PyPy; in most cases you don't need that. The page http://doc.pypy.org/en/latest/extending.html is a bit outdated :-( Thanks for pointing it out.
in my own testing, I noticed that equivalent code cffi code is faster than ctypes, is there an explanation for this?
On top of PyPy, yes, definitely. CFFI is simpler than ctypes; it was *designed* to be simple. Although it was not particularly designed for PyPy and works fine on CPython (and was actually first developed for CPython), this has the intended benefit that PyPy's JIT can do a good job on it. A bientôt, Armin.
Re-Hi, On Wed, Nov 27, 2013 at 5:24 PM, Armin Rigo <arigo@tunes.org> wrote:
I updated that page. Armin
Thanks, Armin, doc page looks good now! On a related note, I'm thinking to interface jvm/dalvik, similar to jpype (C module) and following pyjnius (cython module), but in cffi. I'd be very grateful if there was a good pypy/cffi project you could point me to as an example, especially of harder bits like reference management. d. On 27 November 2013 18:08, Armin Rigo <arigo@tunes.org> wrote:
2013/12/2 Ryan Gonzalez <rymg19@gmail.com>
Check the _tkinter and _sqlite3 modules.
But they don't do advanced reference management, even if _tkinter/tclobj.py has some calls to Tcl_IncrRefCount() and Tcl_DecrRefCount(). The lxml module has interesting code to manage cross-references between C and Python. I'm afraid it's a bit difficult to read (it's an almost exact port of the cython version) But I found that ffi.new_handle() and ffi.from_handle() are really handy in this case: https://github.com/amauryfa/lxml/blob/cffi/src/lxml-cffi/proxy.py#L20
-- Amaury Forgeot d'Arc
Hi Dima, On Wed, Nov 27, 2013 at 4:07 PM, Dima Tisnek <dimaqq@gmail.com> wrote:
there seems to be some confusion (could be all mine) between N terms related to FFI:
As a user of PyPy you only need to concern yourself with cffi and ctypes. The rest is all a number of more-or-less related internal sub-parts of PyPy or the RPython translation toolchain that all attempt to do accessing C-level functionality: rffi, _ffi, _rawffi. And libffi is the existing, non-PyPy-related, C library that is (sometimes) used by these other levels.
"rffi" is about writing RPython code, e.g. a special extension module for PyPy; in most cases you don't need that. The page http://doc.pypy.org/en/latest/extending.html is a bit outdated :-( Thanks for pointing it out.
in my own testing, I noticed that equivalent code cffi code is faster than ctypes, is there an explanation for this?
On top of PyPy, yes, definitely. CFFI is simpler than ctypes; it was *designed* to be simple. Although it was not particularly designed for PyPy and works fine on CPython (and was actually first developed for CPython), this has the intended benefit that PyPy's JIT can do a good job on it. A bientôt, Armin.
Re-Hi, On Wed, Nov 27, 2013 at 5:24 PM, Armin Rigo <arigo@tunes.org> wrote:
I updated that page. Armin
Thanks, Armin, doc page looks good now! On a related note, I'm thinking to interface jvm/dalvik, similar to jpype (C module) and following pyjnius (cython module), but in cffi. I'd be very grateful if there was a good pypy/cffi project you could point me to as an example, especially of harder bits like reference management. d. On 27 November 2013 18:08, Armin Rigo <arigo@tunes.org> wrote:
2013/12/2 Ryan Gonzalez <rymg19@gmail.com>
Check the _tkinter and _sqlite3 modules.
But they don't do advanced reference management, even if _tkinter/tclobj.py has some calls to Tcl_IncrRefCount() and Tcl_DecrRefCount(). The lxml module has interesting code to manage cross-references between C and Python. I'm afraid it's a bit difficult to read (it's an almost exact port of the cython version) But I found that ffi.new_handle() and ffi.from_handle() are really handy in this case: https://github.com/amauryfa/lxml/blob/cffi/src/lxml-cffi/proxy.py#L20
-- Amaury Forgeot d'Arc
participants (4)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Dima Tisnek -
Ryan Gonzalez