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@gmail.com> wrote:

Hi Andrzej,

On Wed, Nov 1, 2017 at 10:43 PM, Andrzej Walczak
<andrzejwalczak@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)