[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.