come see my gf @wffl@im-in.space give a cool talk tomorrow!
https://bsky.app/profile/did:plc:wbvv6voz7yecwmhzbkxm2igp/post/3mw7hsqteo22j
Remote
arya dradjica
@bal4e@tech.lgbt
mastodon 4.7.2+glitch.techlgbtProgrammer who wants to make the world a better place. Trying to help by doing what she's good at: writing efficient code for the long term.
Fascinated by compiler architecture. Well-acquainted with the low-level side of things: memory layouts, concurrent data structures, and SIMD. Privacy advocate. Interested in network protocols, OS design, and programming languages. Dabbling in number theory every once in a while. Looking for ways to bring old hardware back to life---for everyone.
Concerned about ethics. Our _individual_ choices matter.
🏳️⚧️ 🏳️🌈 
| 
Working at @nlnetlabs@social.nlnetlabs.nl on open-source Rust-based DNS software. Writing a Rust compiler (https://bal-e.org/speed/krabby) on the side.
Trying to cultivate a community of positivity and constructive knowledge-sharing. Follow requests are filtered accordingly. Mutuals: come talk to me!
I do not want to hear about "AI" or cryptocurrency.
191 Followers
124 Following
32 Posts
Joined August 19, 2024
Codeberg:
GitHub:
Website:
Pronouns:
she/her
I built my own little benchmarking system in preparation for my RustWeek talk! It's inspired by Criterion, and it can measure multiple statistics (from perf) simultaneously.
> cargo bench --bench perf -- test-data/crates.io-10k.txt
alpha: warming up...
alpha: measuring (307143488 iters)
17.63 ns/iter ± 0.69
52.69 real cycles/iter ± 2.38
53.14 ref cycles/iter ± 2.42
167.68 instructions/iter ± 3.36
0.38 LLC refs/iter ± 0.03
0.05 LLC misses/iter ± 0.01
26.28 branches/iter ± 0.40
0.50 branch mispreds/iter ± 0.07
beta: warming up...
beta: measuring (350176962 iters)
15.42 ns/iter ± 0.71
45.83 real cycles/iter ± 2.42
46.15 ref cycles/iter ± 2.48
142.52 instructions/iter ± 2.68
0.34 LLC refs/iter ± 0.03
0.05 LLC misses/iter ± 0.01
22.04 branches/iter ± 0.36
0.48 branch mispreds/iter ± 0.07
Now to apply all the optimizations I have in mind and watch these per-iter counts go down :D
An update on Krabby: There's a Zulip chat now! I wrote a little status update on the blog: https://bal-e.org/speed/krabby/hi-zulip-also-licenses/. Take a look!
Replying to
After receiving some corrections, I've updated the blog post. Exponential indeed!
#programming #rust
I might put together a bibliography of academic papers on concurrent memory reclamation. I built my own reclaimer by looking at two existing Rust crates, and not going much further; I thought there was little academic research in the field, but it turns out there are quite a few papers! I really want to compare the performance of different implementations, but FFI would complicate things significantly. I'll probably put that bibliography (perhaps with some comments, so closer to a catalog of some kind) in my repository.
Replying to
@jamey A follow-up: I tried this example in the Rust Playground and apparently it is not allowed! rustc does not allow ambiguity around meta-variables; it will only parse $e:expr if no other meta-variables or tokens can be parsed at that point. There go my hopes of getting quartic macro expansion D:
I'll continue exploring the possibilities here. I think this limitation can be handled by the packrat style I proposed, perhaps with some adjustment of cache keys.
Replying to
The first post is up! You can read about my adventures with identifier interning in 2025: https://bal-e.org/speed/krabby/interning-in-2025/
#programming #compilers #krabby
Replying to
I wish there was a nice TUI that could provide as much info as this objdump invocation, which could interactively reveal data when it's needed. perf annotate (when it works) doesn't cover --line-numbers or --inlines (AFAIK). The only relevant project I could find was https://github.com/namhyung/das but it seems to be unmaintained.
🎵 race conditions 🎵
Replying to
@folkertdev Possibly, yeah. I think an indirect branch is more suitable here because 1) it is prediction friendly (we always reach exactly the same address, every time except the first, and CPUs have been good at that for a while); 2) it scales better than conditional branches; 3) it allows for dynamically loading the code at runtime (multiversioning as a language feature should not do this, but it is an avenue I'm curious to explore).
I had forgotten about the multiversion crate; I'm going to try using it again and make sure the user experience is where I want it. I think its #[inherit_target] only works when declared inside the original function; this limitation could be resolved if this was a built-in attr. And it doesn't help parameterizing types over the feature set (which is a bit more niche, but I find myself reaching for it often).
Replying to
@folkertdev Mhm. To clarify what I meant by "ifuncs": I meant the general idea of "have an indirect function call and update the ptr on the first invocation", nothing more specific. If GCC's ifunc impl is weird (and that is what you were referring to) we can ignore it. If you had disqualified the general idea of ifuncs, I'd be curious to know why; I hope you can dig up the details. Maybe they are hard to implement portably.
Replying to
In a perfect world, we could write utility functions (and types, e.g. LookaheadBuffer or Base32Block) once across a set of SIMD feature sets, write a high-level function that ties them all together, and make copies of that function instantiated for different SIMD feature sets. Everything can be inlined into those copies of the top-level function, but not into their callers. And at any level, you can examine the current SIMD feature set and change the implementation in non-trivial ways (e.g. to use PSHUFB!).
Replying to
A silly but straightforward way to get there would be: put that function in its own Rust library, compile it with all the different feature sets you want, link to the resulting binaries, then generate an ifunc-style wrapper. You could generate dylibs and only load the needed ones; you could even merge dylibs for the same feature set across different functions. This lets you use Rust's existing cfg machinery (plus cfg_select!).
Replying to
With Rust today, you can partially approach this with generics; I have an unpublished proof-of-concept of this somewhere. Utility functions would be generic over a type describing the selected feature set. That type can only be constructed when the feature set is available on the current CPU, and this is used as a zero-sized proof object. where clauses can establish that certain features (e.g. AVX2) are available and then use their operations (through safe #[inline] functions to which you pass the proof object; they wrap unsafe #[inline] #[target_feature] impls). Your top-level function can be instantiated with different feature sets using regular generics and an ifunc can be built around them.
Replying to
The main problem I encountered with this approach was that Rust would not always inline everything; the generics, the safe functions forwarding to #[target_feature] and the necessary overhead of building a "nice" API left LLVM dissatisfied.
Furthermore, it was hard to replicate cfg! / cfg_select! in this model. I looked into type system abuse (e.g. https://docs.rs/frunk) but I didn't find a satisfying solution. auto traits (given their limited specialization capabilities) might help.
Replying to
@folkertdev This is so cool! As a fellow SIMD nerd, I'm excited to use this for feature checks, thank you for putting in the effort :3
(although I haven't made up my mind on runtime feature detection and how that should work...)
Replying to
Here's an example (heavily edited to fit the 1K limit):
19dbf: lea -0xa0(%rbp),%rdi
./benches/common/impls.rs:60
let mut interner = I::default();
19dc6: call *0x485c4(%rip) # 62390 <_DYNAMIC+0x330>
as core::cmp::PartialEq>::eq:
.../core/src/ptr/non_null.rs:1692
inlined by .../core/src/slice/iter/macros.rs:180 (...)
inlined by .../core/src/iter/adapters/map.rs:107 (...)
inlined by ./benches/common/impls.rs:62 (...)
self.as_ptr() == other.as_ptr()
19dd0: test %rsi,%rsi
as core::iter::traits::iterator::Iterator>::next:
.../core/src/slice/iter/macros.rs:180
inlined by .../core/src/iter/adapters/map.rs:107 (...)
inlined by ./benches/common/impls.rs:62 (...)
19dd3: ,--- je 1a48c
You can see the responsible function (and its source location), every place it was inlined into, and (nicely colored) jump visualizations.
Replying to
@PolyWolf I might be developing exactly the same thing, as a query system architecture for a very-very-WIP Rust compiler :3
https://codeberg.org/bal-e/krabby/pulls/19
(the PR has been on hold while I was debugging data races, which spun into developing a concurrent memory reclaimer, https://codeberg.org/bal-e/housekeeping which also had data races, but I've figured them out now)
Replying to
@kinnison@social.flarn.net Also see seize (used by papaya). I'm in the middle of building my own reclaimer (seize is too limited and crossbeam-epoch does not support MIRI) called housekeeping; it's not ready for use but it may be interesting depending on what you're doing.
I'm a little surprised that Rust/LLVM doesn't optimize away certain atomic operations. See https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=c9f0f10929e66817a7df54775eb46f52 (compile to assembly in release mode); an unused atomic load (with Relaxed or Acquire ordering) won't be elided, and an atomic swap with unused loaded value won't be downgraded to a store. I'm fairly confident that the atomic loads can be elided, but I'm willing to believe that the downgrading the RMW swap operation might affect e.g. release-acquire sequences. Perhaps these atomic operations are so rare (and usually, hopefully, done properly) that optimizing them is not worthwhile?
Replying to
@pervognsen Somebody must have made an XLS(X) frontend for GCC and I want nothing to do with it :p
Replying to
@harold I haven't taken too close a look yet, but I'm getting strong "modular inversion via Fermat's Little Theorem" vibes.
Replying to
@nicolas17 I'm a huge fan of writing concurrent data structures, especially with my own atomic variables and low-level controls. I can't imagine doing that outside Rust -- the type system provides so many helpful guides (e.g. you can build wrapper types around atomic variables with higher-level functionality, pick whether your types are Send/Sync and rely on it for soundness, and mark dangerous functions as unsafe).
Replying to
@Changaco@diaspodon.fr That's really cool! Though the Marpa homepage mentions that it can't parse all ambiguous grammars in linear time. I think rustc's macro arm language would fall outside its scope, but I don't have the time to test the implementation myself.
I see there's a paper published to arXiv; I skimmed through it but couldn't fully grasp it. I've saved it for later, thank you :D
Boosted by @joe@f.duriansoftware.com
Replying to
@joe@f.duriansoftware.com for array indices: you can offset your FPs as numbers close to infinity, offset your pointers in reverse, then increment your FPs by adding epsilons, transmute into integers and directly add them to your pointers. I don't see any problems with this, whatsoever :P
Replying to
@kinnison@social.flarn.net Do you count concurrent memory reclaimers, e.g. crossbeam-epoch?