On Mon, Nov 6, 2017 at 5:10 PM, Andrzej Walczak andrzejwalczak@google.com wrote:
After some thoughts, I agree, that the inlining control is not a fully-baked idea, yet.
Incidentally, this recent pro@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,