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

Re: when GC is permitted

Am 08 Jan 2004 14:05:27 -0500 hat Jim Blandy <jimb@xxxxxxxxxx> geschrieben:

But here's the alternative.  Under a SRFI-50 style interface, here's
the implementation of car:

    SCHEME_CAR (scheme_value pair)
      return untag_pair (pair)->car;

Under most reasonable tagging systems, untag_pair can be a
subtraction; the '->car' is a subsequent addition, which can be folded
in with the untagging; and then the whole thing can be easily inlined,
and possibly turned into an offset in the addressing mode of a load
instruction.  So the whole thing turns into a single instruction.

There's no comparison.  I think JNI entails at least one order of
magnitude more instructions to implement 'car'.

This is why Richard doesn't like JNI-style.

Now, I'm all for maximum performance, if possible. But that's not
(IMHO) the proper goal for this SRFI. The performance side of this
should come *after* it has been ensured that it is reasonable easy
to write *correct* code. Since we are using C here, correctness
can not be ensured completely - yet, we should try very hard to
simplify the semantics of FFI code, from the user's perspective.

Personally, all the syntactic issues, and how exactly gc-protection
is set up, naming, etc. is rather unimportant to me. Using Scheme
mainly for interfacing to foreign code is what I do most, including
packaging code written by others that interfaces to external libs.
I happly debug Scheme code, wether implementation-specific or portable,
I grudgingly debug Scheme/FFI code specialized to one implementation.
But something I'm not going to do is debugging Scheme/FFI code that
conforms superficially to a (allegedly) portable API, works
on some implementations and then fails on others.

Unless performance-considerations on the instruction-level are
important (and I doubt this is very often the case, and even if
it is: just push more logic over into the C side), let's forget
about this and fix the more obvious problems.