buddy_alloc VS rotate

If you need a sub-allocator with predictable performance feel free to give it a try. The code is here and it is licensed under the 0BSD license, making it as lax and as close to public domain as possible. Comments, issues and PRs are always welcomed and appreciated. Thanks!

I maintain a project that's not technically MISRA compliant (due to being a memory allocator and MISRA disallowing the very idea) and I keep it at 100% test coverage with support for multiple compilers and operating systems. Over time I had a few users reporting back - since it's working for them I count that as success. Is it wildly popular ? Of course not, but it doesn't have to be.

You are right about the tests - they are written with 64-bit in mind. I ought to rework them to switch sizes based on arch but that will take a weekend. I've filed https://github.com/spaskalev/buddy_alloc/issues/19 to track this.

I also maintain a application-based malloc (that doesn't do obtaining and releasing memory through the OS, just managing sub-diving a larger memory block into smaller requests) at https://github.com/spaskalev/buddy_alloc - feel free to ping me with any questions about it.

I'm the author of https://github.com/spaskalev/buddy_alloc - a custom memory allocator for C (modern C11, works with C++ as well) designed for predictable and repeatable performance. It is suitable for use in embedded, games and any other system with soft or hard real-time demands. It has 100% line and branch test coverage and uses a fixed amount of space on the call stack when called. Recently the project had its first external contribution as well. Cheers!

I made a memory allocator that turned out rather neat - https://github.com/spaskalev/buddy_alloc

quadsort/fluxsort/crumsort author here.

For me there's a strong visual component, perhaps most obvious for my work on array rotation algorithms.

https://github.com/scandum/rotate

There's also the ability to notice strange/curious/discordant things, and either connect the dots through trying semi-random things, as well as sudden insights which seem to be partially subconscious.

One of my (many) theories is that I have the ability to use long-term memory in a quasi-similar manner to short-term memory for problem solving. My IQ is in the 120-130 range, I suffer from hypervigilance, so it's generally on the lower end due to lack of sleep.

I'd say there's a strong creative aspect. If I could redo life I might try my hand at music.

This is essentially just a rotation of a subrange of your original array. A variety of different algorithms for this operation can be found here.

Memory bandwidth is 1000x lower than CPU bandwidth, so as a rule of thumb any algorithm whose work scales linearly in the amount of data being processed will be memory bandwidth bound, and also any algorithm which can't be structured to do a lot of work on one memory region at once before moving onto the next one.

Examples (for large enough inputs that it's relevant) include shuffling, sorting, kmeans clustering, branch and bound sudoku solving, vector addition, dot products, and so on.

Moreover, writing a particular piece of code is often easier if you ignore memory bandwidth as a constraint. The classic example is matrix multiplication -- it can be structured such that even disk bandwidth isn't relevant compared to CPU bandwidth, but doing so is a little fiddly compared to the naive n^2 dot products approach, so writing it yourself usually results in a memory bandwidth bound solution for large matrices.

Similarly, writing two passes over your data rather than doing a mega-loop, the choice to use classic kmeans rather than one of its approximations (when it would be appropriate to do so), or not enforcing sortedness at some reasonable boundary and having to do additional passes over your data. It's easy to write code that hoovers up way more bandwidth than it needs to, and often faster algorithms that come out don't do anything different than access the right data at the right time to reduce that pressure, like a trinity rotation [0].

Caveat: Benchmark everything, especially as you're building intuition. Trying to fix what you think is a memory bandwidth issue can result in pipeline stalls and all sorts of fun things, especially when your server has more faster caches than your dev machine, when data in prod doesn't match your micro benchmark, ....

[0] https://github.com/scandum/rotate