The price hike on RAM due to the LLM as a service bubble is really killing interesting fields. Can't we have nice things? Will the arm race end soon?

Indeed be careful at how you use strings when interacting with C APIs. String views are likely not what you want in that context. There is a reason why they don't have c_str().

Long and comprehensive look at how zswap and zram work. They each bring their own tradeoffs, it's important to understand them to choose.

Interesting story on how sometimes you can be betrayed by your memory allocator.

Of course it's a question of the amount of allocations you need.

I used to do that, fell into the "taking notes on the computer". And clearly it's not the same, I'm thinking going back to paper notebooks soon.

Looks surprisingly easy to profile the Django startup. Probably makes sense to profile other parts of your application but this is likely a bit more involved.

Nice introduction of the C++ ownership system. Nothing new under the sun obviously but since I still encounter developers struggling with this, such introductory material is nice to have handy for sharing.

A good reminder that allocators generally do more than you expect.

Careful of undefined behaviours. They can be reached fairly quickly. Especially in C++ and its initialisation maze.

Another explanation for the rule of zero in C++. We should definitely stick to it.

Excellent resource for keeping an eye on performance issues in your codebase. It's very C++ oriented but most of the insights can be generalised to other ecosystems.

A reminder that small details at declaration can have large impacts on memory layouts.

No, don't go assuming you can use disks instead of ram. This is not what it is about. It shows ways to get more out of your disks though. It's not something you always need, but sometimes it can be a worth endeavor.

Interesting notes about borrow checking in Rust. Looks like it does a good job exploring the whole space of issues one can encounter with potential solutions.

Just a little dive in the Rust standard library. It gives a good idea on how they pile layers to ensure safety while providing a nice API on top.

Interesting dive into an heisenbug... Definitely not easy to debug.

Due to the strict type system this kind of conversion is not necessarily a given. There are ways though, and you can even keep it performing well.

This is an interesting and deeply buried optimization for the GNU C++ STL implementation. I didn't expect anything like this.

No good tricks to optimize your code, but knowing the tooling knobs sometimes help.

Indeed, CPU prefetchers are really good nowadays. Now you know what to do to keep your code fast.

Interesting point, fairly logical but didn't sit to think it through before. Indeed, using arenas to get back features of manual memory management won't lead to the same security issues than outside of a memory safe language.

Dealing with temporaries is always complicated it seems, whatever the language.

I think this is indeed something still easily overlooked. You can deal with this kind of intertwined lifetime issues using shared_ptr.

The memory models for GPU programming are complex. This isn't easy to squeeze more performance without introducing subtle bugs.

Interesting comparison between C++ and Rust for a given algorithm. The differences are mostly what you would expect, it's nice to confirm them.

A bit dated perhaps, and yet most of the lessons in here are still valid. If performance and parallelism matter, you better keep an eye on how the cache is used.

Interesting advanced features of GraalVM to better manage the memory of complex Java programs.

Security asks for more than a memory safe language. It helps some things for sure, but there are tools for other languages as well, you better start using them.

Nice little trick to get rid of some malicious bots.

Mutable vs immutable is a good first approximation... but it goes further and this little article does a good job explaining why.

This is a nice little experiment. Not statistically relevant (there are other papers for that), but shows in the details how introducing Rust can impact the way people work. This is interesting because it means the safety gains are not only strictly coming from the (now infamous) borrow checker. We can't rely on everyone applying all the techniques necessary but for sure they're cheaper to put in place than with C.

The concept of allocators in general and arena allocators in particular is too little know. Here is a little article which rediscover the motives behind them. It's a good introduction to the topic.

This is indeed a nice tool to explore and check the memory layout of data structures.

If you forgot that the memory allocator can matter greatly depending on your workload.

Nice feature, but more interesting in its explanation is the topic of static initializers in Rust. They're clearly not a settled area in the language, that's in part because of how low level static analyzers are.

This could be a big improvement for C. We'll see how far this goes.

OK more questions than answers I guess... That said, it shows interesting differences in design choices with C++ to support the traits system.

This is an important concept in Rust... but clearly it's harder to grasp than you'd expect.

They help with some issues... but they can't solve all the memory safety issues of the language I'm afraid.

Interesting comparison. Ada doesn't fare as good as I'd have expected as soon as pointers are in the mix... but there is a twist, you can go a very long way without pointers in Ada.

What do you want? Speed or safety? Ultimately you'll have to choose one.

Another reminder that you don't want reference to primitive types everywhere in Rust code. There's actually ways to handle this properly. This post gives a couple of simple guidelines to apply.

If you didn't realise that null pointers open a maze of different traps, this is a good summary of widespread misconceptions.

Looks like there is a new venue to improve garbage collectors performance. This should be interesting down the line.

Interesting progress on safe type casting in Rust. This should bring nice zero copy parsing of binary data in some cases.

Data layout is essential for performance reasons. It is too often overlooked. If you want real speed you need to help the memory subsystem.

Good reminder that packing your data is generally the right move when squeezing for performances.

Interesting point. As the memory safety of our APIs will increase, can we reduce the amount of sandboxing we need? This will never remove completely the need if only for logic bugs, but surely we could become more strategic about it.

Funny musing about the OOM killer. With nice pointers if you want to dive further into the topic.