[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Optional static types for Lua - experimental derivative Ravi
- From: Marc Balmer <marc@...>
- Date: Sun, 18 Jan 2015 22:22:14 +0100
Am 18.01.15 um 22:10 schrieb Leo Romanoff:
On Sun, Jan 18, 2015 at 11:27 AM, Richard Hundt <firstname.lastname@example.org
> Well the objectives are very different I think. I am looking to
> improve efficiency of certain operations. So the static typing is for
> that purpose. Therefore the features I intend to support will be a
> subset of above. For example, as of now I have no intention to provide
> syntactic support for classes or interfaces. Also no concept of union
Ah, okay, hence the additional ops. That's got me thinking: wouldn't
it be feasible to do run-time instruction specialization without the
need to add syntax (so you'd patch in your new ops dynamically)? If it
worked though, you could run vanilla Lua modules and perhaps get a
performance boost. Maybe that's a ton of work though without
substantial gains because recording, narrowing/widening overhead might
be too high to be beneficial. Dunno. Just an idle thought.
Do you mean something like this?
"Optimizing Lua using run-time type specialization"
How is adding type checking, in any form, optimizing Lua? Isn't it one
of Lua's great benefits that it is actually not statically typed?
In my experience, with a reasonably large code base, Lua not being
statically typed is much more of a benefit than a defect, so I wonder
why this idea of making Lua statically typed pops up from time to time.
Michael Schröder starts his text with claiming that "Like other
dynamically typed languages, Lua spends a significant amount of
execution time on type checks.". Is that really the case? Are type
checks really using a lot of CPU cycles? I have my doubts, but I have
not done the research.