diff options
| author | Taylan Kammer <taylan.kammer@gmail.com> | 2026-08-26 23:25:58 +0200 |
|---|---|---|
| committer | Taylan Kammer <taylan.kammer@gmail.com> | 2026-08-26 23:25:58 +0200 |
| commit | 3416b560e5cefecd317d0e18f0cdc17458113f02 (patch) | |
| tree | 1aebdc9d1edeaeeb748f3ad679e2f400beac9a12 /notes | |
| parent | 0d8e67b84ac39b529247c07c49f235225f40ba55 (diff) | |
Note update.
Diffstat (limited to 'notes')
| -rw-r--r-- | notes/260826-use-alloc.md | 9 |
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 |
