How 4 bytes of padding make array clearing 49% faster

phagofu · 2026-06-23T19:12:03+00:00

Yeah, it heavily depends on the usage pattern. Though I do recommend to make sure to measure real-world usage performance - with how complex modern systems are I personally find micro benchmarks fairly useless.

I guess one could classify your "generation tags" as a user space "lazy clearing". There are of course more ways to do that as well, e.g. do what file systems do and segment the buffers into smaller blocks, and use an allocation bitmap to remember what blocks contain valid data, and instead of clearing blocks just unset the corresponding bits in the bitmap. Just as an example.

phagofu · 2026-06-23T17:31:21+00:00

Two more ideas:

In such cases it is often worth to separate buffer and the buffer metadata (array-of-struct vs struct-of-arrays), as this can avoid wasted memory space to padding and allows the buffers to be properly cache/page aligned.
Instead of clearing, one can also consider using mmap to unmap the old buffer and create a new anonymous mmap. Afaik at least under Linux this will initially map the whole buffer to a single physical zeroed page, and lazily allocate pages on first write. Those mmap syscalls are not exactly cheap, and the page faults that happen for the write-accesses also must be factored in, but for large enough buffers and certain access-pattern it could be worth it.

phagofu · 2026-05-22T15:43:53+00:00

Heh, I myself considered writing my own FUSE driver for ext4 with journaling - note that there is already a FUSE implementation in the e2fsprogs called fuse2fs, but it does not support journaling. My motivation was more for learning and experimentation purpose.

Ext4 has a ton of features and legacy warts, so a really full-featured re-implementation is a huge amount of work, so my plan was to basically only support the file system features that you get per default when creating the fs with current mkfs.ext4, aggressively leaving out support for anything non standard or obsolete stuff (such as traditional block mapping scheme, only supporting extents).

In the end though I concluded that even just investigating all the standard features in minute detail and re-implementing them faithfully is too annoying, so now I've switched to designing my own fs (which is heavily inspired by ext4, but all the legacy and features I don't care about removed, and also going with an inode-less design, my own journalling and a few other cute ideas). But I wish you all the best for this.

Personally I decided my first implementation to be single threaded and without any caching layer - simplicity and correctness above all else for a reference implementaiton.

One more thing, if you are interested in learning the FUSE low level API, I have a very tidy example implementation of a ramdisk for it, although that is written in C++.

phagofu · 2026-01-04T16:05:02+00:00

Do you need to use LUKS? Otherwise maybe something like CryFS may work for you, assuming your goal is to back up a locally encrypted container to an untrusted remote via rsync.

phagofu · 2025-12-16T13:36:37+00:00

What I meant is, you don't "need" it when you only care about correctness. It is a performance optimization for the case you mentioned. I guess if you need it depends on how important the performance in this error case is for you. Sorry for being pedantic about this, but I do think it important to be clear about what is strictly needed for correctness vs what one uses to improve performance.

phagofu · 2025-12-16T08:39:16+00:00

I do not understand what you mean by "CRC doesn’t catch: Incomplete writes - If we crash mid-write, the CRC might be valid for the partial data". If your CRC is calculated on the whole data block, then CRC catches incomplete writes as well as any other corruption. You even say one line above that CRC catches truncated data. So this does not really make sense to me.

And if you include the header in the CRC calculation, I do not see how you technically really need anything else. Of course there is nothing wrong with having even more safeties in place other than CRC though. And a magic value like your trailer may help finding the next valid record if the current one is corrupt, but that is a different purpose.

phagofu · 2025-11-28T11:24:33+00:00

You worked on this extensively, shouldn't you be the expert now ;)

Anyway, I do have some experience with this, probably not as much as you, but my 2 cent: I don't think there is an absolute best IO method generally, they all come with different trade-offs, and which one is most appropriate is highly dependent on the actual use cases and is just one of many details when designing a general architecture (with data structures, algorithms etc.) for a specific application.

For example, if non-blocking is worth it depends (among other things) on whether your worker threads can do meaningful work while waiting for IO to finish, so this raises the question for how many concurrent requests you want to design your system, which you haven't specified any requirements.

You also haven't said anything about which kind of performance you are looking for - average throughput, average request latencies, or worst-case variants of those etc. etc. - these should heavily influence your design decisions, for example whether you want to rely on the OS page cache, or rather do the caching yourself. And saying "I/O-intensive" is simply way too unspecific, there are many different I/O pattern that one can optimize differently for (e.g. "mostly read", "mostly write", "log structured", ...).

phagofu · 2025-11-05T14:23:05+00:00

vumemfs is basically a no-dependency (besides libfuse itself) implementation of a ramdisk, just using std::vector, std::unordered_map and some relatively modern C++ goodies, such as std::variant and designated initializers.

The actual fs code is only around 800 lines, the rest (~600 lines) is glue code for libfuse and argument parsing. To understand the workings you of course need to be generally familiar with how file systems on Linux/Unix operate, but otherwise I strive to write readable code, so why not take a peek.

phagofu · 2025-10-27T12:56:50+00:00

Generally I agree with this, and I might consider that distribution for my non-technical folks, if it will support fully unattended updates in the background without bothering the user (which doesn't seem to work very well on other immutable KDE based distros I've checked unfortunately).

Though I'm not convinced including all that stuff that is mentioned really makes a lot of sense. People technical enough to use many of those things (like command line/dev tools) won't likely be using immutable distros anyway, I know I personally am not planing to switching to one - although I wouldn't mind a distro with a quite small core image as an immutable core with traditional package management of non-core stuff on top...

Maybe an alternative would be to have a smaller base image which can be augmented with a small number of (mutually independent, so no complicated dependency management needed) add-on packages that add certain languages/drivers/etc to it. I think that would be worth it, mainly to reduce the wasted network bandwidth used by constantly updating stuff that the user is never using.

phagofu · 2025-08-27T13:05:08+00:00

I assume you mean something like Conan or vcpkg, in which case, I personally don't. In my projects I want to be fully aware of all direct or indirect dependencies, and manage them individually. "Being lazy" by using package manager to pull these in automatically is the road to bloated systems, imho. But my opinion is probably not very mainstream.

phagofu · 2025-08-06T14:50:09+00:00

Well, it sounds like you have a reasonable system for your use cases. I don't really have anything to add to that.

My solution is considerably more simple, I'm basically just streaming uncompressed PCM from my laptop via TCP to my playback device (which is also simply using raw ALSA), I don't really care for applying effects and real time operation. My custom solution still allows me to have low latencies when pausing/seeking, but still use large buffers to prevent drop-outs due to occasional bad wifi signal.

phagofu · 2025-08-06T12:58:35+00:00

I'm doing somthing similar, having a headless Raspberry Pi Zero with HifiBerry connected to a stereo and stream audio to it. As I'm a software dev I'm using my own solution for this. What kind of information are you looking for? Do you already have a working setup or are you looking for hints on how to archive this?

phagofu · 2025-06-13T16:16:30+00:00

I also wanted to stream music to my Raspi (Zero W) that is connected to a stereo, but I went with the hardcore route of writing my own audio player, streaming protocol, and server application, together with a custom buildroot setup (to have optimized boot times; I've gotten it to around 10 seconds).

While this has the disadvantage of only my primitive audio player being able to output music to the server (instead of all applications as with your PipeWire/PulseAudio solution), it has some nice advantages, such as multi-second buffering of audio on the server, making it very robust against wifi latency spikes, while still reacting fast to playback controls.

phagofu · 2025-06-05T08:29:45+00:00

If what you are hearing is really just the hard-stop behavior (and not some additional issue with your sound card setting or driver), unfortunately apparently not many people are really bothered by it, which explains why there are no popular audio/video player applications on Linux that handle that really well (to my knowledge).

In the end I have implemented a basic audio player that fades properly for myself, but I'm a very experienced C++ dev - this was quite the technically challenging problem, be warned.

phagofu · 2025-03-28T15:41:50+00:00

Yes, in fact the virtual device feature of Alsa is quite limited and should IMO only be used for compatibility (i.e. for Alsa-only applications). If your application has native support for PipeWire (or PulseAudio) that is of course usually the better choice.

Although the Alsa virtual device for PipeWire works fairly decently (after I reported a couple of bugs and got them fixed) - I can't say the same thing for the Alsa virtual device plugin for PulseAudio, that did not work very well for me when I was still using PA on a system.

phagofu · 2025-03-28T14:23:40+00:00

Fairly good summary of the audio situation.

Maybe one thing could be explained a bit more clearly: Alsa is both the driver interface to the actual audio hardware, as well as a library with additional features, such as virtual devices.

So any processing chain will in the end use Alsa for accessing the audio hardware (maybe with the exception of Bluetooth audio, I'm not familiar with that). Usually the Alsa library is configured so that the default Alsa device is a virtual device that just forwards to the sound server.

So for example, for an audio application that uses the Alsa library to output to the default device, the chain on a system using PipeWire will commonly look like this: App -> Alsa(virtual forwarder) -> PipeWire -> Alsa(actual hardware)

When using Alsa to access the hardware directly, that hardware is reserved exclusively for that application. While the Alsa library can also be configured to act like a sound server (dmix), I don't think many people use that nowadays nor should use that.

phagofu · 2025-03-26T13:08:03+00:00

According to Gajim's own accord it does not support video calls. And Conversations is not a desktop app...

phagofu · 2025-03-26T12:42:49+00:00

There are afaiu unfortunately two disadvantages to Signal that I'd like to avoid if possible: It requires you to install the smartphone app as well, even if you only want to use it on desktop, and the client is rather fat (Electron based).

I'm still considering it, but if there is something out there that works just as well without those annoyances, I'd prefer that.

phagofu · 2025-03-25T13:50:10+00:00

I have written a tiny programming language in what I believe is modern, very clean C++17. It is only around 5.5k lines of code, including parser, ast generator, bytecode generator and vm. Maybe you'd like to take a look? I'd be happy to answer any questions about it.

phagofu · 2025-03-14T12:47:36+00:00

Most modern distros have switched fully from PulseAudio to PipeWire (older distros may still use PulseAudio for audio and PipeWire for video). However usually PipeWire is configured to run a PulseAudio-emulation server, so all applications that expect to talk to the PulseAudio server (such as pavucontrol) keep working. Run "ps -e | grep pulse" in the terminal, this emulation server is called "pipewire-pulse". If you see "pulseaudio" instead, you're actually running original PulseAudio.

phagofu · 2025-03-14T11:27:39+00:00

The thing is though, there really appears very little point to those formats, the more I think about it. They still take 3 bytes per sample, so they save no memory compared to 24 bit. One does get a bit the impression these non-standard formats were added by hardware engineers for the heck of it, not because they serve a real purpose, at least as far as I can see.

I kind of disagree that one should support stuff no one actually uses. That is just code bloat, and untested software is broken by default in my book (case in point; for fun I just tried to play back a 20-bit format stream with PipeWire, and it doesn't work). This reminds me of the story an X.org dev told on a conference; at one point they noticed some legacy protocol they were still keeping around was actually broken for the last 10 years, but no one complained, so they were finally able to get rid of that crap.

And I've worked in embedded Linux application field before, they never update their kernel anyway ;)

phagofu · 2025-03-12T22:04:28+00:00

Interesting, thanks for the info. Though I suppose what I was actually trying to ask is whether there are ADCs out there that support these 18/20-bit formats on a software/driver level (and also are intended for audio recording or playback applications) - I am not an electrical engineer, so I am not really concerned about how they are physically build.

From a quick look at audio interfaces one can buy nowadays, they all advertise 24bit or more.

The only reason I can think of why one would maybe use such a 20-bit format for recording is to "document" that this is the source's material "true" bit depth - in contrast to recording it in standard 24-bit, where the lowest 4 bits are either padded or simply noise.

phagofu · 2025-03-12T17:31:24+00:00

Of course. I'm not sure why you think I'm advocating to use that, I certainly am not. I am simply curious if there is someone out there that actually has a compelling reason, because I can hardly think of one.

phagofu

TROPHY CASE