RFC: INLINE defcfun and auto FTYPE declarations [with patch]
Luís Oliveira
luismbo at gmail.com
Wed Nov 8 00:12:49 UTC 2017
On Mon, Nov 6, 2017 at 5:10 PM, Andrzej Walczak
<andrzejwalczak at google.com> wrote:
> After some thoughts, I agree, that the inlining control is not a fully-baked
> idea, yet.
Incidentally, this recent pro at c-l.net message makes me a whole lot
less skeptical about your suggested approach:
<https://mailman.common-lisp.net/pipermail/pro/2017-November/001464.html>.
The introspect-environment library seems to provide a nice portable
API for inspecting optimization policies. Alas, there doesn't seem to
be away to define your own declarations; I was hoping we might be able
to something like (declaim (inline-cffi-functions <boolean>)) or
something along those lines.
> I'll split the patch into INLINE and FTYPE parts.
Sounds like a good idea.
> You may ask why we have decided to inline (almost) every of the DEFCFUNs?
> CFFI interfaces to C - obviously - and a lot of code in C deals with
> double-floats and 64-bit integers.
> Without the stubs being inline, every call to C and back produces boxed
> values, impacting the performance.
Right. Float boxing; that's a classic. But, I (perhaps naively) didn't
expect boxing to happen even without the declarations. Take the
following example:
(in-package :cffi)
(declaim (optimize (speed 3) (space 0) (safety 0) (debug 0)))
(declaim (inline fabs-1))
(defun fabs-1 (x)
(foreign-funcall "fabs" :double x :double))
(declaim (inline fabs-2))
(defun fabs-2 (x)
(declare (double-float x))
(foreign-funcall "fabs" :double x :double))
(defun foo-1 (x)
(floatp (fabs-1 x)))
(defun foo-2 (x)
(floatp (fabs-2 x)))
I expected FABS-1 and FABS-2 to be identical. (FOREIGN-FUNCALL
eventually expands to ALIEN-FUNCALL and I was expecting that would
provide all the type information SBCL's compiler might need.) The
disassembly shows that FAB-2 is one instruction shorter. But
disassembling FOO-1 and FOO-2 shows that they're identical.
Perhaps this example is too contrived. Do you have a better one?
Cheers,
--
Luís Oliveira
http://kerno.org/~luis/
More information about the cffi-devel
mailing list