[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [r6rs-discuss] Implementors' intentions concerning R6RS
From: |
Neil Jerram |
Subject: |
Re: [r6rs-discuss] Implementors' intentions concerning R6RS |
Date: |
Mon, 12 Nov 2007 20:29:12 +0000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <address@hidden> 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