12
top 3 comments
sorted by: hot top controversial new old
[-] Alonely0@mastodon.social 6 points 1 year ago* (last edited 1 year ago)

@Arbitrary I did this a while ago, you might find it useful. It abandons the more traditional vector concept of sequential insert, so that remove() can be implemented. https://github.com/Alonely0/Lariv

[-] Arbitrary@reddthat.com 3 points 1 year ago

Neat work, I'll be sure to take a peek later.

[-] o11c@programming.dev 2 points 1 year ago

chunks: [AtomicPtr>; 64], appears before the explanation of why 64 works, and was confusing at first glance since this is completely different than the previous use of 64, which was arbitrary. I was expecting a variable-size array of fixed-size arrays at first (using something like an rwlock you can copy/grow the internal vector without blocking - if there was a writer, the last reader of the old allocation frees it).

Instead of separate flags, what about a single (fixed-size, if chunks are) atomic bitset? This would increase contention slightly but that only happens briefly during growth, not accesses. Many architectures actually have dedicated atomic bit operations though sadly it's hard to get compilers to generate them.

The obvious API addition is for a single thread to push several elements at once, which can be done more efficiently.

this post was submitted on 30 Jul 2023
12 points (100.0% liked)

Rust

5754 readers
25 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS