FLI (C to Lisp) performance optimizations

I need hints on how to speed up (what I think are) performance issues in a 
program where C is calling my lisp .DLL.  The lisp DLL is in essence a 
"driver" and is being commanded to do things by the C front end.

A test case I'm looking at makes about 700 calls from C to lisp with doubles 
as parameters and 325 calls with C strings (fairly short - approx. 3 to 10 
chars), and makes about 400 calls with references to doubles (i.e. lisp 
returns a double to C) - and then does this about 1,000 times.  I.E. about 
1,000,000 calls with one or two parameters, which unfortunately need to be 
converted on the way in and sometimes on the way out.

A similar program done only in C does this in a very short amount of time 
(about 1/2 second).  The C / Lisp combination takes about 2 minutes, of which 
about 40% looks like it is due to my (very straighforward) use of FLI.

I'm about to rebalance the program so that most of this calling takes place 
only within C, leaving only big, infrequently-called lumps written in lisp.

But, if someone has suggestions on how to achieve wildly better performance 
while retaining the above interface (which would let me do more work in lisp, 
something I'd prefer), I'd be interested in hearing them!

I don't have a good intuition on how much work goes on behind the scenes in 
the FLI.

For example: 

- In a large number of cases, the parameter strings (converted to lisp from c) 
are simply pumped out character by character.  Can I / should I leave them as 
anonymous blobs of bytes which the FLI does no conversion on?  Will that save 
enormous amounts of work (time)?

- What if the number of operations on doubles is low?  Would it save time if I 
treated them as unconverted "handles" and called back to C routines to 
manipulate them?

- Is there any huge time advantage to stuffing these things into a C array and 
converting en-masse?

Thanks
pt

Re: FLI (C to Lisp) performance optimizations

Paul Tarvydas wrote:

> I need hints on how to speed up (what I think are) performance issues in a 
> program where C is calling my lisp .DLL.  The lisp DLL is in essence a 
> "driver" and is being commanded to do things by the C front end.
> 
> A test case I'm looking at makes about 700 calls from C to lisp with doubles 
> as parameters and 325 calls with C strings (fairly short - approx. 3 to 10 
> chars), and makes about 400 calls with references to doubles (i.e. lisp 
> returns a double to C) - and then does this about 1,000 times.  I.E. about 
> 1,000,000 calls with one or two parameters, which unfortunately need to be 
> converted on the way in and sometimes on the way out.

that's going to be time-consuming. avoid.

> A similar program done only in C does this in a very short amount of time 
> (about 1/2 second).  The C / Lisp combination takes about 2 minutes, of which 
> about 40% looks like it is due to my (very straighforward) use of FLI.
> 
> I'm about to rebalance the program so that most of this calling takes place 
> only within C, leaving only big, infrequently-called lumps written in lisp.
> 
> But, if someone has suggestions on how to achieve wildly better performance 
> while retaining the above interface (which would let me do more work in lisp, 
> something I'd prefer), I'd be interested in hearing them!

well, the obvious answer is that unless your calcs are sequentially 
dependent, you should pass an array or two full of the numbers, so there 
are very few calls, but much computation. type conversion may still be 
the same amount, but you drop the repeated fn-call overhead.

> I don't have a good intuition on how much work goes on behind the scenes in 
> the FLI.

heck, I don't either, but I sure wouldn't do what you've done.

> For example: 
> 
> - In a large number of cases, the parameter strings (converted to lisp from c) 
> are simply pumped out character by character.  Can I / should I leave them as 
> anonymous blobs of bytes which the FLI does no conversion on?  Will that save 
> enormous amounts of work (time)?

yes. bytes are bytes.

> - What if the number of operations on doubles is low?  Would it save time if I 
> treated them as unconverted "handles" and called back to C routines to 
> manipulate them?

depending on how complex the calcs are, I'd think about duplicating 
functions in both langs.

> - Is there any huge time advantage to stuffing these things into a C array and 
> converting en-masse?

the conversion time probably won't change much. but you can avoid 
inter-language fn-call overhead...

  -- clint