<div dir="ltr">Hello Luis,<div> <br></div><div>Indeed, I am guilty as well of writing a compiler-macro based Lisp-form compiler - as hinted in the <a href="mailto:pro@c-l.net" target="_blank">pro@c-l.net</a> post :)<br></div><div>It was one of the motivations to add FTYPEs everywhere. Thank you for the interesting pointer.</div><div><br></div><div>As stated in the quoted comment, double-float boxing is one of the reasons why we inline CFFI stubs.</div><div>It's not like SBCL could chose a different call convention depending on known type declarations.</div><div>Once inlined, there will be no difference for FABS-1 and FABS-2 - with or without type of ftype declarations.</div><div>Thank you for the excellent example illustrating this classic issue.</div><div><br></div><div>The FTYPEs help SBCL produce better code if the double-float function stubs are not inlined (for some reason).</div><div>Also, going back to the post you have mentioned, having FTYPEs on CFFI could help compiler-macros</div><div>take informed decisions about code transformations. </div><div><br></div><div>E.g. (quickly typed - might not compile)</div><div><br></div><div>(declaim (ftype (function (double-float double-float) (values double-float &optional)) pow) (inline pow))</div><div>(defcfun pow :double (base :double) (exp :double))</div><div><br></div><div>(defun test (&rest nums)</div><div> (sum (bind #'pow 2) nums))</div><div><br></div><div>Could expand to:</div><div><br></div><div><div>(defun test (&rest nums)</div><div> (flet ((#:f1 (#:e1)</div><div> (declare (double-float #:e1))</div><div> (pow 2 #:e1)))</div><div> (declare (ftype (function (double-float) (values double-float &optional)) #:f1)</div><div> (dynamic-extent #'#:f1))</div><div> (let ((#:a1 (first nums)))</div><div> (declare (double-float #:a1))</div><div> (dolist (#:n1 (rest nums) #:a1)</div><div> (setf #:a1 (+ #:a1 (funcall #'#:f1 #:n1)))))))</div></div><div><br></div><div>Which should allow the compiler to choose an unboxed representation for passing arguments to the internal #'#:f1.</div><div>BTW: I am sure SBCL would do just fine with just 1/3rd of the declarations above - but unsure which 1/3rd ... this time of year. </div><div> </div><div>Cheers,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 7:12 PM, Luís Oliveira <span dir="ltr"><<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 6, 2017 at 5:10 PM, Andrzej Walczak<br>
<<a href="mailto:andrzejwalczak@google.com">andrzejwalczak@google.com</a>> wrote:<br>
> After some thoughts, I agree, that the inlining control is not a fully-baked<br>
> idea, yet.<br>
<br>
</span>Incidentally, this recent <a href="mailto:pro@c-l.net">pro@c-l.net</a> message makes me a whole lot<br>
less skeptical about your suggested approach:<br>
<<a href="https://mailman.common-lisp.net/pipermail/pro/2017-November/001464.html" rel="noreferrer" target="_blank">https://mailman.common-lisp.<wbr>net/pipermail/pro/2017-<wbr>November/001464.html</a>>.<br>
The introspect-environment library seems to provide a nice portable<br>
API for inspecting optimization policies. Alas, there doesn't seem to<br>
be away to define your own declarations; I was hoping we might be able<br>
to something like (declaim (inline-cffi-functions <boolean>)) or<br>
something along those lines.<br>
<span class=""><br>
<br>
> I'll split the patch into INLINE and FTYPE parts.<br>
<br>
</span>Sounds like a good idea.<br>
<span class=""><br>
<br>
> You may ask why we have decided to inline (almost) every of the DEFCFUNs?<br>
> CFFI interfaces to C - obviously - and a lot of code in C deals with<br>
> double-floats and 64-bit integers.<br>
> Without the stubs being inline, every call to C and back produces boxed<br>
> values, impacting the performance.<br>
<br>
</span>Right. Float boxing; that's a classic. But, I (perhaps naively) didn't<br>
expect boxing to happen even without the declarations. Take the<br>
following example:<br>
<br>
(in-package :cffi)<br>
<br>
(declaim (optimize (speed 3) (space 0) (safety 0) (debug 0)))<br>
<br>
(declaim (inline fabs-1))<br>
(defun fabs-1 (x)<br>
(foreign-funcall "fabs" :double x :double))<br>
<br>
(declaim (inline fabs-2))<br>
(defun fabs-2 (x)<br>
(declare (double-float x))<br>
(foreign-funcall "fabs" :double x :double))<br>
<br>
(defun foo-1 (x)<br>
(floatp (fabs-1 x)))<br>
<br>
(defun foo-2 (x)<br>
(floatp (fabs-2 x)))<br>
<br>
I expected FABS-1 and FABS-2 to be identical. (FOREIGN-FUNCALL<br>
eventually expands to ALIEN-FUNCALL and I was expecting that would<br>
provide all the type information SBCL's compiler might need.) The<br>
disassembly shows that FAB-2 is one instruction shorter. But<br>
disassembling FOO-1 and FOO-2 shows that they're identical.<br>
<br>
Perhaps this example is too contrived. Do you have a better one?<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
--<br>
Luís Oliveira<br>
<a href="http://kerno.org/~luis/" rel="noreferrer" target="_blank">http://kerno.org/~luis/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="font-family:arial;font-size:small"><span style="color:rgb(0,0,0);font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">Andrzej Walczak </span></div><div style="font-family:arial;font-size:small"><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">(</span><span style="color:rgb(0,0,0);font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap"><font color="#0000ff">G</font></span><font color="#ff0000" style="font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">o</font><font color="#f1c232" style="font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">o</font><font color="#0000ff" style="font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">g</font><font color="#38761d" style="font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">l</font><font color="#ff0000" style="font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">e</font><span style="color:rgb(0,0,0);font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap">/ITA Software Engineer)</span></div><div><span style="color:rgb(0,0,0);font-family:Arial;font-size:15px;line-height:17.25px;white-space:pre-wrap"><br></span></div></div></div></div>
</div>