summaryrefslogtreecommitdiff
path: root/notes
diff options
context:
space:
mode:
authorTaylan Kammer <taylan.kammer@gmail.com>2026-08-26 23:25:58 +0200
committerTaylan Kammer <taylan.kammer@gmail.com>2026-08-26 23:25:58 +0200
commit3416b560e5cefecd317d0e18f0cdc17458113f02 (patch)
tree1aebdc9d1edeaeeb748f3ad679e2f400beac9a12 /notes
parent0d8e67b84ac39b529247c07c49f235225f40ba55 (diff)
Note update.
Diffstat (limited to 'notes')
-rw-r--r--notes/260826-use-alloc.md9
1 files changed, 9 insertions, 0 deletions
diff --git a/notes/260826-use-alloc.md b/notes/260826-use-alloc.md
index e72b006..20d53c7 100644
--- a/notes/260826-use-alloc.md
+++ b/notes/260826-use-alloc.md
@@ -109,6 +109,15 @@ alignment padding, but that'll be relatively small as well if you do
the calculations, I'm pretty sure. In any case, no worse than other
general-purpose allocators, I'm pretty sure.
+*Update:* Just realized that for SIMD related reasons, it would be
+best to force 16-byte alignment much earlier, and probably 32-byte
+too. Also, the 64-byte alignment doesn't add any value since the
+maximum object size dominates the maximum bit count for bitmaps;
+therefore, the alignment values should simply go: 8, 16, 32, ...
+without any alignment higher than 32. This has practically no
+relevance to the strategies in the rest of this article; higher
+alignments don't prevent any of the discussed designs.
+
## Occupancy bitmaps