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

Re: when GC is permitted

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.

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.