News for hackers. Stuff that matters.

redixhumayun

Re:AI Coding on Thursday September 18, 2025 @01:18AM (#45285716)
> AI has also been a really good brainstorming partner - especially if you prompt it to disable sycophancy.

Can you share more about how you are prompting to disable sycophancy?

Has NewSQL really stalled though? Yugabyte, Cockroach & Spanner all seem to be doing fine?

Hyper even got acquired by tableau a few years ago

Re:Cache Conscious Hash Maps on Wednesday January 29, 2025 @09:48AM (#42865485)
A little trip down performance testing lane as a way to get familiar with the tooling around profiling and performance testing.

Led to a few happy discoveries of compiler optimizations in Rust.

Re:Visualising Extendible Hash Tables on Tuesday February 06, 2024 @09:49AM (#39274750)
I wrote a little bit about extendible hash tables and put some effort into creating visualisations around them. Mostly because this is something I struggle with when learning about a new topic - how to "see" what's happening
Re:Atomics and Concurrency on Friday January 12, 2024 @08:49AM (#38967875)
This is awesome! Also, I'm pretty sure I've come across your repo before from a SO answer (if I remember correctly)
Re:Atomics and Concurrency on Friday January 12, 2024 @08:47AM (#38967851)
Honestly, now that I look back at it having written it a couple of weeks ago, it doesn't feel that long. But, writing it felt incredibly wrong because I was encountering memory models for the first time.

I think for someone who has no exposure to it before, its quite dense (perhaps long wasn't the best choice of wording)

Also, I've been meaning to read The Art of Multiprocessor Programming. I've heard great things about it!

Re:Atomics and Concurrency on Friday January 12, 2024 @08:45AM (#38967830)
That concurrent queue is only there to illustrate usage of CAS in a data structure. I think having an actual implementation of a concurrent queue along with handling the ABA problem might be an entirely separate post.

I added in a note about the ABA problem but perhaps you're seeing a cached version of the post.

Re:Atomics and Concurrency on Friday January 12, 2024 @08:43AM (#38967808)
Yeah, I see your point about thinking in terms of dependency graphs. I actually got the idea for using a visual memory barrier from the Linux docs(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) and the C++ concurrency in action book.

>I guess the missing bit is that beyond the hardware fences you have the hardware cache coherency protocol that makes sure that a total order of operations always exist once load and stores reach the coherence fabric.

Can you explain more about this?

Re:Atomics and Concurrency on Friday January 12, 2024 @05:57AM (#38966569)
I assumed what the poster above meant was that Rust can take care of more than just data races. Specifically Rust can solve the ABA problem somehow?
Re:Atomics and Concurrency on Friday January 12, 2024 @05:54AM (#38966539)
Hey, so I'm curious why having memory barriers span across threads is the wrong mental model.

Assuming that the memory barrier is syncing across a single variable (in this case ready), why would it be correct to think of it as two separate barriers? If it were correct to think of it as two separate barriers on two separate threads, wouldn't there need to be some form of synchronization or linkage between the two barriers themselves so that memory barriers can be coupled together?

For instance, if I had release-acquire models on two variables, ready and not_ready, using separate barriers as representation might look something like this

```

  Thread 1                Memory                  Thread 2
  ---------               -------                 ---------
  |                          |                          |
  |   write(data, 100)       |                          |
  | -----------------------> |                          |
  |                          |                          |
  | ====Memory Barrier====== |                          |
  |   store(ready, true)     |                          |
  | -----------------------> |                          |
  | ====Memory Barrier====== |                          |
  |                          |                          |
  | ====Memory Barrier====== |                          |
  |   store(not_ready, true) |                          |
  | -----------------------> |                          |
  | ====Memory Barrier====== |                          |
  |                          |                          |
  |                          | ===Memory Barrier======= |
  |                          |   load(ready) == true    |                   
  |                          | <----------------------  |
  |                          | ====Memory Barrier=====  |
  |                          |                          |
  |                          |.===Memory Barrier======= |
  |                          |   load(not_ready) == true|                   
  |                          | <----------------------  |
  |                          | ====Memory Barrier=====  |
  |                          |                          |
  |                          |       read(data)         |
  |                          | <----------------------  |
  |                          |                          |
```

Now, how does the processor know which memory barriers are linked together? I ask because without understanding which barriers are linked together, how is instruction re-ordering determined?

Re:Atomics and Concurrency on Friday January 12, 2024 @04:18AM (#38965847)
How would Rust solve this problem?
Re:Atomics and Concurrency on Friday January 12, 2024 @04:01AM (#38965726)
Are there tools out there that can prove semantic invariants in multi-threaded code? I don't understand how there can be automated tools around it at all because how would that even be possible?