Luau Native Code Generation Preview [Studio Beta]

This is great, but there was a part of plugin code broken while enabling this beta.

Mind taking a look?


(Can’t resize trusses)

3 Likes

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)
:slight_smile:

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?

8 Likes

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!

2 Likes

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.

4 Likes

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.

7 Likes

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?

1 Like

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).

2 Likes

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.

9 Likes

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:
image

native code enabled:
image

I’ll try this on my Path Tracer if this makes a significant difference.

3 Likes

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.

9 Likes

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?

1 Like

Supporting a low-level, memory-unsafe, beginner-unfriendly language would be a pretty bad idea.

  • Roblox already has a programming language they’ve built up over the years called Luau. Adding another supported language would not only massively increase the engineering time needed, but introduce extra complexity and confusion among developers
  • C is not memory safe, and there would be a significant amount of time needed to properly sandbox it and fix security vulnerabilities
  • C is literally lower-level than the language the Roblox engine is written in (C++)
  • C isn’t very beginner friendly and is way more complicated to write code in as a beginner than Luau
  • Why would you want to make it more difficult to write code??
5 Likes

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.

1 Like

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?

1 Like

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.

2 Likes

As of Studio 0.593, this beta is now supported on macOS! Reminder:

  • If you’re using an Intel based Mac, make sure you have macOS 10.14 (Mojave) or later;
  • If you’re using an Apple Silicon based Mac, make sure you have macOS 13 (Ventura) or later; additionally, make sure you are running the ARM binary (Activity Monitor should say “Apple”).

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.

3 Likes