pcwalton.bsky.social
Programming languages and graphics person. Rust compiler developer, Firefox hacker, Bevy contributor.
89 posts
2,340 followers
30 following
Regular Contributor
Active Commenter
comment in response to
post
X11 over VNC is pretty usable in iSH on an M4 iPad Pro…
comment in response to
post
I’m actually not sure which behavior I prefer—just thought it was interesting as I’m not aware of any other compiler that does that. I only mentioned NeXT because it’s old :)
comment in response to
post
Maybe, maybe not! Those M4 chips are pretty powerful.
comment in response to
post
Also something I realized: AArch64 has a scaled base + index addressing mode, so the lookup and branch in the compressed instruction case is 3 instructions. godbolt.org/z/nnWKcPcWc
comment in response to
post
Something else I realized: The upper 16 bits of RISC-V instructions are quite regular (identical for all instructions of a given “type”), so for the 32-bit instructions you could do two jump tables. Jump on low 16 for opcode, jump on high 16 to load regs, return and do operation, next insn.
comment in response to
post
IIRC there are also fancier ones called CFA1 and CFA2. All of these are conservative, so they guarantee that, for every indirect call site, the called function will be a member of the set the algorithm produces.
comment in response to
post
There’s a whole literature you can raid from the academic FP community about how to soundly narrow down the set of functions that an indirect call could branch to. Olin Shivers created a family of algorithms called k-CFA where you can tune analysis time vs. precision. It’s pretty neat.
comment in response to
post
But Bevy does support dynamic libraries! There’s a tutorial in the documentation.
comment in response to
post
Have you considered something like k-CFA for allowing some subset of higher-order functions?
comment in response to
post
How do you deal with higher order functions? Just forbid them?
comment in response to
post
Yeah, by "hard crash" I mean defined process abort
comment in response to
post
I mean, if you can hard crash at any time, what good is guaranteeing that you don't panic
comment in response to
post
You can't really guarantee no-panic anyway because of stack overflow.
comment in response to
post
Once Bevy is more mature I don't think the iteration times are going to be appreciably slower. The competition is Unity, which has agonizingly slow "Reloading Domain" times, and Unreal, which is C++.
comment in response to
post
I'm not interested in using or contributing to a language that has no intentions of becoming memory safe. The more popular Zig gets, the less secure the industry gets.
comment in response to
post
Vector on consoles are basically the same throughput as consumer grade CPUs I think. There have been several attempts at making SIMD code look like scalar code in Rust, but none that I know of that are ubiquitous. Autovectorization is hard animation because you have to go AoSoA.
comment in response to
post
Animators are *really* happy in my experience when they hear how many bones we can efficiently animate, thanks to the performance that pervasive multithreading gets you.
comment in response to
post
... but few do it, because multithreading is such a minefield in most languages. I don't see a feasible solution other than compiler-enforced thread safety. For that, Rust and Swift are the only games in town as far as I can see, and Bevy gives Rust a big lead. 2/2
comment in response to
post
Not sure, but that's weird that they say they want to use function purity as a way to determine the semantics? The usual way you would do this would just be to always copy semantically and then have a MemCpyOpt like pass that cleans up unneeded copies. This is more precise than function purity.
comment in response to
post
The moment I realized Zig was unserious is when they claimed they were going to prevent stack overflows with static reachability analysis. They're not even at the point of being able to argue about whether to use e.g. k-CFA--they don't even understand the problem domain yet.
comment in response to
post
Ugh, I didn't realize it was that bad.
The struct parameter passing thing is a complete blocker for shipping things in Zig. The compiler is just broken. And I assume they aren't fixing it because they don't want to regress performance.
comment in response to
post
Every sufficiently advanced template system contains an ad-hoc, bug-ridden, slow implementation of half of a proper generics system
comment in response to
post
I'm not super familiar with it, honestly. I would note that Bevy has a huge head start at this point, though.
comment in response to
post
I wouldn't be surprised if there's some hypothetical language that's better at solving the problems of scalable multithreaded game dev than Rust, because as you correctly point out manual memory management is a burden, but sadly there doesn't seem to be any work in this area. Zig and Jai aren't it.
comment in response to
post
I mean, I've tried to come up with potential solutions, and I really can't, other than "test orderings and fix races manually" (what you do in Unity DOTS), which isn't a very attractive option when there's an alternative that lets you just not have to worry about it.
comment in response to
post
I used to agree with this re. games, but I realized over the past couple of years that the ubiquity of multicore complicates this a lot. I don't see a way to multithread game logic in a scalable way without aliasable-xor-mutable, and Rust is kind of the only game in town for that right now.
comment in response to
post
"But but what about old HP-UX systems from 1994 that I've never seen but according to Wikipedia only have C compilers and no LLVM por"-- No. Stop. Don't compile to C.
comment in response to
post
Perhaps bootstrapping a build with rust-analyzer's work if it's running? If you're running VS Code in the background, rust-analyzer has already done the typechecking and is holding that data in memory, might as well reuse it instead of having to do it again when you cargo build
comment in response to
post
My feeling is that rustc has had so much performance work done on it that we need radical solutions in order to really move the needle, e.g. JIT compilation
comment in response to
post
Nobody believes me here; maybe I should take measurements sometime to show it. It's always puzzled me that Unity devs aren't up in arms about how slow compilation and domain reload is in that engine!
comment in response to
post
Have you dealt with "Reloading Domain" in Unity? It's about the same, honestly.
comment in response to
post
This one is legitimate and I complain upstream about it a lot (and get flak in GitHub issues for it) :)
But it also doesn't have much to do with Rust--and besides, Bevy has very big blaring warnings about its instability.
comment in response to
post
You may say "well then, prove it", and I would... if not for NDAs. But stay tuned, I'm extremely excited to show it :)
comment in response to
post
In my experience, having done game dev in Rust for over a year now, there's nothing that makes that domain hard in Rust, other than the tooling (editor, etc.) just not being there yet. It's the same sort of thing people said about every other domain until Rust succeeded in each one.
comment in response to
post
And then Tiny Glade comes out and sells a ton of copies. "Ah, nevertheless!" they say.
It's always the exact same pushback. Rust clearly works in this domain, end of story. 2/2
comment in response to
post
For example, in Unity, a nominally GC'd system, you need to call Destroy on GameObjects to remove them from the scene, at which point they become dead and accessing them throws. This is just a use-after-free bug! The GC is buying you nothing for those objects (of course, it's useful in other ways).
comment in response to
post
Unless things have changed recently, all MemorySSA does is accelerate the query "is the heap at time X exactly the same as the heap at time Y?" This is very weak (presumably because alias info for the heap is so bad in C++ -- but not so in Rust!) Querying finer-grained alias info is really expensive
comment in response to
post
In particular MemorySSA is extremely underpowered compared to what it could be doing.