Noooo, even with APX the DIV and IDIV instructions are hardwired to rdx:rax :(

I filed an issue on what I think the minimum set of instructions that wasm needs to efficiently implement JITs of systems with MMUs is: try-load and try-store. github.com/WebAssembly/... Interested in feedback. (From what I see, this would enable fast emulation on non-jailbroken iOS.)

Interesting that having to emulate paging via softmmu and 80-bit x87 floats are what kills copy.sh/v86 wasm-based JIT performance. I wonder how fast you could go with MMU-less RISC-V Linux? Could be nice for non-jailbroken iOS.

Project that'd be fun but that I have no time for: Compile and run native code on-device on iOS by running macOS (or Windows?) interpreted in a VM on-device, and have the VM talk to the iOS device via a tiny device ($5 microcontroller?) you plug into the USB port that loops the USB back.

I noticed that x86 APX has a prefix that allows for 3-operand insns (e.g. add rax,rbx,rcx instead of mov rax,rbx; add rax,rcx). I wonder what the advantage of that over the 2 instruction pair is? Couldn't the CPU fuse the latter instruction pair into effectively a 3-operand insn?

OK, the way Clippy told me to replace cos(pi / 4) with the FRAC_1_SQRT_2 constant is wild. Clippy is becoming self-aware.

Bevy 0.17! I only have minor improvements in this one, because my engine-level work has been focused on VFX instead of Bevy proper, but the improvements everyone has contributed to this have been awesome to see!

OK, I love this. tl;dr using knowledge of your allocator, speed up linked list traversal by adding a branch that guesses where the next linked list element is and pre-populates the "next" variable to eliminate stalls if the allocations are well-behaved.

Wrote up how Unity's "Freeform Stretching" and "Rotate With Stretch" features work so that the next person who wants to run them on GPU doesn't end up pulling their hair out: gist.github.com/pcwalton/ff7...

Just reverse engineered Unity's "Freeform Stretching" and "Rotate With Stretch" particle system features. Never had a problem devolve into "write down as many random observations as I can until I get down to 2 equations with 2 unknowns and can solve for the result" before, but sometimes it works!

RTX in Bevy!

Well, that was certainly a bug. Problem: Hanabi particles are too fast. I store direction and magnitude separately, but direction wasn't being normalized. Hmm. Bug in my normalization code? No, it looks right... 1/

I made my temporary fork of Bevy Hanabi more concrete. It's now called Hanabi-Batched: github.com/pcwalton/bev... This is a temporary fork that provides much better performance in real-life scenarios, making the difference between a shippable game and not in most cases.

Also true for Rust.

With the GPU-driven rendering work I did earlier this year and the Hanabi VFX work I'm doing now, Bevy is consistently hitting 120 FPS for me. Looks really nice on a high refresh rate display. Building a GPU-driven renderer is a ton of work, but the results *really* pay off.

Just pushed a branch of Hanabi, the GPU VFX system for #bevyengine, with a significant overhaul of the way scheduling works: github.com/pcwalton/bev... In my tests, I can now have 500+ different particle *systems*, each with many particles, on screen at once and still hit 120 FPS.

Asking ChatGPT "what is two-phase occlusion culling?" and it confidently gives the wrong answer, saying that it involves artists placing occluders manually, when a huge draw of 2-phase is that it *doesn't* require artists to do that.

It's hilarious to me that ChatGPT can now write decent Rust, but it's completely useless at doing anything but the most basic operations in ImageMagick. ImageMagick is objectively more difficult than the borrow checker

Always resist the temptation to store extra data alongside indirect draw parameters. It may seem convenient now, but you will want to support multidraw indirect eventually and then you will have to redo all your bind group management and you will hate yourself.

peekable() is nice for iterators, but usually what I really want is pushbackable(). i.e. let me use the equivalent of ungetc(), to push back a single element.

Current status: Debugging a race condition in which the easiest way to repro is "put my laptop to sleep, stick it in a bag for at least 10 minutes, turn it on without A/C power, and then start the program".

wrote about some of the work i've done in the past year and what i'm hoping to accomplish next year in bevy! ✨ www.charlotte.fyi/posts/bevys-...

What's the origin of the name "rib" for a lexical environment? I believe it's Scheme, based on finding the name inside some Chez Scheme source in Racket and googling bringing up www.khoury.northeastern.edu/home/will/Tw... -- but I'm not sure *why* Scheme chose that name.

In WGSL: * There is neither ternary operator nor expression if/else. Strike 1. * The replacement, select(), evaluates eagerly. Strike 2. * select() arguments are in the *opposite* order of the ternary. Yes, that means the else branch precedes the if branch. Strike 3, you're out.

Every `EXPRS ::== EXPR | EXPRS ',' EXPR` production in any language ever should be considered a bug. Trailing commas should be allowed everywhere!

Hey #bevy :D It's time for your weekly #bevymergetrain, where I go over the community-reviewed #opensource PRs for the #rustlang game engine that I help maintain! Somehow, there's already 24 PRs in our backlog today: github.com/bevyengin...#bevy#bevymergetrain,#opensource#rustlangll we merge the PR, or request changes? Follow along!

Bevy really feels like it's reached a milestone where you don't have to do engine work anymore to ship something. (And I'm ridiculously excited to reveal what that "something" is, but it's gotta wait...)

One thing I've always wondered is why GCC reports undeclared identifiers only once per function. It's done this for a very long time: I remember the "Each undeclared identifier is reported only once..." message on NeXT!

I’d love it if iSH had a built-in Wayland server that exposed Stage Manager multi-window support on the iPad. It’d probably solve a good 75% of my “why is it so hard to do X random thing on iOS” problems.

Idea I have no time to implement: A RISC-V emulator for iOS, using a single jump table for every 16-bit compressed instruction. Would probably be a lot faster than iSH. 16 bits is small enough that you could inline every single instruction. (I know not all insns are compressed, but most are.)

Looking through old photos and I found this one of a whiteboard in Mozilla offices from Nov 2011. IIRC I was explaining early borrow checker designs to @dherman.dev and @pcwalton.bsky.social.

The fundamental reason I'm bullish on Rust in game dev doesn't have anything to do with (lack of) GC, or memory safety -- it's the way aliasable-xor-mutable makes it easy to multithread your game logic. Updating game objects *should* be embarrassingly parallel... 1/2

The most disqualifying thing about Zig is the semantics around aggregate assignment. github.com/ziglang/zig/... For performance, sometimes Zig doesn't copy structs on the stack, so refactoring to introduce temporaries can cause Zig to just miscompile code. It happens a lot and still isn't fixed.

And they say that comptime is better than generics.

Sometimes I wonder whether people who say that Rust gamedev will never be able to compete with Unity because of slow compiles have ever used Unity. Domain reloads in Mono are agonizingly slow.

Today's fun bug: Diagnosing an error in a popular software package that will remain nameless and compiles to C++ that goes away if you use -fstrict-aliasing. Don't. Compile. To. C.

And now directional light support added. Hardest part was actually just figuring out units. Bevy uses illuminance (lux) for directional lights, but I need it in luminance (just convincing myself that this was true took a long while). The conversion process is a little tricky (thread below).

All this chatter about how Rust is supposedly bad for game development is the exact same chatter I used to read about how Rust is bad for server-side apps, or desktop apps, or OS kernels, or libraries to be called from C, etc. etc. 1/2

The only thing that GC buys you for scene graph objects is memory safety (which you can get in other ways, e.g. generational indices). It doesn't simplify the memory management. Holding on to the memory of an object in your scene that's been despawned is not what you want. 1/2

LLVM should exploit undefined behavior more. It's a pure win for memory-safe languages like Rust. (Before you mention unsafe, we can specify the semantics around those blocks specifically to make them "friendlier". But for safe code, the compiler should go nuts.)

Man, I try to use ChatGPT for easy programming tasks on systems with poor documentation, but when it hallucinates APIs that don't exist it's *deeply* frustrating and costs me more time than it would have if I had just searched through the docs.

super exited for this release! ✨ this cycle, i worked on the following features covered in the release notes:

I wrote much of the GPU-driven rendering code for this release. In general I'm really happy with the rendering performance of the engine now. Great to see this finally out!

Three constants: death, taxes, and working around Android GPU driver bugs github.com/bevyengine/b...

Hot take: The existence and ubiquity of Cargo is just as consequential, if not more so, to real-world productivity vs. C/C++ than anything regarding Rust's type system or borrow check. The former isn't nearly as fun to argue about on message boards, though.

New article on my Nanite-like renderer in Bevy engine! Get excited for Bevy 0.16 releasing soon! jms55.github.io/posts/2025-0... bevyengine.org

My favorite piece of language syntax ever is AppleScript’s “round as taught in school” developer.apple.com/library/arch...

It's annoying to see people argue "well, you could just add a static analysis for X to language Y" when people ask "how do you enforce invariant X" when language Y isn't type/memory safe. No, obviously not! It's not memory safe! That means you can't soundly analyze anything!

Trying to create a solution for safe memory management in programming languages that doesn't put any restrictions on what you can do with pointers and has no runtime overhead is as impossible as trying to come up with a pair of even numbers whose sum is odd. Sometimes things just can't be done!

Bevy 0.16 has a GPU driven rendering path now, enabled by default on platforms where it's supported! It uses bindless resources and multi-draw indirect to hugely reduce drawcalls. GPU 2-phase occlusion culling is supported. CPU overhead is minimized by aggressively retaining objects on GPU.