[Top][All Lists]

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

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

From: Ludovic Courtès
Subject: Re: [r6rs-discuss] Implementors' intentions concerning R6RS
Date: Sun, 11 Nov 2007 16:28:53 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)


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.

>>   * 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:

  * 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;

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

I'm sure there's much to gain from these.  Implementing it in Scheme
would improve maintainability while keeping room for future

> I'm pretty Unicode-ignorant, but I've read enough to think that this
> area is important.  Is the problem with the C API just that it has
> "char" everywhere?

Yes, mostly.  That said, I'm not sure exactly how the C I/O API would
need to be changed.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]