From: David Bakhash
Subject: foreign function overhead
Date: 
Message-ID: <m3og6ez5tp.fsf@alum.mit.edu>
Hi,

One of the things I've never really explored when dealing with foreign 
language interfaces such as ACL's FFI and LW's FLI, is the overhead to 
calling a foreign function, and converting data between languages.
for example, I imagine the overhead in calling a foreign function to
be the cost of converting the arguments to C data types, and then
converting the return types back to Lisp.  That seems pretty heavy.
Furthermore, I imagine that even once that's done, there's even more
overhead, just as Lisp functions under a given implementation may
incur more overhead than C function calls, and the ff calls, being
hybrid, will likely incur at least the overhead of Lisp funcalls.

In this sense, I've always treated ff calls the way I treat SQL calls
-- as very expensive.  If people can expound on this, I'd like to hear 
more about them.

dave

From: Raymond Toy
Subject: Re: foreign function overhead
Date: 
Message-ID: <4nu2g6s19a.fsf@rtp.ericsson.se>
>>>>> "David" == David Bakhash <·····@alum.mit.edu> writes:


    David> One of the things I've never really explored when dealing with foreign 
    David> language interfaces such as ACL's FFI and LW's FLI, is the overhead to 
    David> calling a foreign function, and converting data between languages.
    David> for example, I imagine the overhead in calling a foreign function to
    David> be the cost of converting the arguments to C data types, and then
    David> converting the return types back to Lisp.  That seems pretty heavy.
    David> Furthermore, I imagine that even once that's done, there's even more
    David> overhead, just as Lisp functions under a given implementation may
    David> incur more overhead than C function calls, and the ff calls, being
    David> hybrid, will likely incur at least the overhead of Lisp funcalls.

Isn't this a quality of implementation issue?  CMUCL supports the
foreign types pretty well, and there's no copying/converting unless
absolutely necessary.  For structures and such, you either deal with
the alien types as alien types or copy the structures back and forth.

Also, the sources for CMUCL claim that calling out to C is at least as
efficient as calling lisp, so at least for CMUCL foreign calls are
pretty cheap.

Ray
From: Joe Marshall
Subject: Re: foreign function overhead
Date: 
Message-ID: <u2g6w7ry.fsf@alum.mit.edu>
David Bakhash <·····@alum.mit.edu> writes:

> Hi,
> 
> One of the things I've never really explored when dealing with foreign 
> language interfaces such as ACL's FFI and LW's FLI, is the overhead to 
> calling a foreign function, and converting data between languages.
> for example, I imagine the overhead in calling a foreign function to
> be the cost of converting the arguments to C data types, and then
> converting the return types back to Lisp.  That seems pretty heavy.
> Furthermore, I imagine that even once that's done, there's even more
> overhead, just as Lisp functions under a given implementation may
> incur more overhead than C function calls, and the ff calls, being
> hybrid, will likely incur at least the overhead of Lisp funcalls.
> 
> In this sense, I've always treated ff calls the way I treat SQL calls
> -- as very expensive.  If people can expound on this, I'd like to hear 
> more about them.
> 
> dave

It depends, of course, on what you are calling, what argument types it
takes, and the details of the foreign function interface.  I'd be
surprised if it took as much overhead as an SQL call, though.  I would
expect it to be of the same order of magnitude as an `inter process'
RPC (as it is doing essentially the same sort of work, marshalling the
arguments, constructing a frame, transferring control, marshalling the
result and freeing the resources).

However, the right thing to do, if you are worried about the
performance of a particular application, is to *measure it*.
Otherwise, don't worry about it, I don't.

~jrm
From: David Bakhash
Subject: Re: foreign function overhead
Date: 
Message-ID: <c29wvl135lc.fsf@w20-575-31.mit.edu>
Joe Marshall <·········@alum.mit.edu> writes:

> However, the right thing to do, if you are worried about the
> performance of a particular application, is to *measure it*.
> Otherwise, don't worry about it, I don't.

yeah.  me neither.  It was more of just an interesting diversion.  I was 
just curious to know the details of the ff calls, and their relative
performance.  To me, it's neither here nor there.  Sometimes, people
care about trivia, expecting that the knowledge will someday make a
difference, and in the meantime just feeling more knowledgeable,
somehow.

btw, thanks for the answers,
dave