[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] A more detailed plea for help with FFI...

From: Ed Watkeys
Subject: Re: [Chicken-users] A more detailed plea for help with FFI...
Date: Wed, 15 Dec 2004 12:44:13 -0500

On Dec 15, 2004, at 12:14 PM, felix winkelmann wrote:

Is your "use finalizers conservatively" policy about performance or
correctness? (That's not necessarily an either-or question.)

[...] Use finalizers when they fit the job, but excessive use of them will decrease performance (chicken-specific) [...]

What sort of overhead is associated with a finalizer call, compared to a normal GC operation? For example, if I created a string library that malloc'd memory (in C), and free'd it via a simple function installed via set-finalizer!, how would that compare to Chicken's built in strings? So, in other words...

(let ((chicken-string "This is a test."))
      (foreign-string (make-foreign-this-is-a-test-string)))

Putting aside the fact that a sufficiently intelligent system could optimize this down to #t, how do chicken-string and foreign-string meet their ends? As soon as I get back from lunch, I'll write a couple programs that create and destroy a million native chicken-string and foreign-string instances and compare the run times.

Speaking of optimization, would knowing whether a foreign function has side effects allow any Scheme compiler written in the next (umm) ten years produce better code? Straying even farther afield, what's your take on the whole dynamic recompiling VM approach vs. static compiling? As a Mac old-timer, I remember dealing with the 68K -> PPC transition, Apple's 68K interpreter, and their subsequent DR 68K interpreter. Everyone seemed to forget about that just in time for Sun to "discover" the same approach and use it in their HotSpot JVM, which -- I've read -- can beat optimized, compiled C code thanks to the dynamic analysis of the code. And then there's Transmeta, but I'm not an x86 guy, so I never paid that much attention.


Watkeys Product Design *
address@hidden * +1 215 694 4201

reply via email to

[Prev in Thread] Current Thread [Next in Thread]