This was the way of the first TMS34010 cards for Autocad (circa 1988). You'd have a EGA/VGA card for the host, and the graphics processor would drive the high-resolution graphics display. There were 50+ vendors with a 340 solution for the high-end, before SVGA. Later, vendors conceded to adding a VGA port integrated alongside.
In Karl Guttag's recent talk on the 34010 (VCFSW YouTube channel) he mentions being contacted by Bloomberg for their multi-up terminal. When it shipped in the early 90s, it was the first dual display system I'd seen. Wall Street later began buying 4-display Matrox cards.
In my grade school years, I made many maps of my imaginary world. By high school, I was putting them into my computer, one 16x16 grid at a time. Had to make sure the edges matched up. Then I wrote code to print them on the Epson MX-80 dot matrix. The poster-board I tiled them on was still in the basement, though many of the squares were falling off.
It was easier after I coded a moving 64x64 buffer.
Oh that is a blast from the past - I had an Epson MX-80 printer as a kid connected to my first PC. Many fond memories of trying to make muti-page prints from it... And the dot-matrix sound is still embedded deep in my brain.
The quoted code suggests that the wrong sizes aren't evident constants in code (there is a function to compute/retrieve them) and extra inspection during debugging is the most plausible way to detect them.
Hopefully this kind of bug is enough to teach the important of measuring, logging and testing to a naive optimist.
Do you think the author is somehow capable of writing the entire codebase, but not able to reason about code???
I'm sure you've never made a silly mistake where you passed the wrong integer parameter to a function, stared at your screen, and failed to notice it. Or, forgot the order of arguments to calloc().
If you're saying that profiling is for those too lazy to reason about their code, you're distorting the whole lesson: profiling is more powerful than guessing.
No, that's not the point. This isn't a situation where you need to "guess"; bloom filters should be sized according to their capacity. This is akin to having a fixed 10-arg buffer for your program, getting a crash when someone passes 11, and saying "this is the kind of bug you only find by building the thing and measuring it". Yeah it happens and we all make silly mistakes, but it's just not true that this couldn't have been foreseen.
So the author is doing a self-learning exercise about profiling pre-production code, and you're disagreeing with them by comparing it to a commercial contract. I'm sure you've never, ever made a dumb mistake while getting paid.
Well, the thing about reliability is that you can't really guarantee it by testing one particular scenario.
It seems to me that neither the old nor the new version of the code is really "durable" as I would understand the word. The old version made a write syscall per batch, but doesn't say it also did an fsync per batch. The new version writes data to an mmap'ed file, and calls fsync in the background.
So both versions are "durable" in the sense that written data is preserved even if the process gets killed, because it's in the OS page cache. But in both versions, a write can be completed before the data actually makes it to disk, so a power failure will lose acknowledged writes.
His slide showed Opus 4.6 saying "walk". I couldn't get 4.6 to do that.