Front page | perl.perl6.internals |
Postings from October 2005
Re: Tcl - compiling
Thread Previous
|
Thread Next
From:
Will Coleda
Date:
October 3, 2005 18:52
Subject:
Re: Tcl - compiling
Message ID:
24F09DBC-F4D0-4834-B2D9-FE40E6CCEFF4@coleda.com
On Oct 3, 2005, at 6:34 PM, Leopold Toetsch wrote:
>
> On Oct 3, 2005, at 22:57, Will Coleda wrote:
>
>
>> 3) Keep a global counter that is incremented whenever a procedure
>> is created or rename'd. When generating the compiled code, key
>> against this counter - if it's changed, we must fall back to the
>> interpreted version. (which, although it starts out with a a call
>> to the compiled builtin, might have been replaced at that point.).
>>
>
> I don't see the point. Your compiler can emit, e.g.:
>
> "while"(test, body)
>
> You provide an appropriate implementation of a default "while"
> function, in your default namespace.
> Whenever user code overrides the "while" word ("set while $foo" -
> or some such - I dunno Tcl syntax details), you store_global the
> new implementation as a compiled function into the same namespace
> (or as a lexical).
>
That's actually how things work right now (very similar to the
interpreter from previous versions).
I'm suggesting switching to inlining the code when possible... and
then watching out for cases where the inlined version is stale (using
a fairly simple method, but one that'll still give us a boost.). The
degenerate case using this caching/inlining will be the current
implementation (plus an integer compare before each invocation)
Is the argument that inlining will not (even theoretically) provide a
speed boost? I imagine on single pass code it'd be a wash, but for
something like while, we're potentially avoiding one find_global per
statement per iteration of the body, as well as the associated call/
return for each element in the body. Even for something like examples/
bench.tcl, that'd be tens of thousands of parrot sub calls/returns
that we could potentially eliminate. as low as that overhead is, I
imagine it's got to add up.
The nice thing about doing the inlining _as it's available_ means
that (presuming this *is* a good thing), we can inline the builtins
that give us the best boost first, and I don't have to reimplement
everything all at once.
Regards.
Thread Previous
|
Thread Next