Source code of the benchmarks? At least, the False Sharing and AddVectors trick don't work on my computer. (I only benchmarked the two. The "Data-Oriented Design" trick is a joke to me, so I stopped benchmarking more.) And I never heard of this following trick. Can anyone explain it? // Force 64-byte alignment for cache lines type AlignedBuffer struct { _ [0]byte // Magic trick for alignment data [1024]float64 } Mayb…
CPU cache-friendly data structures in Go
71–80 of 88 posts
Re: CPU cache-friendly data structures in Go
#72Earlier quoted context omitted.
Yes, without repr(C) order and padding isn't guaranteed. You would use https://docs.rs/crossbeam-utils/latest/crossbeam_utils/struc... or similar to force fields not being on the same cache line.
huh TIL "On modern Intel architectures, spatial prefetcher is pulling pairs of 64-byte cache lines at a time, so we pessimistically assume that cache lines are 128 bytes long."
Re: CPU cache-friendly data structures in Go
#73I waited half a day to post this, I think we aren't supposed to question if articles are LLM written - but this one really triggered my LLM-radar, while also being very well received. I'd love to know how much LLM was used to write this if any, and how much effort went into it as well (if it was LLM-assisted.)
The structure reads as LLM written. I don't mind this unless the content is utterly wrong. I was actually learning about cache-friendly data structures and I'm really interested in that cache-friendly Robin Hood hashing but now I worry it's a hallucination.
Re: CPU cache-friendly data structures in Go
#74I waited half a day to post this, I think we aren't supposed to question if articles are LLM written - but this one really triggered my LLM-radar, while also being very well received. I'd love to know how much LLM was used to write this if any, and how much effort went into it as well (if it was LLM-assisted.)
Interesting and surprisingly, there are numerous praising comments here.
Re: CPU cache-friendly data structures in Go
#75I waited half a day to post this, I think we aren't supposed to question if articles are LLM written - but this one really triggered my LLM-radar, while also being very well received. I'd love to know how much LLM was used to write this if any, and how much effort went into it as well (if it was LLM-assisted.)
None of the tricks in this article get verified. It is totally solemn drivel. Interesting and surprisingly, there are numerous praising comments here.
Of course I didn't verify the results I got either - I'm not about to spend hours trying to figure out if this is just slop. But I think it is.
Re: CPU cache-friendly data structures in Go
#76Earlier quoted context omitted.
None of the tricks in this article get verified. It is totally solemn drivel. Interesting and surprisingly, there are numerous praising comments here.
FWIW, which may be not much - I had codex cli try to verify the results. On my M2 Macbook Air only the first example (False Sharing) did anything - a 23x speedup compared to the article's 6x speedup. All the others didn't produce any speedup at all. Of course I didn't verify the results I got either - I'm not about to spend hours trying to figure out if this is just slop. But I think it is.
Re: CPU cache-friendly data structures in Go
#77"Data Oriented Design" is more than just for performant code. You can and perhaps should also use it to reason about and design software in general. All software is just the transformation of data structures. Even when generating side-effects is the goal, those side-effects consume data structures. I generally always start a project by sketching out data structures all the way from the input to the output. May get mu…
Good programmers worry about the algorithms. Great ones worry about the data structures and the relationships between them. If memory serves, it was Kernighan.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they’ll be obvious." - Fred Brooks, The Mythical Man Month
And two threads with some further discussion I found while looking for these quotes:
Re: CPU cache-friendly data structures in Go
#78Earlier quoted context omitted.
FWIW, which may be not much - I had codex cli try to verify the results. On my M2 Macbook Air only the first example (False Sharing) did anything - a 23x speedup compared to the article's 6x speedup. All the others didn't produce any speedup at all. Of course I didn't verify the results I got either - I'm not about to spend hours trying to figure out if this is just slop. But I think it is.
Could you share the benchmark source code of the first example?
Re: CPU cache-friendly data structures in Go
#79Earlier quoted context omitted.
FWIW, which may be not much - I had codex cli try to verify the results. On my M2 Macbook Air only the first example (False Sharing) did anything - a 23x speedup compared to the article's 6x speedup. All the others didn't produce any speedup at all. Of course I didn't verify the results I got either - I'm not about to spend hours trying to figure out if this is just slop. But I think it is.
Could you share the benchmark source code of the first example?
Looks like the LLM invented somewhat different test for it than the article had. I tried again and have this with the same data structure as in the article:
That gave similar results to the article.
All the other tests still give little-to-no speedup on my machine.
Re: CPU cache-friendly data structures in Go
#80Earlier quoted context omitted.
Could you share the benchmark source code of the first example?
Here's the one that showed a lot more speedup than the article: https://pastebin.com/v9tczpus Looks like the LLM invented somewhat different test for it than the article had. I tried again and have this with the same data structure as in the article: https://pastebin.com/SDdcchZG That gave similar results to the article. All the other tests still give little-to-no speedup on my machine.
TIL.