fwsgonzo

Awesome stuff. I will promptly add this in my (rather large) game engine and see how it affects startup!

This video has been a good introduction: https://www.youtube.com/watch?v=ZHNNW8c_FaA

I live on the coast of Norway so I am trying to keep up with the research. It is exactly as the article says: Even if there's "only" a 10% chance, or even 5%, that's a huge risk to take to stay. So I think it's important to pay attention to this henceforward.

I have a 1,5M LOC game codebase, where both the server and client builds and starts nearly instantly. Probably < 3sec total iteration time just because of typing stuff in the terminal. Build system is just a casual ccache + mold. But you have to do a lot of stuff in the background during startup.

Hard to disagree, but have you seen abroad? Seems like outside Europe you're at a constant one health crisis away from homelessness. Is that even an exaggeration at this point?

https://i.redd.it/e2u2h3la7e1b1.jpg

How long has RISC-V been around? Seems to me that it's doing well on any measure.

I made a scripting solution for my game, mainly to keep motivation up. I really like writing an maintaining a high-quality emulator, while game development can be a slog sometimes. I believe this has kept me from losing motivation and perhaps it can be attributed to me one day releasing that game.

Progress on linking a basic program? https://stackoverflow.com/questions/64308644/rust-unable-to-...

The first thing to look for is if the solution states clearly that it is a speculation-safe sandbox. I do think that not many will do that, but there are some. And go from there.

That's what they do. They add additional layers on top of the sandbox like jailing. You can jail your sandboxes, but it's not so easy to make that a multi-platform solution for gaming. I think for games I would just stick to a fast interpreter and apply some generally appropriate measures to discourage timing attacks.

It's much worse than that because of the complexity around JITs, behavior of hardware and speculative execution. Proper sandboxing is really hard, and I suspect that if people really want security they would disable JIT in general. Even simple ones like pcre2. Personally I have disabled Firefox's JIT (I believe it's called ion in the settings, but correct me if I misremember) for a few years now. I've never had any trouble with any websites so far. It's not instant loading, but it's close enough.

... but I don't know if I would lump bytecode with JIT. Bytecodes don't need or use RWX execute segments, for example. Lots of your favorite JITs do, for speed.

Very interesting, and that constant folding trick is handy!

I live on a remote island too, but it has a bridge! Same feeling: Wouldn't want to live anywhere else!

Indeed, I think he's repeating something that is today outdated information. With RVA profiles, we know what desktop-class RISC-V looks like, and that's what people might compare against ARM.

Thank you! That explains it. I must have made the example for 0.11!

I used the "official" example. It's OK that things break - just that I can't figure out how to update my previously working code. So, I'm wondering - where is the updated official example of using the HTTP client?

Somehow it was uBlock. Disabled it and the game starts just fine!

Is "call to eval() blocked by CSP" supposed to happen? I'm on Firefox.

I was just playing this myself. Felt like finding a gem in a sea of uninteresting games.

As usual the HTTP client example is broken again: https://github.com/fwsGonzo/libriscv/blob/master/binaries/zi...

Congrats on shipping a game! It's truly an insane amount of work these days, with all the competition out there.

I saw that. Keep in mind that libriscv is 35% faster than wasm3, and it looks like wasmi is not as fast as wasm3 yet. But they are making good progress.

I've been at it for a few years now and my experience with game engine scripting is that the functions are small, and that it's helpful or pleasant to have the ability to make many calls back into the game engine to ask for things, even simple things. My measurements have shown time and again that libriscv spends 3ns entering and leaving the emulator dispatch, and 2ns to execute a system call or even a more complex host function scheme (using custom instructions).

So now it's a race. For example, wasmtime needs 48ns just to enter and leave, and 24ns to make a call into the host. That's around 100-150 instructions libriscv can execute before wasmtime has even overcome the fixed call latencies. And then add 50 each time we make a call back into the engine.

Now combine this with my ~200 host functions in my game, and I don't know how many in-game events. Which function would wasmtime be faster at? I don't know, probably not a single one. And that's really it. There's no fibonacci computations in game engine scripting. It's just logic.

As far as using complex run-times for scripting: I've already been doing this dance for years now. For example, TinyKVM is a native performance KVM userspace emulator that I among other things ran v8 inside. You can find my research paper about it. So it's not like I couldn't throw v8 in there and slideware some JS solution. But, I really do prefer writing C++.

Also related is attack surface. libriscv is 10k LOC. wasmtime is what, 350k LOC?

Here is a random function I benchmarked: https://fwsgonzo.medium.com/a-sandboxed-rainbow-function-b42...

wasmtime spent 107ns and libriscv 57ns. Those kinds of functions is your average script function. And, even if we were exactly matching in latency, I would still call that a win!

EDIT: To add, you did make a good point about tooling, components etc.

Nothing wrong with using WebAssembly, if you wish to. eBPF I'm not so sure is a good fit. Most people are just fine with Lua, LuaJIT or Luau though. This is really just for especially interested, or if you really need low latency.

This whole comment sounds dismissive towards both me and RISC-V as an architecture people actually run their computers on.

I have a lot of blog posts that you can read to get up to speed. Or maybe you already made up your mind.

You're right! I actually did try to integrate a compiler, but I quickly realized that it wasn't worth it for me, personally. Iterating on the script is very quick right now. It's mostly a matter of compiler flags and ccache, believe it or not. And I can use mold for linking RISC-V!

Yeah, I can confirm that the iteration speed is fast. I consider the scripting portion a solved problem right now, having used it so long. Gamedev is so many other things though, and practically every corner of the engine has to have convenience functionality in order to reduce the overall workload. It's rough for gamedevs right now, I feel like.

I spent a lot of time on those benchmarks. I think my conclusion is just that because WASM isn't a register-machine architecture, you basically have to implement a register allocator to be really fast. wasmtime uses a complex allocator to great success. wasm3 has done it too, but it's just a basic one and it won't be able to compete with GCC or Clang. I could be wrong here, but what else is there? During my testing, it was never in question if libriscv was faster.

I used my usual benchmarks: STREAM (memory) and CoreMark (CPU).

Ah yeah, I have installed RISC-V with a oneliner in WSL. So it's not too far off on Windows, but I mostly program on Linux these days. You can also build on a Linux VM and share it to Windows, but what kind of iteration loop is that?

I don't know. Perhaps clang-cl could be used on Windows? It depends on how much of a run-time environment one wants.

Maybe I'm old now. I'll remove it from the article! Reading back on it, it seems like I'm writing negatively about Lua, despite using it for many years. I think highly of Lua, and especially think it has made so many things easier for people over the years. I actually chose Nelua as one of the examples (Part 3) because of it!

Writing performant code is a highly complex and arduous task that is highly dependent on compiler, language, system, hardware and actual needs.

It's also about understand the black box that is your program by using tools beside the programming language to understand memory usage, allocation patterns, blocking operations and dead-time, bloat, destructive interference in multiprocessing applications, NUMA-stuff and so on, and so forth. Then there's program-specific things like SIMD-processing, using efficient algorithms, differences created between standard-library implementations.

So, which language is faster is just a chapter in a book about performance. And, comparing two languages it feels like comparing apples to oranges. If you had the chance to go back and write a program over again, you will probably end up with an overall different, hopefully better, design.