RFC: INLINE defcfun and auto FTYPE declarations [with patch]

Andrzej Walczak andrzejwalczak at google.com
Mon Nov 6 17:10:48 UTC 2017


Hi Luis,

I should have thanked you and your colleagues in my initial email for
implementing and maintaining CFFI.
It is a great library with a super design - personally I like it very much.

After some thoughts, I agree, that the inlining control is not a
fully-baked idea, yet.
I'll split the patch into INLINE and FTYPE parts.

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.

In the end, one of the reasons why developers interface to C is performance,
so IMHO the CFFI library, which is already great by default,
should allow developers to access every bit of performance that is there.

Regarding the FTYPE declarations - we build our software stacks with
different compiler policy settings.
In developer/test builds the declarations act as run-time assertions.
In production builds they produce much better optimized code.
At compile time, we can detect program errors using the type system.

The lisp-parameter/value-type generics, introduced here, allow us to
declare custom CFFI types
that for example pass like int64 but hold only fixnum values.
Or we can declare a string type that processes as simple-base-string which
gives nice optimizations in SBCL.

Also, always declaring FTYPEs on DEFCFUNs is a good thing since the C code
that we interface to is rather static as compared to Lisp code. Thus static
function
declarations of C stubs will always be a win.

Cheers,

On Mon, Nov 6, 2017 at 10:38 AM, Luís Oliveira <luismbo at gmail.com> wrote:

> Hi Andrzej,
>
> On Wed, Nov 1, 2017 at 10:43 PM, Andrzej Walczak
> <andrzejwalczak at google.com> wrote:
> > Recently we have migrated one of our largest projects from our home-grown
> > foreign-function interface implementation to CFFI.
> > The project is almost 1M LOC with almost 1K of foreign-functions.
>
> Cool! That's interesting to know!


>
> > The attached patch contains a proposal that we would like to share.
> > Please, let us know about any modification necessary that would make this
> > patch useful for a larger community.
>
> The idea of automatically inlining DEFCFUNs when SPACE > 2 > DEBUG is
> interesting. If we go down that route, we'd better be consistent
> across lisps, but I wonder if there's such a thing is possible when
> the optimisations vary so much across Lisps. Are CL otimisation
> declarations the best way to control the optimisation? I'm skeptical.
> I'm also a bit worried about using SBCL internals.
>
> I'm curious to know the purpose of the declarations. Are you mostly
> taking advantage of SBCL's declarations-as-assertions behaviour or are
> you looking for some sort of optimisation? Do you have any examples
> showing how they help?
>
> Cheers,
>
> --
> Luís Oliveira
> http://kerno.org/~luis/
>



-- 
Andrzej Walczak
(Google/ITA Software Engineer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20171106/5b75c400/attachment.html>


More information about the cffi-devel mailing list