Hi,
Neil Jerram <[EMAIL PROTECTED]> 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
improvements.
> 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.
Thanks,
Ludovic.
_______________________________________________
Guile-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/guile-devel
