feat: replaced unsafe pointer with atomic.pointer[T] for cleaner atom…

[mehrdad3301]

fixes issue.

[guycipher]

Was there perf done to see if this solution has benefits on throughput and latency? Comparing benchmarks even to prior. I do wonder besides that the code looks great but I’m always curious on those perf aspects.

[mehrdad3301]

I ran the default benchmarks and suprisingly there were some improvements

Benchmark Comparison: unsafe.Pointer vs atomic.Pointer[T]

Master Branch (unsafe.Pointer):

fillseq: 149,964.85 ops/sec
readrandom: 1,837,897.45 ops/sec
concurrent_writers: 154,459.93 ops/sec
Average: 219,194.10 ops/sec

Atomic.Pointer Branch:

fillseq: 159,338.64 ops/sec (+6.25% improvement)
readrandom: 1,985,226.34 ops/sec (+8.02% improvement)
concurrent_writers: 164,092.47 ops/sec (+6.24% improvement)
Average: 233,031.65 ops/sec (+6.31% improvement)

Performance Analysis:

fillseq: +6.25% faster (sequential writes)
readrandom: +8.02% faster (random reads)
concurrent_writers: +6.24% faster (concurrent writes)
Overall: +6.31% improvement in throughput

Latency Improvements:

fillseq P50: 12.5μs → 12.2μs (2.4% faster)
readrandom P50: 1.0μs → 875ns (12.5% faster)
concurrent_writers P50: 12.5μs → 12.7μs (similar)

---

I think that the Go compiler can optimize atomic.Pointer[T] better than manual unsafe.Pointer casts, leading to more efficient code generation. Another guess is that type-safe wrapper may improve memory layout and cache locality. I solely did this to improve code clarity, didn't think there were performance benefits associated

[mehrdad3301]

I have no idea why the tests for windows are failing. Do you think it's related to this PR or something we need to investigate separately ? @guycipher

[guycipher]

Good stuff, yeah windows is just generally slower the scheduler and stuff I think it may be a data race, I've reran with debug mode on. When I get to my computer I will pull your code and run it locally to see.

[guycipher]

Was a data race.