Programming languages and graphics person. @pcwalton.bsky.social
San Francisco, CA
Joined November 2009
- Tweets12.9K
- Following515
- Followers17.7K
- Likes6.1K
Landed multi-draw-indirect and bindless textures in Bevy 0.16! It cuts our CPU overhead for drawing in half on many scenes, and along with the retained render-world scene graph I also landed it brings us significantly closer to GPU-driven rendering.
Learned the other day: On GPU, inverse trigonometric functions are way more expensive than regular trigonometric functions. But on CPU, they're about the same speed (source: llvm.org/devmtg/2022-11/slid…)
One thing that would make Rust compiles faster in many cases is for Cargo to insta-kill any rust-analyzer processes when you run cargo build. That "Blocking" message wastes a lot of time.
Sorry, but at this point if you think Bevy's ECS is a burden for app logic I just don't believe you. You have to organize your code somehow. The question is whether the framework helps you do it or not.
Bevy 0.15 is out :) This time around, I wrote animation masks, additive blending, most of the Bevy Remote Protocol, chromatic aberration, point light and spot lights for volumetric fog, and PCSS.
Bevy 0.15 is out now! It features Required Components, Entity Picking, Generalized Entity Animation, Animation Masks, Curves, Function reflection, Bevy Remote Protocol, VBAO, OIT, Chromatic Aberration, Fog volumes, Better Text, and more!
bevyengine.org/news/bevy-0-1…
Idly wondering if Objective-C/Swift have precise enough reachability information to try running a Bacon cycle collector if memory is running low.
Wanted: a `#[derive_fast_hash]` that gives you a fast hash and compare implementation that goes as many bytes as it can at a time, for types with no padding anywhere (the macro would guarantee this somehow).
The iOS ecosystem has gotten so close to having true JIT support on iOS that I'm not sure that the delta between all the workarounds and true JIT support is that meaningful anymore. You can already JIT in wasm or JS, or you can interpret, or you can get a JIT entitlement...
Really interesting deep dive into virtual geometry (Nanite) in Bevy 0.15: jms55.github.io/posts/2024-1…
FYI I'll be posting future updates over there in addition to here: bsky.app/profile/pcwalton.bs…
Like everyone, I'd like to reduce my time on the hellsite.
A lot of C++/Rust malloc overhead comes from the loosely coupled malloc(size_t) interface. For example, the allocator has to compute which bin to use at runtime, when most of the time the compiler knows the size and could precompute the bin offset.
Also consider malloc logging/tracing features. Very convenient! But it adds a runtime check on every allocation. When your point of comparison is ~5 instructions as in the JVM, those tiny branches add up.
Honestly, I feel like programmers are way too quick to assume that "allocation" = "slow" is an iron law of the universe. In the JVM it's like 5 instructions.
The problem with C++/Rust allocators is that they're tuned to the workloads they observe in programs... (1/2)
The biggest problem with the Rust ecosystem is that everyone keeps using Fira Sans instead of a font that looks good
I didn't expect increased unification of the Windows and Unix development experience to be a side effect of Rust's success, but it's a very nice one. The fact that tools like Nushell and ripgrep are cross-platform makes switching between Win/Mac/Linux much more seamless.
Defer has three problems:
(1) it's function scoped, which is just a bug that should have been fixed;
(2) you can forget to call it and leak stuff;
(3) defer can be implemented on top of destructors, so why not just implement destructors?
On why defer over destructors is the wrong trade-off:
TL;DR defer has real advantages, but they affect a minority of actual use cases. 99% of the time, automagic recursive Drop is what I want.
xitter.cf/LinaAsahi/status/18469…
Every longtime Rust dev has a "I wish they had listened to me back then" hobby horse. Mine is that I had advocated for rustfmt to be less tied to the AST so it would be better at formatting syntactically-incorrect code. I should have argued more forcefully.