Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CPU cache-friendly data structures in Go

skoredin.pro

Post reply on HN
Print view View original

51–60 of 88 posts

Re: CPU cache-friendly data structures in Go

#51

Post by all2 »

OutOfHere wrote: post #49
all2 wrote: post #48

Earlier quoted context omitted.

Aren't goroutines by their nature asynchronous? Am I misunderstanding what you mean by 'async'?

Asynchronous is a programming style; it does NOT apply to Go. The goroutines run in parallel. Also, don't use complicated words when simple words will do.

    Asynchronous is a programming style; it does NOT apply to Go.
Ok, good to know. I guess I jammed threading and async into the same slot in my brain.

    Also, don't use complicated words when simple words will do.
I'm not sure what you mean by this in relation to my above comment.

Re: CPU cache-friendly data structures in Go

#52

Post by aforwardslash »

OutOfHere wrote: post #49
all2 wrote: post #48

Earlier quoted context omitted.

Aren't goroutines by their nature asynchronous? Am I misunderstanding what you mean by 'async'?

Asynchronous is a programming style; it does NOT apply to Go. The goroutines run in parallel. Also, don't use complicated words when simple words will do.

In golang, there is no guarantee that goroutines will run in parallel; also, it is quite common to use channels as means of synchronization of results, akin to common async programming patterns.

Re: CPU cache-friendly data structures in Go

#53

Post by OutOfHere »

aforwardslash wrote: post #52
OutOfHere wrote: post #49

Earlier quoted context omitted.

Asynchronous is a programming style; it does NOT apply to Go. The goroutines run in parallel. Also, don't use complicated words when simple words will do.

In golang, there is no guarantee that goroutines will run in parallel; also, it is quite common to use channels as means of synchronization of results, akin to common async programming patterns.

> In golang, there is no guarantee that goroutines will run in parallel;

That's not specific to Go lang. Most of the constraints you're thinking of apply to all parallel programming languages. It goes with the territory. All parallel programming languages impose certain flavors of their management of parallelism.

Re: CPU cache-friendly data structures in Go

#54

Post by 0x457 »

loeg wrote: post #45
jasonthorsness wrote: post #27

If you are sweating this level of performance, are larger gains possible by switching to C, C++, Rust? How is Rust for micro-managing memory layouts?

You need to do the exact same kinds of thing in C/C++/Rust. I believe Rust struct layout is not guaranteed to match program order unless you use an annotation forcing it (repr(C)). (So to answer the question: it's great; as good as any other language for micromanaging layout.)

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.

Re: CPU cache-friendly data structures in Go

#55

Post by furyofantares »

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

Re: CPU cache-friendly data structures in Go

#56

Post by sa46 »

OutOfHere wrote: post #49
all2 wrote: post #48

Earlier quoted context omitted.

Aren't goroutines by their nature asynchronous? Am I misunderstanding what you mean by 'async'?

Asynchronous is a programming style; it does NOT apply to Go. The goroutines run in parallel. Also, don't use complicated words when simple words will do.

Go is certainly capable of async programming. https://en.wikipedia.org/wiki/Asynchrony_(computer_programmi...

> The goroutines run in parallel. Also, don't use complicated words when simple words will do.

That’s not called for, especially since you’re wrong.

Re: CPU cache-friendly data structures in Go

#57

Post by [deleted] »

furyofantares wrote: post #55

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

[deleted]

Re: CPU cache-friendly data structures in Go

#58

Post by x-complexity »

loeg wrote: post #46
solatic wrote: post #15

Earlier quoted context omitted.

Most modern processor architecture CPU cache line sizes are 64 bytes, but not all of them. Once you start to put performance optimizations like optimizing for cache line size, you're fundamentally optimizing for a particular processor architecture. That's fine for most deployments, since the vast majority of deployments will go to x86_64 or arm64 these days. But Go supports PowerPC, Sparc, RISCV, S390X... I don't kno…

On which architecture are cache lines not 64 bytes? It's almost universal.

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

https://cpufun.substack.com/i/32474663/notable-differences

As noted by the other comments, Apple's M-series chips seem to use a 128-byte cache line. ARM doesn't mandate that their licensees must use a pre-specified cache line size: 64 bytes just happens to be the consensus-arrived standard.

Re: CPU cache-friendly data structures in Go

#59

Post by ayuhito »

furyofantares wrote: post #55

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

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

Are people supposed to be obligated to post such a report nowadays?

I enjoyed the article and found it really interesting, but seeing these types of comments always kind of puts a damper on it afterwards.

Re: CPU cache-friendly data structures in Go

#60

Post by furyofantares »

ayuhito wrote: post #59
furyofantares wrote: post #55

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

> 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.) Are people supposed to be obligated to post such a report nowadays? I enjoyed the article and found it really interesting, but seeing these types of comments always kind of puts a damper on it afterwards.

> Are people supposed to be obligated to post such a report nowadays?

No, typically when I ask questions it's optional.

> I enjoyed the article and found it really interesting, but seeing these types of comments always kind of puts a damper on it afterwards.

That is why I waited half a day, and until after there were lots of comments praising the article. Still, I'm sorry if it put a damper on it for you.

Also the whole reason I asked about the source is because I think the article has a lot of merit and so I am curious if it's because the author put a lot of work in (LLM-assisted or not.) Usually when I get that feeling it's followed by a realization I'm wasting my time on something the author didn't even read closely.

But I didn't get that this time, and I'd love more examples of LLMs being used (with effort, presumably) to produce something the author could take pride in.

Post reply on HN