fully parsed and bytecoded Tcl
Russell Treleaven
Here is a quote from an earlier post from Jeff Hobbes
"I actually did the modifications that allowed global compile. I am not
convinced of the oft-repeated but never really well analyzed statement
"code that runs just once is faster to interpret than compile". In
fact, I no longer believe it for most "standard" code.
Furthermore, Larry and I have discussed a bit what it could mean to only
have a compile side (fully parsed and bytecoded) Tcl. You could
possibly excise a large chunk of the classic Tcl codebase by moving to
that. I would like to discuss this further at the Tcl conference"
I believe this means faster execution, smaller codebase and smaller runtime.
Did this get discussed?
It sounds great, Is there a downside?
Sincerely,
David Gravereaux
> Is there a downside?
binary files that aren't human readable, perhaps.
--
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
Donal K. Fellows
> I believe this means faster execution, smaller codebase and smaller
> runtime.
Maybe. The interpreter part of the Tcl implementation really isn't that
big though.
> Did this get discussed?
It wasn't a presentation, but rather an informal "in the corridor" type
discussion. Maybe with beers to hand. :-) Which is to say that I wasn't
there, though I did discuss with a few other people (including both
Miguel and Kevin) whether it is possible to move to *full* compilation
(i.e. all the way to native machine code) of Tcl procedures. (We think
it is possible, but it's definitely non-trivial. Won't be in 8.5. :-))
> It sounds great, Is there a downside?
It can change the semantics very slightly (though if you're writing code
that depends on such things, you should probably poke your eyes out!)
even on 8.5 (which is a lot more correct about these things than
previous versions) and it has the theoretic overhead of the extra
compilation step (which might or might not be a problem). However, as
long as the source is retained (and some scenarios require this anyway)
then there should be no real down-side. I've no idea whether the
performance loss from extra compilation is worth it though; it's a
non-trivial study to carry out. (Help with improving the benchmark
suite, downloadable from the tcllib CVS as its own module, would be
definitely welcome. And it's pretty easy to do; all tests are just
scripts...)
Donal.
suchenwi
Donal K. Fellows schrieb:
> ... I did discuss with a few other people (including both
> Miguel and Kevin) whether it is possible to move to *full* compilation
> (i.e. all the way to native machine code) of Tcl procedures. (We think
> it is possible, but it's definitely non-trivial. Won't be in 8.5. :-))
Maybe the currently ongoing efforts of making tcc available to Tcl
(Odyce, mjanssen) hay help here?
Kevin Kenny
Generating machine code is the *easy* part. Doing type inference
so that the gemerated machine code willbe significatly faster than
bytecode, that's *hard*. It looks *possible*, but it'll be quite
a _tour de force_ even in the broader programming-language
community if we do pull it off at all well.
--
73 de ke9tv/2, Kevin
suchenwi
> Here is a quote from an earlier post from Jeff Hobbes
>
> "I actually did the modifications that allowed global compile. I am not
> convinced of the oft-repeated but never really well analyzed statement
> "code that runs just once is faster to interpret than compile". In
> fact, I no longer believe it for most "standard" code.
> I believe this means faster execution, smaller codebase and smaller runtime.
Codebase size and runtime depend on the core makers, but you can test
"faster execution" right today - by putting your script in: if 1
{...}. The [if] body gets byte-compiled. Time both varieties, and let
us know if you find interesting differences :^)
Alexandre Ferrieux
>
> Generating machine code is the *easy* part. Doing type inference
> so that the gemerated machine code willbe significatly faster than
> bytecode, that's *hard*.
>
Of course. But handmade type annotations can largely simplify the
task, in addition to helping the compiler report violations in the
most helpful place (instead of 3 parsecs away, like may happen in
ambitious functional languages ;-).
I guess you have already thought this over. What's the verdict ?
-Alex
PS: maybe the notion of type constraints too UnTclish -- sorry if it
is...
Donal K. Fellows
> I guess you have already thought this over. What's the verdict ?
Let's see what we can do without them.
Donal.
Alexandre Ferrieux
It seems a bit in contradiction with Kevin's comment:
> > It looks *possible*, but it'll be quite
> > a _tour de force_ even in the broader programming-language
> > community if we do pull it off at all well.
-Alex
Donal K. Fellows
> Donal K. Fellows wrote:
>> Alexandre Ferrieux wrote:
>>> I guess you have already thought this over. What's the verdict ?
>> Let's see what we can do without them.
>
>
>>> It looks *possible*, but it'll be quite
>>> a _tour de force_ even in the broader programming-language
>>> community if we do pull it off at all well.
No contradiction there, and nor do I see how it is possible to read such
into my words. Kevin (correctly) states that it is hard, and I feel that
to give up without trying, especially as we can use runtime-collected
data to help, is defeatism. Less meta-discussion, more code!
Donal.