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/