Fil-C's GC has basically always had size-specialized allocation and I've done some experiments with this so I have my own data.
As the post says, there are two potential benefits:
- Faster memory clearing when the compiler knows the size. In Fil-C, I leverage that by having LLVM emit a memset inline, so it often ends up being some SIMD crap.
- Faster size class computation.
Interestingly, the faster size class computation isn't really faster in practice. I implemented it and that's how the ABI works today, but I'm likely to move the size class computation into the runtime to simply the ABI, since repeated experiments show that there are no savings to be had there. It's super surprising, but the numbers don't lie.
Anyway, cool to see other fast non-moving GCs also finding the same sweet spot as me.
(Posted from WebKit built with Fil-C so for extra meta, I'm using the GC I describe to write this post)
On a sufficiently anemic CPU doing enough fast allocation you can get measurable improvements from that kind of thing, but for a superscalar CPU and a general purpose allocator I agree you'd be hard pressed.
pizlonator•35m ago
Not sure that protobuf change is the same thing
But you might be right on your overall point: on my big x86 CPU, it doesn't matter, but it might matter on some tiny arm thingy
pizlonator•59m ago
Fil-C's GC has basically always had size-specialized allocation and I've done some experiments with this so I have my own data.
As the post says, there are two potential benefits:
- Faster memory clearing when the compiler knows the size. In Fil-C, I leverage that by having LLVM emit a memset inline, so it often ends up being some SIMD crap.
- Faster size class computation.
Interestingly, the faster size class computation isn't really faster in practice. I implemented it and that's how the ABI works today, but I'm likely to move the size class computation into the runtime to simply the ABI, since repeated experiments show that there are no savings to be had there. It's super surprising, but the numbers don't lie.
Anyway, cool to see other fast non-moving GCs also finding the same sweet spot as me.
(Posted from WebKit built with Fil-C so for extra meta, I'm using the GC I describe to write this post)
charleslmunger•54m ago
On a sufficiently anemic CPU doing enough fast allocation you can get measurable improvements from that kind of thing, but for a superscalar CPU and a general purpose allocator I agree you'd be hard pressed.
pizlonator•35m ago
But you might be right on your overall point: on my big x86 CPU, it doesn't matter, but it might matter on some tiny arm thingy