Bit fields for everyone

2025-10-27T00:00:00+00:00

This is an edited version of the talk I gave at RustFest Zurich 2024</a>. Titled “PSA: You too can pack structs” </blockquote>
Bit fields is a way of putting data together to save memory. Not merly 10%, we are talking about dividing memory usage by 2, 10, in one personal case, it divided by 100 memory usage!
How to do it? Read on!
Here is why you would want to use bit fields:

Reduce memory usage</li>
Reduce battery usage</li>
Reduce bandwidth usage</li>
Support older and cheaper devices</li> </ul>
Why not use bit fields? Well, mostly you should use them.
Yet, it’s not widdely known. It should be, as it’s an easy solution to a lot of problems, and has been arround since the dawn of computing.
Let’s start with some code:
pub struct MeshPipelineKey { hdr: bool, tonemap_in_shader: bool, deband_dither: bool, depth_prepass: bool, normal_prepass: bool, deferred_prepass: bool, motion_vector_prepass: bool, may_discard: bool, environment_map: bool, screen_space_ambient_occlusion: bool, depth_clamp_ortho: bool, temporal_jitter: bool, morph_targets: bool, reads_view_transmission_texture: bool, lightmapped: bool, irradiance_volume: bool, blend: Blend, msaa: Msaa, primitive_topology: PrimitiveTopology, shadow_filter_method: ShadowFilterMethod, screen_space_specular_transmission: SsstQuality, view_projection: ViewProjection, tonemap_method: TonemapMethod, } </code></pre>
This is taken from the Bevy</a>1</a> game engine.
^{1
Bevy is an amazing engine. It let you write games in Rust, like pygame, but with type safety and performance. It’s open source, so no nasty license backstabs, and if the documentation is lacking in place, you just press enter in the IDE and get a direct look at the code.
</div>
In Bevy, MeshPipelineKey</code> is part of the rendering engine, it associates a mesh to a material. Each frame – so, probably 120 times per seconds – we check the material of all our meshes, a Bevy game can have from 4 meshes to 10K, even 100K meshes.
There is about a million hash and comparison per second. And MeshPipelineKey</code> is just a tinny little bit of the whole engine, and beyond the engine, we still have your whole game to run. This needs to go damn fast.
With this struct, it doesn’t go damn fast. Why? CPUs are perfect at hashing (especially with the right algorithm) and comparing, it takes a single instruction! But MeshPipelineKey</code> is 23 bytes long, and a CPU can’t compare 23 bytes in one go, it has to load this in two different registers, then keep the hash result and compare it.
This is quite fast, but it’s not enough, it’s not damn fast. What would be damn fast? Using a primitive, like u32</code>, a hash and comparison would be 1 instruction, if not less than 1!
Can we use an u32</code> instead of this large struct? In the first place, why does it take 23 bytes?}
Each field take one byte. bool</code> in Rust takes one byte, not one bit, as you could expect. This is because bool</code>s are addressable, and addresses work on bytes, not bits. Otherwise, how would you do &bool</code>?2</a>
^{2 Ok, this isn’t a good reason, since references in Rust aren’t addresses. </div> Here is how it looks in memory: The same is true for the other fields. They are all enums with a tinny number of variants. They could be encoded in as few as 2 bits. For example:}enum TonemapMethod { None = 0b000, Reinhard = 0b001, ReinhardLuminance = 0b010, AcesFitted = 0b011, Agx = 0b100, SomewhatBoringDisplayTransform = 0b101, TonyMcMapface = 0b110, BlenderFilmic = 0b111, } </code></pre> That represents 7*16=112 unused bits (ie bits we are going to hash but don’t care about). That’s about 87.5% of the struct. So many wasted bits! Can we do better than Rust here? Of course. Instead of declaring a whole struct, let’s use a u32</code>. Then, we can assign fields to one, two, or three bits. As opposed to using one byte per field. Nice visual and all, but in code, what does that look like? One way of doing it is with masks. We define a constant for each of our “field” that represents the bits we use to store the field in the u32</code>. To read a field, we have to “single out” the field from the rest of the struct, by masking with the &</code> operator. Then, if we choose carefully our representation, we have the final value. To set a field value, we need to clear the value and then set the bits with the |</code> operator. Well, this will take a couple more CPU instructions than directly loading from memory. But memory loads are already a couple of instructions, and can take hundreds if you are hitting something out of cache. In code what does that look like? #[repr(u32)] enum Blend { Opaque = 0b00 << 11, PremultipliedAlpha = 0b01 << 11, Multiply = 0b10 << 11, Alpha = 0b11 << 11, } const BLEND_MASK: u32 = 0b11 << 11; impl TryFrom<u32> for Blend { fn try_from(u32: u32) -> Result<Blend, ()> { // ... } } fn set_blend(mesh_pipeline_key: u32, blend: Blend) -> u32 { let blend_offset = blend as u32; (mesh_pipeline_key & !BLEND_MASK) | blend_offset } fn get_blend(mesh_pipeline_key: u32) -> Blend { let masked = mesh_pipeline_key & BLEND_MASK; masked.try_into().unwrap() } </code></pre> Gosh, what horror. This sure is code, but that looks dangerous and error prone3</a>. ^{3 In fact, the original code I used in the presentation contained an error that I only corrected when cleaning up for this blog post. </div> So, how does that look like in the wild? Maybe Bevy has better code quality?}Bevy uses the bitflags</a> crate, let’s see how that looks: bitflags::bitflags! { pub struct MeshPipelineKey: u32 { const HDR = 1 << 0; const TONEMAP_IN_SHADER = 1 << 1; const DEBAND_DITHER = 1 << 2; const DEPTH_PREPASS = 1 << 3; const NORMAL_PREPASS = 1 << 4; const DEFERRED_PREPASS = 1 << 5; const MOTION_VECTOR_PREPASS = 1 << 6; const MAY_DISCARD = 1 << 7; const ENVIRONMENT_MAP = 1 << 8; const SCREEN_SPACE_AMBIENT_OCCLUSION = 1 << 9; const DEPTH_CLAMP_ORTHO = 1 << 10; const TEMPORAL_JITTER = 1 << 11; const MORPH_TARGETS = 1 << 12; const READS_VIEW_TRANSMISSION_TEXTURE = 1 << 13; const LIGHTMAPPED = 1 << 14; const IRRADIANCE_VOLUME = 1 << 15; // etc. </code></pre> Starting with the boolean fields, we convert the struct into a newtype, and declare associated constants, one per field. Then, to read and write to the packed struct, we do as we did earlier, but with named constants instead of magic numbers. Here is how it looks like when reading/writing to a MeshPipelineKey</code>: let key = MeshPipelineKey::HDR | MeshPipelineKey::MAY_DISCARD | MeshPipelineKey::IRRADIANCE_VOLUME; // Note that unlike C, and other C-derived language, // operations follow the correct operator precedence. if key & MeshPipelineKey::IRRADIANCE_VOLUME == MeshPipelineKey::IRRADIANCE_VOLUME { // do irradiance volume } </code></pre> As a developer, I don’t like this code. While it is “type safe” the code doesn’t reflect what we are doing. It is ostensibly manipulating bits, or bit twiddling, but what we mean to do is not manipulating bits, but rather check a boolean value, no? In any case, we should look at how to handle enums with this. Please keep in mind that this is an anti-pattern. Do not reproduce it at home or at work, not even in the presence of a trained professional. const BLEND_RESERVED_BITS = Self::BLEND_MASK_BITS << Self::BLEND_SHIFT_BITS; const BLEND_OPAQUE = 0 << Self::BLEND_SHIFT_BITS; const BLEND_PREMULTIPLIED_ALPHA = 1 << Self::BLEND_SHIFT_BITS; const BLEND_MULTIPLY = 2 << Self::BLEND_SHIFT_BITS; const BLEND_ALPHA = 3 << Self::BLEND_SHIFT_BITS; const BLEND_MASK_BITS: u32 = 0b11; const BLEND_SHIFT_BITS: u32 = Self::PRIMITIVE_TOPOLOGY_SHIFT_BITS - Self::BLEND_MASK_BITS.count_ones(); </code></pre> For enums, we just define additional constants for each variant. We then check for the variant this way: key |= MeshPipelineKey::BLEND_MULTIPLY; if key & MeshPipelineKey::BLEND_RESERVED_BITS == MeshPipelineKey::BLEND_OPAQUE { // do opaque blend } else { // ... } </code></pre> Very similar to booleans, just checking against variants. Straightforward isn’t it? But haven’t you noticed something? First off, the BLEND_</code> prefix, very reminiscent of C enums. Second, we have lost exhaustivity check! Consider what happens when we add a new blend mode. We add a new constant, and then, of course, we should update every place that checks the value of the blend bits. But since this is an if/else, the compiler can’t remind us to do it if we forget. Furthermore, we forgot to add a bit to the mask BLEND_MASK_BITS</code>, because we now need 3 bits to encode our blend variants, and again, the compiler couldn’t help us. const BLEND_RESERVED_BITS = Self::BLEND_MASK_BITS << Self::BLEND_SHIFT_BITS; const BLEND_OPAQUE = 0 << Self::BLEND_SHIFT_BITS; const BLEND_PREMULTIPLIED_ALPHA = 1 << Self::BLEND_SHIFT_BITS; const BLEND_MULTIPLY = 2 << Self::BLEND_SHIFT_BITS; const BLEND_ALPHA = 3 << Self::BLEND_SHIFT_BITS; // vvv new variant const BLEND_ADDITIVE = 4 << Self::BLEND_SHIFT_BITS; const BLEND_MASK_BITS: u32 = 0b11; const BLEND_SHIFT_BITS: u32 = Self::PRIMITIVE_TOPOLOGY_SHIFT_BITS - Self::BLEND_MASK_BITS.count_ones(); // Then when accessing: key |= MeshPipelineKey::BLEND_MULTIPLY; if key & MeshPipelineKey::BLEND_RESERVED_BITS == MeshPipelineKey::BLEND_OPAQUE { // do opaque blend // vvv new variant check } else key & MeshPipelineKey::BLEND_RESERVED_BITS == MeshPipelineKey::BLEND_ADDITIVE { // do additive blend } else { // ... } </code></pre> I can tell you, the Bevy rendering code is littered with bit twiddling like that. And every time there is a change to the rendering code, there is a massive thousand lines diff that conflicts with everything else. It makes unanimity, ask anyone they will tell you they dislike this code. Also, personally, I found this to be extremely confusing, I had to learn (on top of learning graphics programming) what the hell was going on, and why the silly. But we finally managed to use a u32</code> for our MeshPipelineKey</code>. Our hash is indeed dang fast, in fact, it’s order of magnitudes faster. But, that was at the cost of maintainability, which we still pay to this day. Seemingly, there is a tradeoff between maintainability and performance. We got performance, but we lost: Readability, accessing a field is now a boolean operation with C-style manual namespacing</li> We lost exhaustiveness checking</li> It’s easy to forget to update field offsets and masks</li> We now depend on the bitflags</code> crate.</li> </ul> But dang! We are using the Rust programming language! What Rust did is tell us that no, we don’t have to choose between performance and maintainability, we can do both! Emphatically! Engineering is not just about making decision, it knowing about which decisions you can make. So let’s make the right decision here and use the nearly forgotten art of bit fields. I’ll be using a Rust crate called bitbybit</code>. There is a variety of bit field crates, but I choose this one because I can vouch for it, I’ve thouroughfully reviewed it. I’m being told however, that there are better crates you can use. You remember the asterisk in the “list of drawbacks” slide? There is actually a drawback here. Can you guess at it? It is an additional dependency. Still, compared to bitflags</code>, it’s just a different dependency. But you should be careful about which dependencies you use, and, like me, verify them before using them. So let’s see how it looks like with bitbybit</code>: #[bitfield(u32)] pub struct MeshPipelineKey { #[bit(0)] hdr: bool, #[bit(1)] tonemap_in_shader: bool, #[bit(2)] deband_dither: bool, #[bit(3)] depth_prepass: bool, #[bit(4)] normal_prepass: bool, #[bit(5)] deferred_prepass: bool, #[bit(6)] motion_vector_prepass: bool, #[bit(7)] may_discard: bool, #[bit(8)] environment_map: bool, #[bit(9)] screen_space_ambient_occlusion: bool, #[bit(10)] depth_clamp_ortho: bool, #[bit(11)] temporal_jitter: bool, #[bit(12)] morph_targets: bool, #[bit(13)] reads_view_transmission_texture: bool, #[bit(14)] lightmapped: bool, #[bit(15)] irradiance_volume: bool, // etc. } </code></pre> This looks very similar to the original struct declaration. Under the cover though, we are doing the exact same bit twiddling as before. In fact, the macro declares MeshPipelineKey</code> as a newtype over a u32</code>. Notice that we have an attribute #[bit(x)]</code>. Here, x</code> represents the position in the u32</code> of the field. Do we really care about where our fields go? Actually yes: Network and hardware protocols use bit fields, where the precise location of bits and their meaning is specified into an RFC or burried in dusty manuals. C has a special syntax</a> just for bit fields. But because you cannot control where each bit goes (it is implementation defined because of course everything in C is implementation defined) everybody will tell you to never use bit fields in C. Hence, this is the likely reason no one uses bit fields nowadays anymore. But here, unlike in C, we have control. How do we read and write to fields now? The fields are declared as methods on MeshPipelineKey</code>. If we were to expand the bitfield</code> macro, it would look as follow: pub struct MeshPipelineKey(u32); impl MeshPipelineKey { pub fn set_irradiance_volume(self, irradiance_volume: bool) -> Self { // ... } pub fn irradiance_volume(&self) -> bool { // ... } // etc. } </code></pre> To use them, we just call the methods: let key = MeshPipelineKey::builder() .with_irradiance_volume() // ... .build(); if key.irradiance_volume() { // do irradiance volume } </code></pre> No more bit fiddling, no more weird constants. You just access data with a getter, like the wise Java sages taught you at school. They work the way you expect them to work. What about enums? bitflags’ devious limitations were brought to light with enums, how does bitbybit handle enums? So, this is how the rest of the MeshPipelineKey</code> struct looks like: #[bitfield(u32)] pub struct MeshPipelineKey { // bits .. #[bits(16..=17)] blend: BlendMask, #[bits(18..=20)] msaa: Msaa, #[bits(21..=23)] primitive_topology: PrimitiveTopology, #[bits(24..=26)] tonemap_method: TonemapMethod, #[bits(27..=28)] shadow_filter_method: ShadowFilterMethod, // etc. } // The enum declarations: #[bitenum(u2, exhaustive = true)] enum Blend { Opaque = 0b00, PremultipliedAlpha = 0b01, Multiply = 0b10, Alpha = 0b11, } </code></pre> Instead of specifying a unique bit, we specify a range of bits. We also have to add the bitenum</code> attribute to our enums. With this, bitbybit</code> can tell you if the range is enough to hold the enum in question, and refuses to compile if not. With nice and detailed error messages at compile time and all (I would know, I wrote them). bitbybit</code> can also tell you if the target size of the struct is not enough to hold all the fields. And we access an enum field as we would expect it: key.set_blend(BlendMask::Opaque); match key.blend() { BlendMask::Opaque => { /* do opaque blend */ } // other blend modes } </code></pre> We match on an enum, that means that we still have exhaustiveness checking! OK, it’s technically less efficient. To find out why, I’ll let you scroll up to the third code listing, the one where we manually do masking, without any external crates. Notice the values of the variants of the Blend</code> enum. They are “pre-shifted”, and when comparing against the value extracted from mesh_pipeline_key</code>, we don’t do any more shifting. That’s like one less instruction. I mean, in this specific case, the compiler should be able to optimize it. The moral of the story is that (rarely, but indeed sometimes) we don’t have to chose between maintainability and performance. This time, we picked both. Don’t let yourself be blinded by false dichotomies. Remember: engineering is not just about making choices. It’s also about knowing which choices you can make. On packed representation</h2> The original talk title was “PSA: you too can pack structs”. Here, for clarity, I kept using “bit fields”. But in the literature, “packed” is often used interchangeably with “bit fields” (that wouldn’t be the first time CS has confusing naming schemes) In Rust, you might know of the #[repr(packed)]</code> attribute. It’s the weaker version of bit fields. I focused on MeshPipelineKey</code> – where packed</code> isn’t relevant – because it was a practical use case with real world application. Here is a different scenario: We are building the cheese panopticon. A database of the cheese stashes of every person on earth. We start by making a struct to represent cheese stashes: enum CheeseType { Gruyere, Vacherin, Raclette, } struct Cheese { kind: CheeseType, aged: bool, weight_kg: u64, } </code></pre> We are going to have billions of copies of Cheese</code> in memory, so better not take too much memory. Let’s see how many bytes it takes: fn main() { println!("{}", std::mem::size_of::<Cheese>()); } // -> 16 </code></pre> Sixteen! This means that Rust uses 128 bits to represent a Cheese</code> datastructure. Let’s see why. We have three fields: kind</code> is an enum with three variants, 1 byte</li> aged</code> is a boolean value, 1 byte</li> weight_kg</code> is a u64</code>, so 8 bytes</li> </ul> I count 10 bytes, so what’s up? Why is Rust wasting 6 whole bytes for my Cheese</code>?! Let me explain. You know that in Rust, a reference cannot be null. Specifically, they are always well formed. What does it take for a reference to be well formed? Can’t be null</li> Always points to valid data</li> It respects the alignment of the data type it’s pointing to.</li> Some other hooey gooey stuff that is a constant headache if you are ever to use unsafe</code>.</li> </ul> So what’s alignment? In short, some machine instructions only work (or are much faster) if the address of an integer it’s loading is a multiple of 1, 2, 4, 8, 16 etc. That address coefficient is what we call “alignment”. If you have ever written C code for ARM devices, you might have encountered a mysterious “Bus Error”. It comes from alignment. All Rust types have an alignment. For u8</code>, it’s 1, for u16</code> 2, u32</code> 4 and u64</code> 8. (same as its size). When it comes to composite types (ie: struct), the size of the composite must be divisible by all it’s component type’s alignment. In particular, since all alignments are power of two, it just needs to be divisible by its highest component’s alignment. And its alignment will be that. In the case of Cheese</code>, weight_kg: u64</code> has an alignment of 8. So Cheese</code>, which contains weight_kg</code>, must itself have a size that is divisible by 8. 10 is not divisible by 8, the next best one is 16. So Rust adds 6 bytes of padding to each instace of the Cheese</code> struct. Padding is just blank data that has no purpose (in fact, reading it is undefined behavior). Thanks to this, when your struct is in an array, its fields will always be aligned (ie: you can create valid references to them that won’t trigger bus errors (which are very similar to segmentation faults in term of fun to debug)) In Rust, #[repr(packed)]</code> allows you eliminate padding: #[repr(packed)] struct Cheese { kind: CheeseType, aged: bool, weight_kg: u64, } // -> size: 10 bytes </code></pre> But that does mean that we lose alignment. Since it’s undefined behavior to read from unaligned memory, we actually can’t create references to weight_kg</code> in Cheese</code>, &cheese.weight_kg</code> is a compiler error. When the struct is not packed, we have this: With the #[repr(packed)]</code> attributes, we have the following: So, indeed, #[repr(packed)]</code> can drastically reduce memory usage! Instead of storing 8 Example</code> in our array, we stored 10. You’ll notice that bitbybit</code> requires a backing storage type. We used u32</code>. But imagine just a second that your data fits perfectly in 33 bits. Would you need to use a u64</code>? There is no padding, but that’s still a lot of wasted memory. Some bit field crates allow using arrays as backing storage, making it possible to have – for example – [u8; 5]</code> as backing storage. That minimizes memory usage, at the cost of slightly more complex generated code.

Optimizing the day 6 Advent of Code 2022 challenge a little too much

2022-12-06T00:00:00+00:00

WARNING: Spoilers ahead for the thing mentioned in the title.

Today’s (2022-12-06) AOC (Advent of Code</a>) was easier than yesterday’s if you have been doing it in rust.

You basically just have to implement code that finds the ending index of the first sequence of N bytes in a given input where no two bytes are the same.

It is relatively trivial to do in rust. Here is my initial implementation.

fn </span>all_distinct</span><T: Clone </span>+ </span>Ord>(</span>slice</span>: </span>&</span>[T]) -> </span>bool </span>{
</span>    </span>let mut</span> slice_copy </span>=</span> slice.</span>to_vec</span>();
</span>    slice_copy.</span>sort_unstable</span>();
</span>    slice_copy.</span>windows</span>(</span>2</span>).</span>all</span>(|</span>pair</span>| pair[</span>0</span>] </span>!=</span> pair[</span>1</span>])
</span>}
</span>fn </span>first_unique</span><T: Clone </span>+ </span>Ord>(
</span>    </span>datastream</span>: </span>&</span>[T],
</span>    </span>required_distinct</span>: </span>usize
</span>) -> Option<</span>usize</span>> {
</span>    datastream
</span>        .</span>windows</span>(required_distinct)
</span>        .</span>enumerate</span>()
</span>        .</span>find_map</span>(|(</span>i</span>, </span>slice</span>)| </span>all_distinct</span>(slice).</span>then_some</span>(i </span>+</span> required_distinct))
</span>}
</span>fn </span>main</span>() {
</span>    </span>let</span> input </span>= </span>std::io::stdin().</span>lines</span>().</span>next</span>().</span>unwrap</span>().</span>unwrap</span>().</span>into_bytes</span>();
</span>    </span>let</span> output </span>= </span>first_unique</span>(</span>&</span>input, </span>4</span>).</span>unwrap</span>();
</span>    println!(</span>"</span>{output}</span>"</span>);
</span>}
</span></code></pre>
ez-pz </p>
Could have ended here, but as your scrollbar may hint, that wasn’t accounting
for @Toby</code> on the bevy discord
implementing a benchmarking suite to compare the performance of each
solutions people posted in the #off-topic</code> channel.</p>
From now on I’ll refer to required_distinct</code> by W</code>. I’ll also refer to the
input length by N</code>.</p>
solution name</th> runtime (ns)</th> W</code></th></tr></thead>

hashet</td> 244,760</td> 4</td></tr>
manevillef</td> 242,403</td> 4</td></tr>
nicopap</strong></td> 123,600</strong></td> 4</strong></td></tr>
snaketwix</td> 50,000</td> 4</td></tr>
vec</td> 153,107</td> 4</td></tr>
–––––––</td> </td> </td></tr>
hashet</td> 1,792,000</td> 14</td></tr>
manevillef</td> 1,239,000</td> 14</td></tr>
nicopap</strong></td> 699,000</strong></td> 14</strong></td></tr>
snaketwix</td> 106,000</td> 14</td></tr>
vec</td> 1,764,677</td> 14</td></tr>
</tbody></table>
I’m fairing pretty well for an a priori</em> very naive implementation
optimized for readability.
But snaketwix</code> clearly has the lead. The reason is that, unlike all the other
Solutions, they only iterates over the input once. They have a VecDeque</code> to keep
track of already seen characters and dropping them when they go out of the
window. So their solution has a complexity of O(N)</code>.</p>
My solution uses
windows(required_distinct)</code> and does an operation per element of that window
(both a sort_unstable</code> and a linear adjacent element comparison). It also
allocates a whole Vec</code> per stream element, going to a complexity of
O(N * (W + W * log(W))) = O(N * W * log(W))</code>. This is clearly visible when W</code>
is increased in the benchmarks.</p>
First optimization</h2>
Suddenly invaded by a Zachtronician sense of optimization, I decided to
go down the rabbit hole.</p>
Allocation is a well known source of slowdown. Especially if recurrent. Each
new allocation can put the allocated data at widely different position in
memory. When reading that data, it might evict the CPU cache and result in a
few thousands cycles of slowdown.</p>
I decided to “hoist” (aka moving outside of a loop) the Vec</code> allocated in
all_distinct</code>. Since I call all_distinct</code> in a loop, I must now accept the
Vec</code> as a function parameter, I’ll just initialize the Vec</code> in
first_unique</code>.</p>
// Now we have a &mut Vec<T> as parameter    vvvvvvvvvvvvvvvvvvvvvvvv
</span>fn </span>all_distinct</span><T: Clone </span>+ </span>Ord>(</span>slice</span>: </span>&</span>[T], </span>collect_vec</span>: </span>&mut </span>Vec<T>) -> </span>bool </span>{
</span>    </span>// `Vec::clear` removes all elements while keeping the pre-existing capacity.
</span>    </span>// Perfect, since `slice` will always have the same length.
</span>    collect_vec.</span>clear</span>();
</span>    slice.</span>clone_into</span>(collect_vec);
</span>    collect_vec.</span>sort_unstable</span>();
</span>    collect_vec.</span>windows</span>(</span>2</span>).</span>all</span>(|</span>pair</span>| pair[</span>0</span>] </span>!=</span> pair[</span>1</span>])
</span>}
</span>fn </span>first_unique</span><T: Clone </span>+ </span>Ord>(
</span>    </span>datastream</span>: </span>&</span>[T],
</span>    </span>required_distinct</span>: </span>usize
</span>) -> Option<</span>usize</span>> {
</span>    </span>// The Vec is initialized here, outside of the find_map, before we iterate.
</span>    </span>let mut</span> collect_vec </span>= </span>Vec::with_capacity(required_distinct);
</span>    datastream
</span>        .</span>windows</span>(required_distinct)
</span>        .</span>enumerate</span>()
</span>        .</span>find_map</span>(|(</span>i</span>, </span>slice</span>)| {
</span>            </span>// must pass it as argument vvvvvvvv
</span>            </span>all_distinct</span>(slice, </span>&mut</span> collect_vec).</span>then_some</span>(i </span>+</span> required_distinct)
</span>        })
</span>}
</span>fn </span>main</span>() {
</span>    </span>let</span> input </span>= </span>std::io::stdin().</span>lines</span>().</span>next</span>().</span>unwrap</span>().</span>unwrap</span>().</span>into_bytes</span>();
</span>    </span>let</span> output </span>= </span>first_unique</span>(</span>&</span>input, </span>4</span>).</span>unwrap</span>();
</span>    println!(</span>"</span>{output}</span>"</span>);
</span>}
</span></code></pre>
solution name</th> runtime (ns)</th> W</code></th></tr></thead>

hashet</td> 344,420</td> 4</td></tr>
manevillef</td> 338,375</td> 4</td></tr>
nicopap</td> 166,605</td> 4</td></tr>
nicopap_hoist</strong></td> 6,410</strong></td> 4</strong></td></tr>
snaketwix</td> 59,685</td> 4</td></tr>
vec</td> 212,330</td> 4</td></tr>
–––––––</td> </td> </td></tr>
hashet</td> 2,126,025</td> 14</td></tr>
manevillef</td> 1,654,485</td> 14</td></tr>
nicopap</td> 931,946</td> 14</td></tr>
nicopap_hoist</strong></td> 618,202</strong></td> 14</strong></td></tr>
snaketwix</td> 130,358</td> 14</td></tr>
vec</td> 2,406,825</td> 14</td></tr>
</tbody></table>
(yep, that’s a 26× speedup on W</code> = 4)</p>
Notice that nicopap_hoist</code> is two times faster than the snaketwix</code> solution
on W</code> = 4. This may be because their solution rely heavily on HashMap</code> and
inserting/popping from a VecDeque</code>. For small W</code>, the overhead of the
HashMap</code> is greater than the additional operations of an  O(N * W * log(W))</code>
impl with no overhead otherwise.</p>
Now the question of why we got a 27 times speedup</strong> for W</code> = 4, while only
having a 1.5 speedup for W</code> = 14. I actually have no idea.
It might be that allocating a Vec</code> is as slow as W</code> = 7.</p>
Removing such overhead would indeed result in about 6 times speedup on very
small W</code> and <2</code> speedups on larger W</code>. There might be other optimizations
kicking in, but I wouldn’t be able to name them.</p>
Second Optimization</h2>
snaketwix</code>’s solution has a O(N)</code> complexity. Could we reach such complexity
level without what seems like overhead introduced by HashMap</code>? Answer is: nay.
But yet we can do better.</p>
We have one major issue with our implementation: Sorting each windows. This
represents a significant computing cost, repeated N</code> times. Especially since
we have to copy the whole slice to our Vec</code> (even if pre-allocated) each time
in addition to sorting it.</p>
Why are we sorting? Simply put: we want to detect duplicates. There is of
course better ways to detect duplicates.</p>
A set</h3>
Most notably, we could – instead of copying each element to a new Vec</code>,
sorting them, and then comparing them pair-wise – just, you know, add them one
after the others to a sort of set, and check each time if it is already in the
set. This already reduces the time complexity of our stuff from O(N * W * log(W))</code>
to O(N * W)</code>!</p>
But as you might have noticed, it’s a pretty bad idea. All those solutions that
are about twice slower than my implementation do exactly this.</p>
Why are they
slower if they have a lower complexity? Simply put, O</code> (big O notation, what I
have been referring to as “complexity”) is a limit</em>, this means that for small
values of N</code> and W</code>, complexity is not a good indicator of runtime. Most of
the time other constant overhead are so great that the complexity start to
be useful to have an idea of runtime only after the variables in the expression
are greater than a hundred thousands. For some algorithms</a> constant overhead
can be so great that the big O notation is only good as a purely theoretical
construct.</p>
In this particular case, the “better” solutions are slower because they use
HashSet</code> (or HashMap</code>). Hashing is indeed a constant time operation, but it’s
fairly costly. On top of that, they add a level of indirection that might kill
somewhat cache coherency again. This makes using the rust standard library
impractical.</p>
So what alternative do we have? Well…</p>
When doing some improvements to the bevy game engine, I came across bitsets</a></strong>.
It’s a cool</em> data structure where an individual element can be represented as a
single bit. We can then check the bit for set ownership.</p>
Our input is explicitly only single letters from the alphabet. So to encode a
set of input elements, we only need a total of 26 bits! Hell, this means we
could simply encode a bitset as a u32</code>! (Has 32 > 26 bits)</p>
struct </span>AlphabetSet(</span>u32</span>);
</span>impl </span>AlphabetSet {
</span>    </span>const fn </span>new</span>() -> </span>Self </span>{
</span>        </span>Self</span>(</span>0</span>)
</span>    }
</span>    </span>/// Add letter to set, return `true` if it is already part of it.
</span>    </span>/// `symbol` must be an ascii latin alphabet letter.
</span>    </span>fn </span>add_letter_or_contains</span>(</span>&mut </span>self</span>, </span>symbol</span>: </span>u8</span>) -> </span>bool </span>{
</span>        </span>let</span> to_set </span>= </span>1 </span><< </span>(symbol.</span>wrapping_sub</span>(</span>b</span>'a'</span>) </span>as u32</span>);
</span>        </span>let</span> already_set </span>= </span>self</span>.</span>0 </span>&</span> to_set </span>==</span> to_set;
</span>        </span>self</span>.</span>0 </span>|=</span> to_set;
</span>        already_set
</span>    }
</span>}
</span></code></pre>
It’s not rocket science, and it’s very efficient. I’ve even used bitsets for
my GBA game</a>.</p>
In that snippet, I subtract from symbol</code> (the alphabet character from the
input) the u8</code> value of a</code> (so that the value of alphabet letters are in
[0..26]), and then I “add it to
the set” by setting the bit in the “set” (our u32</code>) that corresponds to our
letter to 1</code> (self.0 |= 1 << [alphabet_index]</code>).</p>
fn </span>all_distinct</span>(</span>slice</span>: </span>&</span>[</span>u8</span>]) -> </span>bool </span>{
</span>    </span>let mut</span> set </span>= </span>AlphabetSet::new();
</span>    </span>!</span>slice
</span>        .</span>iter</span>()
</span>        .</span>any</span>(|</span>letter</span>| set.</span>add_letter_or_contains</span>(</span>*</span>letter))
</span>}
</span>// sop stands for "start of packet"
</span>fn </span>first_sop</span><</span>const</span> W: </span>usize</span>>(</span>datastream</span>: </span>&</span>[</span>u8</span>]) -> Option<</span>usize</span>> {
</span>    datastream
</span>        .array_windows::<W>()
</span>        .</span>enumerate</span>()
</span>        .</span>find_map</span>(|(</span>i</span>, </span>slice</span>)| </span>all_distinct</span>(slice).</span>then_some</span>(i </span>+</span> W))
</span>}
</span>fn </span>main</span>() {
</span>    </span>let</span> input </span>= </span>stdin</span>().</span>lines</span>().</span>next</span>().</span>unwrap</span>().</span>unwrap</span>().</span>into_bytes</span>();
</span>    </span>let</span> output </span>= </span>first_sop::<14>(</span>&</span>input).</span>unwrap</span>();
</span>    println!(</span>"</span>{output}</span>"</span>);
</span>}
</span></code></pre>
(I also swapped to use array_windows</code> over windows</code>, for exoticism, since
windows</code> will definitively generate the same final assembly)</p>
Then we just need to replace the all_distinct</code> function to use the
AlphabetSet</code>. Specifically, we return from add_letter_or_contains</code> a bool
telling if the letter was already encountered.</p>
That’s it. It’s still O(N * W)</code>, but W</code> here grow by about 5 CPU cycle per
W</code>, so unlike the hoist solution (which still was relatively light on CPU cycle growth per W</code>,
I’d say 100 or so) there shouldn’t be a drastic difference between relatively
close values of W</code>. To rephrase: This means the runtime of the solution should
grow still linearly but much slower than with hoist. Maybe so little that we’ll
beat more theoretically efficient solutions
(since we are talking about close to 0 overhead here).</p>
Now let’s see our benchmarks…</p>
solution name</th> runtime (ns)</th> W</code></th></tr></thead>

hashet</td> 344,360</td> 4</td></tr>
manevillef_2</td> 169,767</td> 4</td></tr>
nicopap</td> 158,936</td> 4</td></tr>
nicopap_hoist</td> 6,527</td> 4</td></tr>
nicopap_bitset</strong></td> 5,197</strong></td> 4</strong></td></tr>
snaketwix</td> 58,178</td> 4</td></tr>
vec</td> 113,473</td> 4</td></tr>
–––––––</td> </td> </td></tr>
hashet</td> 2,144,092</td> 14</td></tr>
manevillef_2</td> 1,085,112</td> 14</td></tr>
nicopap</td> 919,232</td> 14</td></tr>
nicopap_hoist</td> 623,370</td> 14</td></tr>
nicopap_bitset</strong></td> 24,871</strong></td> 14</strong></td></tr>
snaketwix</td> 118,899</td> 14</td></tr>
vec</td> 2,141,100</td> 14</td></tr>
</tbody></table>
Outrageously fast!</strong></p>
Going further</h2>
I didn’t explore faster possibilities, but @Verte</code> proposed an interesting
solution, very similar to mine. Instead of using
!windows.any([add_or_contains])</code>, they simply Add all</strong> the letters from the
window to the bitset and count how many bits are set (this can be done in a single
instruction with u32::count_ones</code>) If the number of bits is equal to the
number of elements, it means all the elements are unique!</p>
This is pretty good, and possibly more efficient than my solution. In my case,
I early exit as soon as a duplicate is found. This translates in the generated
assembly by a single jump instruction after each comparison. Due to branch
prediction and pipeline invalidation, Verte’s solution might really be better.</p>
The CPU has an instruction pipeline, it preloads the next few instructions it
will execute. Problem is that when encountering a conditional jump instruction,
the next few instructions become unknown since it’s impossible to know the
value of the predicate before evaluating it. So if it didn’t load the correct
instructions, it will need to clear the pipeline and reload the next
instructions, causing a stall</em> of a few cycles to a few hundred cycles
depending on the context.</p>
Just unconditionally adding up all the letters to the bit set, then acting on
it fixes that problem, and enables the potential for vectorization (aka
automatic SIMD instructions)</p>
I didn’t test it yet, but I could expect a 4× speedup.</p>


Warlock's Gambit trace analysis
2022-09-01T00:00:00+00:00
I did some analysis on the traces of warlock’s gambit.</p>
I captured traces both using Chromium’s dev tools and bevy’s trace_chrome</code>
features. I usually use the trace_tracy</code> feature, and run tracy</a>, but
this time, for the benefit of a potential employer (and my curiosity),
I decided to try out the chrome version.</p>
Sadly, the trace as captured by chrome in the WASM stack do not help much.</p>
The rust symbols show up, but bevy relies heavily on type erasure both for
performance and ergonomics.</p>
Specifically the game systems are added to a scheduler as an erased function,
and ran each frame. Using the argument types of the function, the scheduler
knows which systems touches which components, and only runs in parallel
systems that do not touch mutably the same components. This allows automatic
concurrency, but at the cost of decoupling the running of game systems from
their declaration, thus losing a lot of “free” debugging tools.</p>
However, bevy smartly sets up custom tracing events, actually associating
the system ran with the name of the function of the system. Bevy uses the
tracing-wasm</code> crate for tracing on wasm, sadly, I didn’t manage to get
it working. It seems chrome has difficulties properly understanding the
trace event hierarchy.</p>
Follows the tracing files for native and chrome telemetry:</p>
Both traces are in the chrome tracing format, so they work in the same tools.</p>
I’ve been recommended to use https://ui.perfetto.dev/</a> to inspect chrome traces,
but I fond in the chromium dev website  https://speedscope.app</a> and I find it
much better. The sandwich view makes understanding what takes most time a piece
of cake (or sandwich as the name would have it).</p>
speedscope has three views accessible through the top left bar:</p>

Time order (the classical trace view)</li>
Left heavy (shows to the left the longest spans)</li>
Sandwich (show as list, allowing you to order by “self” time or total run time)</li>
</ul>
“self” time is the time a span ran minus inner span runtime. </p>
fn fun1() {
</span>    takes_a_lot_of_time();
</span>    span2();
</span>    span3();
</span>}
</span>fn fun2() {
</span>    span2();
</span>    span3();
</span>}
</span></code></pre>
Here, fun2</code> does no work beside calling other functions with spans, meaning its
self time is very low. While fun1</code> will have a long self time. Self time tells
you which function to optimize.</p>
I recommend you get familiar with the sandwich view, because it is the fastest
way to figure out what is slowing down your app.</p>
Following is the “left heavy” view in speedscope.app for warlock’s traces.
Click on the heading to download the file.</p>
native traces</a></h4>


</div>
chrome traces</a></h4>


</div>
Analysis</h4>
The native trace will take about 5 minutes to open on https://speedscope.app</a>,
but here is what I can get out of it:</p>


Notice that 30% of runtime is prepare_systems</code> self time! It’s the method
responsible for reading systems access types and scheduling them according
to their declared dependency and mutual exclusivity (exclusive writes etc.)
That time is completely unreasonable, and planned for removal with the
new scheduler rewrite.</p>
But this doesn’t concern wasm at all! Since wasm is single-threaded,
prepare_systems</code> is simply skipped, since everything is sequential anyway.
This implies that the WASM version is potentially faster than the native version</p>
Furthermore, I’m personally offended how bevy handles scheduling. The system
list is static since the first frame, yet, the dependency calculation is ran
every frame. In addition, the graph building code is very inelegant, and
naturally O(n²), n</code> being the system count. This is especially damning
in the render extract stage where about a hundred systems are scheduled.</p>
</li>

The second most expensive code seems to be rendering. Inspecting the chrome
trace, it seems most time is spent queuing GPU commands. It is probably that
bevy could minimize that, given that we have at most 30 sprites on screen here. </p>
</li>

The third most expensive function finally seems to be the lighting extraction
method. There is no lights and all materials are unlit, I’m really not sure
what bevy is doing there.</p>
</li>

The systems warlock’s gambit has control over are difficult to catch,
especially since the names are mangled, even using bevy’s tracing feature,
due to usage of states, which are also due to be replaced. You can find some
in the CoreStage::Update</code> span.</p>
One of our dependencies, used to select cards with ray casting, is visible
in CoreStage::First</code>, but you can see that compared to bevy’s overhead, its
impact is minimal</p>
</li>
</ul>
With this insight, I’ll probably be able to help optimize bevy a little bit.
I won’t touch the scheduling, since it is currently being rewritten. But it
seems some low hanging fruits are:</p>

check_visibility</code></li>
prepare_lights</code></li>
prepare_windows</code></li>
</ul>


Can't we do better than the current dev workflow?
2022-07-24T00:00:00+00:00
CI sucks.
Tests take forever,
fail spuriously or magically starts to fail in new and amusing ways,
it requires constant attention, even more than an baby breastfed with prunes.</p>
Git sucks. No need to lament about complexity, just get used to it,
my issue is how it barely helps with asynchronous development.
Merge conflicts are hard to fix,
conflict resolution doesn’t provide enough context, and
need a config flag to avoid having to repeat the same conflict resolution a billion
times.
If merge requests are not handled fast enough,
invariably you have to rebase over and over, even for trivial changes.
You always</em> get merge conflicts if you touch the imports of your file.
I swear, I feel sometimes git invents new commits just out of spite
and forces you to solve conflicts.</p>
Why all of this?</p>
You develop on a dev machine, usually running the same OS as the CI machine.
You don’t delete your whole OS and reinstall everything from scratch
every time you compile your code.
You take advantage of your language’s compiler ability to cache intermediate
results and reuse them.
Why is it that we remake everything from scratch on our CI machines?</p>
The artifacts locally generated by your compiler are no different
from the ones your CI machine generates.
So why not re-use them?</p>
You ran the tests locally, why is it that the CI machine must re-check them?</p>
Why is it that git can’t take into consideration your language’s syntax
when generating diffs?
Even Vim automatically detects your file’s language and understands
enough of it to color it accordingly.</p>
Can’t we do better? It seems we got stuck at one point on Jenkins + git,
and froze in time before we got actually good development tools.</p>
Can’t we get better review tools?
Github, Bitbucket and Gitlab are worse than bad.
Insanely slow, barely any context in the review comments,
with little traceability.</p>
It seems those issues that affect all developers all the time are left
completely unattended.</p>
Why is that?</p>
Are we so bereft of creativity we can’t imagine a better world for ourselves?</p>
I see some</em> interest, but so so little of it. In no particular order:</p>

There is dark</a></li>
There is unison</a></li>
There is pijul</a></li>
</ul>
Both pijul and unison do not directly solve any of my questions,
they only explore related problems.</p>
Anything else? Anything more? How have we not yet solved
(or even slightly improved) those issues?
Yet, those must be the largest source of expense in the modern development workflow.</p>


Helix magic
2022-07-18T00:00:00+00:00
I’ve been using as daily driver the Helix</a> text editor for 3 months now.
Coming from 5 consistent years of Neovim usage, I switched fairly quickly.
The kakoune-based modal editing intrigued me, and I wanted to give it a try.
But what swayed me is the great out-of-the-box user experience.
Going from 200 lines of fennel config and 20 dependencies to 0 config and 0
dependency is a big plus.</p>
I’m still more comfortable with neovim than helix, but Helix has capabilities
that I’ve yet to take advantage of.</p>
Here is an example of what I mean.</p>
The problem</h2>
I was asked to create a criterion</a> report for changes I made to the bevy
implementation of query iterator size hints</a>.</p>
After familiarizing myself with criterion and running the benchmarks,
criterion generated a report in the form of a HTML file tree.
Each benchmark has its own html file with a variety of plots,
the reports also contain a bunch of json and csv files I’ve no idea how to use.</p>
Criterion also generates automatically difference plots if you run it twice in
a row. But again, does nothing else but embed them in the benchmark-specific
html page.</p>
However, what I needed was a summary</em> of all the changes. It was impossible to
tell what the changes I made entailed at a glance, since I would need to open
each html benchmark report individually and look at the “Changes” section at
the very end of the file.</p>
How did Helix help me solve it</h2>
What I wanted was a unique page that displays a single plot per benchmark and a
summary of the changes for it.</p>
Looking at the file tree generated by criterion, I found that each report had a
subdirectory called both</code> with a few plots in them. The one I chose was
pdf.svg</code> (the probability density function), because it does both a good job
of expressing the accuracy of the benchmark and the effects of the change.</p>
I also needed the table of comparison from each html report files (as follow):</p>

  
    
      </th>
      Lower bound</th>
      Estimate</th>
      Upper bound</th>
      </th>
    </tr>
  </thead>
  

    
      Change in time</td>
      -0.0149%</td>
      +0.0193%</td>
      +0.0543%</td>
      (p = 0.33 >
      0.05)</td>
    </tr>
  </tbody>
</table>
Ideally, I’d also make it clear which benchmark was an improvement and which
one was a regression by having a different color for each comparison result.</p>
How I did it</h3>
I first used the fd</code></a> tool to list all pdf.svg</code> files within a both</code>
directory.
I then put the result in a file.</p>
(btw I strongly recommend you use fd</code>, it’s a better version of find</code>, which
paleolithic UI I absolutely never once remembered how to use, even at five
minutes interval)</p>
fd --full-path</span> both/pdf.svg target/criterion </span>></span> all_changes.html
</span></code></pre>
I then opened all_changes.html</code> with helix.
The content of the all_changes.html</code> file was as follow:</p>
target/criterion/for_each_iter/report/both/pdf.svg
</span>target/criterion/for_each_par_iter/threads/1/report/both/pdf.svg
</span>target/criterion/for_each_par_iter/threads/16/report/both/pdf.svg
</span>target/criterion/for_each_par_iter/threads/2/report/both/pdf.svg
</span>target/criterion/for_each_par_iter/threads/32/report/both/pdf.svg
</span>target/criterion/for_each_par_iter/threads/4/report/both/pdf.svg
</span>...
</span></code></pre>
Note that <ESC></code> means that I press the escape key.</p>
I created a h2</code> html element by copying the head of the file name and copying
it into a h2</code> tag. The command sequence would be:</p>

111C</code> (create a cursor per line in the file)</li>
gs2f/d</code> (go to start of line, select all characters between it and the 2nd
next slash and delete them)</li>
gl</code> (go to line ending)</li>
3F/h</code> (go back 3 slashes in the line + one more character back)</li>
v</code> (enter selection extension mode)</li>
gs</code> (go to start of the line)</li>
"iy</code> (yank selection into register i</code>)</li>
O<ESC></code> (create a new line before this one, exit edit mode)</li>
_iP</code> (insert in before the cursor the content of register i</code>)</li>
I<h2><ESC></code> (insert the string “<h2>” at the beginning of the line)</li>
A</h2></code> (finally, insert “</h2>” at the end of the line)</li>
</ul>
<h2>for_each_iter</h2>
</span>for_each_iter/report/both/pdf.svg
</span><h2>for_each_par_iter/threads/1</h2>
</span>for_each_par_iter/threads/1/report/both/pdf.svg
</span><h2>for_each_par_iter/threads/16</h2>
</span>for_each_par_iter/threads/16/report/both/pdf.svg
</span></code></pre>
I then embedded the image in the file by translating each line into a img</code>
element.</p>

o<img src="<ESC></code> (start new line with img tag beginning)</li>
_iP</code> (past content of register i</code> before the cursor)</li>
i/report/both/pdf.svg"><ESC></code> (insert the end of the img tag)</li>
</ul>
<h2>for_each_iter</h2>
</span><img src="for_each_iter/report/both/pdf.svg">
</span>for_each_iter/report/both/pdf.svg
</span><h2>for_each_par_iter/threads/1</h2>
</span><img src="for_each_par_iter/threads/1/report/both/pdf.svg">
</span>for_each_par_iter/threads/1/report/both/pdf.svg
</span></code></pre>
Now the difficult thing was embedding the html change report table  from the
benchmark page.
For this, I used xidel</a>, a xpath</a> tool to read xml and html.
It’s very similar to jq</code>, but for xml</code> rather than json</code>.</p>
FYI xidel</code> is a single pascal file of 2000 lines.</p>
I first tested in my shell how I would do it in pure bash. I came up with the
following function:</p>
function </span>get-report-table </span>{
</span>    </span>file</span>=</span>"${</span>1</span>%%</span>both/pdf.svg}"
</span>    </span>xidel</span> ./target/criterion/$</span>file</span>/index.html \
</span>        --xpath3 </span>'//*[@class="additional_stats"]' </span>\
</span>        --printed-node-format</span>=</span>html
</span>}
</span></code></pre>
This returned (almost) the HTML I wanted in my final file:</p>
<</span>div </span>class</span>=</span>"additional_stats"</span>>
</span>  </span><!-- The report data for the last benchmark, which
</span>       we don't care about for the summary -->
</span></</span>div</span>>
</span><!-- What we want: the comparison table between the last benchmark and
</span>     the current one (with a diagnostic such as "Performance has improved.")
</span>     -->
</span><</span>div </span>class</span>=</span>"additional_stats"</span>>
</span>  <</span>h4</span>>Additional Statistics:</</span>h4</span>>
</span>  <</span>table</span>>
</span>    <</span>thead</span>>
</span>      <</span>tr</span>>
</span>        <</span>th</span>></</span>th</span>>
</span>        <</span>th </span>title</span>=</span>"0.95 confidence level" </span>class</span>=</span>"ci-bound"</span>>Lower bound</</span>th</span>>
</span>        <</span>th</span>>Estimate</</span>th</span>>
</span>        <</span>th </span>title</span>=</span>"0.95 confidence level" </span>class</span>=</span>"ci-bound"</span>>Upper bound</</span>th</span>>
</span>        <</span>th</span>></</span>th</span>>
</span>      </</span>tr</span>>
</span>    </</span>thead</span>>
</span>    <</span>tbody</span>>
</span>      <</span>tr</span>>
</span>        <</span>td</span>>Change in time</</span>td</span>>
</span>        <</span>td </span>class</span>=</span>"ci-bound"</span>>-17.097%</</span>td</span>>
</span>        <</span>td</span>>-14.185%</</span>td</span>>
</span>        <</span>td </span>class</span>=</span>"ci-bound"</span>>-11.391%</</span>td</span>>
</span>        <</span>td</span>>(p = 0.00 </span>&lt;</span> 0.05)</</span>td</span>>
</span>      </</span>tr</span>>
</span>    </</span>tbody</span>>
</span>  </</span>table</span>>
</span>  Performance has improved.
</span></</span>div</span>>
</span></code></pre>
Helix has the “|</code>” command to pass the currently selected lines to a shell
command and replace them in place with the output of the command.</p>
I had difficulties with this one, because xidel</code> only accepts files as
argument, also parameter expansion</a> (such as ${1%%both/pdf.svg}</code> used to
remove the trailing both/pdf.svg</code> from the input) does only work with
variables, not standard input.</p>
The trick was to:</p>

Replace the $file</code> in the command by $(cat /dev/stdin)</code></li>
Remove in helix the trailing both/pdf.svg</code> (gl2F/d</code>)</li>
Now I can just press |</code> and copy the command.</li>
</ol>
And BANG! I had now the table in my html file for each benchmark.</p>
I then selected the extraneous report div by using helix’s awesome
tree-sitter based motions (I bound them to (</code> and )</code> on my keyboard), and
pressed d</code> to remove it.</p>
Now for clarity, I just needed to wrap the “Performance has improved” bit into
a <a style="color:red/green"></code> based on the message.</p>
This is a classic usage of the helix editor.</p>

Select the whole document with %</code></li>
with s</code> enter “select mode”</li>
type improved</code>, then enter. You now have all the occurrences of improved</code></li>
expand selection to parent syntax node (I set this to ]</code>)</li>
Add in front the anchor node opening with i</code></li>
Add at the back the node closing delimiter with a</code></li>
Repeat with regressed</code>.</li>
</ul>
Done.</p>
I now had the full report, I uploaded it on my site</a> and linked it in
the PR.</p>
EZ</p>


The mut keyword in Rust
2022-07-18T00:00:00+00:00
Rust implements explicit mutability declaration. However, rust has a very
unique and precise definition of what “mutating” a variable means, and this
might trip up new users.</p>
Also, rust’s borrow rules makes declaring variables as “constant” or
“mutable” much more meaningful than in other programming languages.</p>
I’ll explain here what mut</code> really</em> means in rust.</p>
The tl;dr is: declaring a variable as mut</code> just allows you to create a mutable
reference to it, and assign new values to it nothing more, nothing less.</p>
Let’s start with some code:</p>
use </span>std::collections::HashMap;
</span>
</span>let</span> my_map: HashMap<</span>usize</span>, String> </span>= </span>HashMap::new();
</span></code></pre>
Here, we create a new hash map, call it my_map</code>.
We own</em> my_map</code>, because what my_map</code> is,
is not a reference (&Foo</code>) or mutable reference (&mut Foo</code>).</p>
But, when you do:</p>
let</span> item </span>=</span> my_map.</span>get</span>(</span>103434</span>);
</span></code></pre>
You are creating a reference to my_map</code>.
The get</code> method</a> on HashMap</code> accepts a &self</code>, a reference.
But my_map</code> is not a reference, this should be a compilation error!
Mismatching types.
What is actually happening is that the compiler inserts a reference here.</p>
let</span> item </span>= </span>(</span>&</span>my_map).</span>get</span>(</span>103434</span>);
</span></code></pre>
The same is true for the insert</code> method</a>.
insert</code> accepts a &mut self</code>, a mutable reference.
So, behind the scenes, rust creates a mutable reference to my_map</code> when you
do:</p>
let</span> my_map: HashMap<</span>usize</span>, String> </span>= </span>HashMap::new();
</span>// !!!!! ERROR, does not compile !!!!
</span>my_map.</span>insert</span>(</span>340101</span>, </span>"My String"</span>.</span>to_owned</span>());
</span>// (&mut my_map).insert(...)
</span></code></pre>
In fact, the above snippet of code doesn’t compile.
This is because rust requires all variables for which you create mutable
references to be declared with the mut</code> keyword.</p>
let mut</span> my_map: HashMap<</span>usize</span>, String> </span>= </span>HashMap::new();
</span>//  ^^^
</span>// 👌 💯
</span>my_map.</span>insert</span>(</span>340101</span>, </span>"My String"</span>.</span>to_owned</span>());
</span></code></pre>
In rust, function parameters act like variable declarations,
so they follow the same rule.</p>
Why can I mutate a mutable reference without mut</code>?</h2>
Ok, but why can I do this?</p>
let mut</span> my_map: HashMap<</span>usize</span>, String> </span>= </span>HashMap::new();
</span>let</span> my_other_map </span>= &mut</span> my_map;
</span>my_other_map.</span>insert</span>(</span>340101</span>, </span>"My String"</span>.</span>to_owned</span>());
</span></code></pre>
See? No mut my_other_map</code>, only let</code>!</p>
Indeed, the only things you need to declare with mut</code> are:</p>

Things you create a mutable reference of</em>.</li>
Things you assign to, as in foo = new_foo;</code></li>
</ol>
my_other_map</code> is already a mutable reference, and you are not assigning to it.
So it doesn’t need to be declared mut</code>.</p>
Besides, the &mut</code> here in the declaration is a dead giveaway that you are
going to mutate my_other_map</code>.</p>
By all means, you still can create a mutable reference to your mutable
reference if you really want to.</p>
let mut</span> my_map: HashMap<</span>usize</span>, String> </span>= </span>HashMap::new();
</span>let</span> my_other_map </span>= &mut</span> my_map;
</span>// !!!!! ERROR, does not compile !!!!!
</span>// need to declare mut my_other_map
</span>let</span> my_sneaky_map: </span>&mut &mut </span>HashMap<</span>_</span>, </span>_</span>> </span>= &mut</span> my_other_map;
</span></code></pre>
In comparison to other languages</h2>
Rust follows a recent trend in languages design, which is to make the
declaration of mutable variable distinct from immutable variables.</p>
However, in other programming languages, everything has interior mutability</em>.
Interior mutability is when you modify the inside</em> of a class without
modifying the outside.
In any project of meaningful size, you more often change the inside of classes
than their complete value
(in fact, it’s very rare to change the value of something without going through
a method).
All implementations of explicit mutability declaration I have seen, do not, in
any way, prevent interior mutability. Even rust</strong>.</p>
As a result, the only way to ensure immutability in those languages, is by only
exposing non-mutating methods to your class and marking all fields private.</p>
In scala, you can</em> use val</code> and var</code> to declare a variable as “immutable” vs
“mutable”, but this is definitively misleading. You can very much declare a
java</strong> hash map as val</code> and then insert new items in it.
However, since the scala standard library is immutable, there is no point in
worrying about mutability or interior mutability.
(unless of course, you are using java classes or your scala classes themselves
contain java classes)
The compiler doesn’t in anyway guarantee that your val</code> won’t be mutated or
won’t have a mutable method.
So what is var</code> for?
It’s a sort of inline documentation (with all the pitfalls that this entails).
And honestly, I’m not too hot on it.</p>
This is also true of javascript’s var</code> vs const</code>, and C’s const</code> (beyond the
complete nonsense related to declaration priority and what const</code> is
actually const</code>-ing between the type, the reference or god knows what)</p>
const </span>we_have_consts </span>= </span>{ a: </span>10 </span>}
</span>// Wait, this doesn't even cause a runtime error???
</span>we_have_consts</span>.</span>a </span>= </span>34
</span>console</span>.</span>log</span>(</span>we_have_consts</span>.</span>a</span>)
</span>// 34
</span></code></pre>
Rust also has interior mutability, and indeed, it can trip up users to see a
method taking a &self</code> and modifying the value of self</code>.</p>
However, this is far from usual, and it’s mostly constrained to specialized
concurrent libraries such as dashmap</a>.</p>
(also, &mut T</code> itself has interior mutability, by definition, you are mutating
something “pointed to” by the reference, aka “inside” of it)</p>
In general, the borrowing rules prevent all spooky action at a distance,
at least, as long as the unsafe</code> code you are using is sound.</p>


The little coordinate system reference
2022-07-16T00:00:00+00:00
I’ve been implementing an FBX</a> 3d file format loader for bevy</a>, and currently the
most challenging part of it has been figuring out coordinate system
transitions.</p>
I’m having a lot of trouble using search engines to find references online, so
I’m creating my own. Here it is: the most exhaustive reference (with pictures!)
on how to convert between coordinate systems.</p>
If you finish reading this without an answer to those 3 questions, I’m a twat.</p>

What’s “left-handed” vs “right-handed” coordinate systems?</li>
What is forward?</li>
How to convert between coordinate systems?</li>
</ul>
What’s a coordinate system?</h2>
A game engine, a modelling software, or any 3D game work in 3D space.
To locate something in 3D space, you need some sort of information or data.
The position data is called a “coordinate”, and in 3 dimension,
it is divided in 3 different scalar1</a></sup> values, also called components.
Software most often use the standard basis</a> as coordinates.
Each component answer the question:
“how many step in this basis direction do you have to make
to reach the coordinate position?”
The basis of 3D space are X, Y and Z. We all agree on that.
However, it turns out, beyond that, no one agrees on anything.</p>
What are the differences between coordinate systems in different software?</h2>
You might be interested in this link</a> as a reference of which
software uses which coordinate system.</p>
Beyond X Y and Z, you need to find what they represent.
On a whiteboard, you generally draw the X axis from left to right and the Y
axis bottom up.</p>
</p>
While, when drawing on a piece of paper on your desk, the X axis goes to the
right and the Y axis forward</strong>.</p>
Each software is free to chose what axis is up.
Usually, Y is up, like on the whiteboard. But after choosing what “up” is,
there is the question of choosing what is “forward” (goes out of the whiteboard
perpendicularly) and what goes in the other direction of the whiteboard.
(on the whiteboard, it was X)</p>
The left/right-handed coordinate system</h2>
(If you are reading this in a public place, you may look silly while reading
this section.)</p>
To answer this question, some people use the “left/right-handed” description.
Take your hands, and point your thumb, your index and middle fingers outward.
In the left/right-handed system, the thumb is X, the index is Y and middle
finger Z.
You’ll notice that regardless of how you spin your hands,
the outward fingers of both hands won’t ever go in the same direction.
They may at one point end up on the same axises, but they won’t point in the
same direction.</p>
I embedded an interactive demo, which source code is
available here</a>.</p>
The left gizmo is left-handed, while the right gizmo is right-handed.
The red ball is +X</strong>, the green ball is +Y</strong> and the blue ball +Z</strong>.</p>
(may be slightly broken on mobile)</p>

Warlock's Gambit trace analysis

Can't we do better than the current dev workflow?

Helix magic

The mut keyword in Rust

The little coordinate system reference

- Nicola Papale's technical blog

Bit fields for everyone

The quest for a perfect quasi-random sequence

What I make of ChatGPT

Optimizing the day 6 Advent of Code 2022 challenge a little too much

- Nicola Papale's technical blog

Bit fields for everyone

The quest for a perfect quasi-random sequence

What I make of ChatGPT

Rust pitfall</h2> Here is a short interaction for code gen</p>

Optimizing the day 6 Advent of Code 2022 challenge a little too much

Warlock's Gambit trace analysis

Can't we do better than the current dev workflow?

Helix magic

The mut keyword in Rust

The little coordinate system reference