Please tailor SLua compiler optimizations to second life
Fizz Savira
The rational is simple enough. Even though 128k is bigger than ever, it's not infinite. Optimization controls that are "standard" aren't as useful as optimization controls that fit the demands of second life.
Optimizations that reduce code footprint (e.g. aggressive constant folding) should be usable without triggering optimizations that increase code size in the name of performance.
I don't know what optimizations are available, and how you want to treat optimization control in scripts, but it seems that tailoring them to fit second life make sense.
Log In
primerib1 Resident
If LL needs to implement too many SL-specific optimzation, that will consume manpower for maintenance, resource that probably can be better allocated elsewhere to modernize the creaking old simulators.
Besides, if scripts so far can work acceptably with 64 KiB even if their bytecode is huge (compared to SLua's), then a reasonably similar script should work really fine with 128 KiB.
Wulfie Reanimator
primerib1 Resident To be fair, the cases that matter aren't scripts that already fit into 64KB or the SLua equivalent. A ton of systems have been split into multiple scripts because they cannot fit into one.
primerib1 Resident
Wulfie Reanimator Well, that trick should still work with SLua, no?
I'm actually more concerned of the truism that "Software will expand to fill all available RAM and then some".
Setting a limit to 128 KiB makes people at least more aware that they don't have carte blanche entitlement to server-side memory.
Also, I've read somewhere -- probably in Discord? I forgot -- someone wrote that their highly-optimized LSL scripts running on SLua runtime sometimes end up smaller than a similar SLua script, so there's saving there + 64 KiB addition = good thing.
Tapple Gao
I'd prefer this was implemented upstream in luau, and that SLua did not fork the code generator. Either of the following:
- Add more fine-grained inline optimization options, or
- Add a new optimize setting -Os/--!optimize size
Either one would require an RFC. I can't find one either accepted, in-progress, or rejected for either of the above options: https://github.com/luau-lang/rfcs/pulls
Kristy Aurelia
Yeah, SLua needs optimiser tweaks to get the best outcome, since for SL we really care about bytecode size, more than speed, since bytecode size takes away from stack/heap size.
One of the examples is that
-O2
can sometimes result in inlining that produces larger bytecode, as it can inline some of the function calls, but not all, resulting is a lot more copies of the bytecode.But there are other parts of
-O2
that do result in better bytecode like more aggressive bit32
const folding, which has no drawbacks.