Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

86% Positive

Analyzed from 191 words in the discussion.

Trending Topics

#size#faster#fil#class#computation#cpu#super#allocation#experiments#post

Discussion (3 Comments)Read Original on HackerNews

pizlonator•about 2 hours ago
Super interesting!

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•about 2 hours ago
https://github.com/protocolbuffers/protobuf/commit/50f9ac3ba...

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•about 2 hours 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