[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Generic optimizable operation syntax proposal
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Sun, 5 Jun 2022 15:03:53 +0200
On 03/06/2022 13:52, Sergey Zakharchenko wrote:
One of Lua's greatest strengths is its hackability. It's possible to
add custom opcodes and operators representing them, but in doing so,
we break source-level compatibility. What if we could have a
universal and familiar syntax representing the operations? Here's
what I have on my mind:
------------------------------------------------------------ In BNF:
prefixexp ::= var | functioncall | ( exp )
prefixexp ::= var | functioncall | ( exp ) | ` ( exp )
In expression documentation, add:
`(exp) is equivalent to exp, but possibly optimized in an
All feedback welcome!
I'm very wary of any syntax change that hampers readability and is not
related to clearly defined semantics.
If we want highly optimized code we have C, with all its hassles
regarding unspecified, implementation-defined and undefined behavior,
where implementations are free to define (and document) undefined
behavior as an extension! And all that pesky sequence-point rules.
And Lua was designed from the start with C integration in mind.
Now what would `(exp) mean exactly? Would it be just a hint that
something *might* be optimized by the current implementation? Or is it
an explicit request like "*do* optimize this if you can" to the
Does it change the semantics? No? So why would the programmer care? Why
wouldn't the programmer want a more optimized code? Maybe because there
are drawbacks? Is it really useful to let the programmer simply say
"optimize" or "not optimize", without knowing explicitly what is
What if there are different level of optimizations with different
tradeoffs? Memory vs speed, maybe? How could the programmer say
"optimize at level 2, but not at 3 in this case"?
At this point the programmer should really be able to *choose
explicitly* what he needs. Again, this seems the realm of C, or of
explicitly calling different implementations of a Lua function.
Expression-level optimizations is something an implementation should
tackle, and only if it is generally useful. Lua already optimizes some
expressions (e.g. repeated use of ".." operator), but IIRC it doesn't
have a general bytecode optimizer (like some C compilers do at assembly
level, where they exploit all the leeway the standard gives to
In the end, your proposal seems to have very limited usefulness in
general (IIUC: just when you have two possible options where the
programmer may need to make an informed choice about a possible
optimization that is not "tunable").
OTOH, this breaks one of the best practices of high level programming
and SW engineering: hiding implementation details. And what is more
"implementation-detaily" than an optimization?
And it hampers readability too. What if I want to optimize only a
subexpression? Would something like the following be valid?
x and `(type( x ) == 'number') and `(myfunc(z))
And what happens to this code when you run the program in another
implementation that does *different* optimizations?
Again, the code gets obfuscated and the only advantage is very context
Of course there are times when a programmer wants to know something
about the efficiency of an algorithm (e.g. is this function O(1) or
O(n)?), but if one is using Lua for fine-tuning efficiency IMHO they are
on the wrong path: they should use the C-API instead and *document
extensively* any function that they make available on Lua side and
document each call site stating *why* it is important that the specific
call is a call to a heavily optimized function.
What you propose could be obtained more simply as:
-- optimized algorithm, maybe implemented in C in some implementations;
-- regular code in non-optimized implementations.
-- Call site:
if test(x,y,z) then ....
If the overhead of the function call is excessive wrt the execution time
of the body of the function, this would call for (pun intended) a
general change of Lua VM where function calls could be inlined (IDK if
current Lua implementation inlines some calls).