Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[Neil Jerram <neil@ossau.uklinux.net>]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> I think I understand the point here, and it seems to me that this is
>> an improvement for the developer, not for the end user; and IMO not a
>> significant one (because it's pretty trivial to write a smob mark
>> function).  It also implies a performance cost, from scanning regions
>> of SMOB memory that Guile currently knows cannot contain heap
>> pointers.
>
> It really isn't that clear what performance impact libgc's pervasive
> scanning has.

Fair enough, let's wait and see what further investigation reveals.

>>>   * Rewrite the interpreter in Scheme (or a subset thereof), with a
>>>     tiny Scheme-to-C compiler.  That could be done in such a way that we
>>>     could re-use, e.g., the memoization and unmemoization code that
>>>     already exists in the first step.
>>
>> Interesting.  Do you think that that would be a lot faster than the C
>> code we have now?
>
> Note that whether it's implemented by hand in C or compiled to C doesn't
> make a significant difference.  The main optimizations I have in mind
> are the following:

These sound really interesting!  Do we need to wait for a rewrite of
the core interpreter, though, or could we try doing this in the
current code?

>   * heap-allocation-free closure invocations, which can be achieved by
>     storing a closure's arguments into a stack-allocated C array or,
>     even better, in registers (of course, invoking closures with rest
>     arguments would still require allocating an argument list);
>
>   * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
>     N is the frame number and M the position of the variable within that
>     frame's environment;

Are you sure the current algorithm is O(N*M)?  I would have said
O(N+M).

>   * no C function call overhead for tail(-recursive) calls.

I thought that was mostly achieved already, by extensive use of
gotos.  But I guess there must be important cases that I've not
noticed.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel