As a Roblox developer, it is currently too hard to write performant LUA code that works on low end devices, especially when there’s lots of moving parts on the client or when the client is processing a heavy workload.
Use Cases
The following use cases are presented.
Use Case 1
In my game, depending on the map, I have quite a few items that float up and down on a sine function, and rotate. All the items get this treatment for each tick of RunService.RenderStepped. Therefore, I have to run a for loop inside the event handler. I have done some tricks such as pre-processing as much of the data before hand as possible and not running the loop every time to help alleviate this, but it’s still an issue on lower end machines. This is generally a compute intensive task as the delta time from the engine is used to calculate the angle increment from the parameters on the parts themselves.
Use Case 2
Some on demand effects, such as lightning, are compute intensive as the position and orientation of each part that makes up the bolt must be calculated independently, and it relies on the location and orientation of the previous part so it can link up and look visually correct.
Additional Information
Although Roblox does support Parallel LUA, there are some very strict requirements in place which makes using Parallel LUA for effects mostly impossible since properties of instances cannot be written to in parallel mode, which is a design limitation albeit for thread safety for the engine. This means that even when using Actors to separate code into multiple threads, one is still forced to enter single thread mode to run the effects.
Conclusion
If Roblox is able to address this issue, it would improve my development experience because my code will run more efficiently on lower end devices and not bury the device in work that it will never catch up on.
I don’t understand this feature request. What is it that is being requested? --!native can already be declared at the top of the script to enable native codegen - and it wont always provide that big of the performance boost depending on what is being executed.
Clients have actors, servers have native codegen.
Sadly its too difficult to write exploit-free native codegen processing code.
e.g. a few months ago a bug existed which shifted variables registers so:
local a = buffer.create(16)
local b = 1
In this code, if you did certain buffer writes, the registers would shift and “a” would get shifted to have the value of “b”. (this was fixed a long time ago dont get too hyped)
Now imagine if this was used to gain access to certain restricted items — maybe this ends up in a sandbox escape — things would go south pretty fast.
Roblox’s reputation would be highly damaged after an attack causes some devices to get infected.
Im guessing the reason this feature was released on servers in the first place was because they are sandboxed and security measures everywhere.
We probably have to wait a few more years until the developers are sure there are no sandbox escapes or native code is fully sandboxed.
It’s a directive to the engine to compile the script into native machine code instead of the byte code for interpretation. Machine codes runs directly on the CPU at CPU speed, which significantly increases the performance of the code over interpretation.
PHP and JavaScript do this as well. I think other interpreted languages like Python and Ruby also do this. I haven’t heard anything about Apple hating JITC. Would you please elaborate? Have they stated any reasons?
apple only allows jit on web browser apps. they are pretty strict with this stuff as it could lead to security vulnerabilities, being able to generate executable code on the fly
Lua doesn’t use a stack because it’s register-based (it uses a return stack for function calls, but that’s unrelated). I have no idea what bug you are talking about because shifting registers should be impossible since they’re unsequenced.
Still, Apple does not permit running dynamic assembly on its chips, to the hardware level. This is the same reason Minecraft had to be rewritten in C++, because the JVM wouldn’t work on iOS.
Here’s the issue that I have. Since the code is precompiled before the client downloads it, I wouldn’t call that dynamic assembly. The code is compiled on publish and then sent to the device when the device logs into the server. I don’t see the problem here.
