CPU cache-friendly data structures in Go

    // Pin goroutine to specific CPU
    func PinToCPU(cpuID int) {
        runtime.LockOSThread()
        // ...
        tid := unix.Gettid()
        unix.SchedSetaffinity(tid, &cpuSet)
    }

The way I read this snippet is it pins the go runtime thread that happens to run this goroutine to a cpu, not the goroutine itself. Afaik a goroutine can move from one thread to another, decided by the go scheduler. This obviously has some merits, however without pinning the actual goroutine...

Re: CPU cache-friendly data structures in Go

#8

Post by hu3 » Thu, Oct 09, 2025, 3:15 PM UTC

> False sharing occurs when multiple cores update different variables in the same cache line.

I got hit by this. In a trading algorithm backtest, I shared a struct pointer between threads that changed different members of the same struct.

Once I split this struct in 2, one per core, I got almost 10x speedup.

Re: CPU cache-friendly data structures in Go

#9

Post by hu3 » Thu, Oct 09, 2025, 3:16 PM UTC

readthenotes1 wrote: post #4

I wonder how many nanoseconds it'll take for the next maintainer to obliterate the savings?

That's just one prompt away!

Re: CPU cache-friendly data structures in Go

#10

Post by spockz » Thu, Oct 09, 2025, 3:22 PM UTC

hu3 wrote: post #8

> False sharing occurs when multiple cores update different variables in the same cache line. I got hit by this. In a trading algorithm backtest, I shared a struct pointer between threads that changed different members of the same struct. Once I split this struct in 2, one per core, I got almost 10x speedup.

Interesting! Did you find out a way to bench this with the built in benchmarking suite?