This is great, but there was a part of plugin code broken while enabling this beta.
Mind taking a look?
(Can’t resize trusses)
This is great, but there was a part of plugin code broken while enabling this beta.
Mind taking a look?
Getting a 4x improvement in our Sweep code (raycast but with arbitrary shapes in place of a point)
Getting a 6x improvement in our locomotion stepLinking code (which is just a big matrix inversion)
In our IK code, we get almost no improvement in real tests, though I don’t want to post it because it is sensitive. Should I just DM?
So to my understanding this will increase the performance on the CPU right? The GPU will stay unaffected as the script execution happen on the CPU.
Also if I am not wrong the Roblox app and its core scripts already run natively right? This is to get Luau from experiences that are made in Roblox to run native and therefor faster.
I wonder in a client side(when it gets released) at rendering how much faster games are gonna be now
This seems unrelated to this beta (doesn’t go away when the beta is disabled), but we’ll take a look!
If your IK code is using Vector3 heavily then this is known and we will be working on Vector3 optimizations soon! If your IK code is scalar only then we’ll reach out via DM.
Sorry for the error, that one’s my fault, not related to this beta.
Specifically, resizing single TrussParts is broken in Studio right now. It’ll be fixed in the next release, until then you can still resize them through the Size property in the properties pane if necessary.
Ah yes, it’s entirely quaternions represented as (scalar, Vector3). I saw in the post that Vector3s did not see a similar improvement, but I expected at least something because Sweep has a lot of Vector3 operations in it… I just didn’t expect the scalar improvements to be so great as to basically become free in comparison to Vector3, really impressive.
Will native code gen be taking advantage of SIMD if it isn’t already?
I think I stated this in earlier posts but the memory increase is likely due the fact that native code is less compact than Lua byte code.
You get more speed at the cost of maybe using a little bit more memory than normal.
And (maybe) possibly slightly slower loading times in games that heavily use this feature (due to compilation time).
Is it planned to allow pre-compiling code eventually? i.e. publish game → code gets compiled by roblox → players join game and receive compiled code
I feel like this would be really good since the initial slowdown will be gone AND on top of that exploiters won’t be able to steal code as easily because its machine code and not bytecode.
isn’t that just how it works?? oh wait nvm
Don’t really have a proper benchmarking solution.
When enabling native code for my Conways Game of Life (Purely tables and a lot of for looping), I get around 1.4x - 2x (Could be higher) faster generation steps compared to native code disabled. For some reason the varying 1.4x and 2x is due to the number of live cells being check in every iteration. It seems like native code gets a bigger benefit when there are more live cells being checked.
native code disabled:
native code enabled:
I’ll try this on my Path Tracer if this makes a significant difference.
i have wave generation (and calculation) in one of my games, is that a valid use case for “native code”?
Not yet but yeah the plan is to use SIMD instructions for Vector3 ops.
Supporting C would be more cool, but I think this is a really surprising and interesting challenge.
but I have a question. Does it download source code from the server into the client and compile it on the client side? In detail, when is it compiled to native code?
Supporting a low-level, memory-unsafe, beginner-unfriendly language would be a pretty bad idea.
The reason for releasing native code is to compile it into machine language, similar to C, so that complex and numerous calculations can be processed more quickly. “Doing complex and numerous calculations faster” There is nothing better than C. Moreover, some Lua functions actually work in C level (like math, string etc). And security only needs to prevent a few libraries and a few security vulnerabilities. If roblox support C, it would be able to quickly perform AI deep learning, pathfinder, and other large operations faster than Lua native code.
To add on, people who manage to learn and use C on Roblox would have to go through the tedious effort of allocating and deallocating memory in their code should it be necessary. C doesn’t have a garbage collector to automatically allocate unused memory, so it leaves it up to the user to manually allocate memory from one value to another.
In my experience with C, I find this very tedious.
Will code that involves C → Luau → C transitions see noticeable performance gains when run natively?
Luau → C transitions may get a little faster, but C → Luau transitions don’t, so overall not much has changed here and avoiding these transitions is still good for performance, native code or not.
As of Studio 0.593, this beta is now supported on macOS! Reminder:
We are continuing to work on improvements to native code performance; as these are motivated by specific benchmarks, please continue to let us know if you have code where you are not seeing the expected improvements. We also may reach out to people who posted about their results to discuss them in more detail.