Live data from Hacker News

CPU cache-friendly data structures in Go

skoredin.pro

71–80 of 88 posts

Re: CPU cache-friendly data structures in Go

#71
post #17

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…

[deleted]

Re: CPU cache-friendly data structures in Go

#72
post #54

Earlier 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."

That was true in like, 2011. I'm not sure if it's true anymore.

Re: CPU cache-friendly data structures in Go

#73
post #65

I 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.

None of the tricks in this article get verified. Almost all of them are false.

Re: CPU cache-friendly data structures in Go

#74

I 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.

Re: CPU cache-friendly data structures in Go

#75
post #74

I 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.

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

#76
post #74

Earlier 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.

Could you share the benchmark source code of the first example?

Re: CPU cache-friendly data structures in Go

#77
post #43

"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.

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - Linus Torvalds

"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:

https://news.ycombinator.com/item?id=17580598

https://news.ycombinator.com/item?id=10293795

Re: CPU cache-friendly data structures in Go

#78
post #76

Earlier 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?

[deleted]

Re: CPU cache-friendly data structures in Go

#79
post #76

Earlier 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?

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.

Re: CPU cache-friendly data structures in Go

#80
post #76

Earlier 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.

Many thanks for providing the source. It also works on my machine.

TIL.

Post reply on HN