3 ms·
I'm not sure I understand your point. First you say: > In general if shrinking the pointer size is a huge optimization, your data structures have too many poin
by dist1ll 4y ago
I'm not sure I understand your point. First you say:
> In general if shrinking the pointer size is a huge optimization, your data structures have too many pointers in them.
And then you go on to say
> having sibling references (e.g. in graph structures) via indices into a slab, which can be u32 rather than pointer-sized.
What you're describing is literally pointer compression. You're using offset indices that point to a compressed/sufficiently small address space.
- scottlamb 4y ago> What you're describing is literally pointer compression. You're using offset indices that point to a compressed/sufficiently small address space. True, but it's finer-grained than a global switch. I can decide that I will have at most 2^32-1 objects in this particular graph/slab without giving up the ability for my program to address more than 4 GiB of RAM in total as it would with the x32 ABI. Also, this trick is only a small part of reducing pointer storage. I mentioned passing stuff in via the stack vs keeping it in the data structure. I forgot to mention: use vecs rather than e.g. linked lists, open addressing hash maps rather than chaining, btrees rather than red/black trees, etc. This is also stuff that Rust's std library encourages. btw: of course none of the techniques I mention are unknown to Donald Knuth. He's likely either wanting to get programs written by others to run more quickly or trying to optimize well beyond what I'd care to do. I'd rather split the difference, basically: decrease pointer density a fair bit and keep the pointers at 64-bit.
- dist1ll 4y agoFair enough, I agree that a global x32 switch seems misguided, especially since efficient data structures are already written in cache-aware ways.