You can look at things like concurrent skip lists and for large data sets with persistence, log sequential merge trees. On Mar 14, 2025, at 1:20 AM, Jason E. Aten <j.e.a...@gmail.com> wrote:
(If that seems surprising, the reason is mentioned in the sibling c++ library announcement: "performance in these cases is effectively governed by the number of cache misses, not the number of key-compare operations" -- https://opensource.googleblog.com/2013/01/c-containers-that-save-memory-and-time.html ... so the game turns into how few pointers you can chase. Turns out in memory b-trees are great for this. On Friday, March 14, 2025 at 6:09:56 AM UTC Jason E. Aten wrote:
I do keep seeing references to Java concurrent stuff people are porting to Go. I have to check it out.
I need an ordered k/v store (find the next key greater-than)... and I was trying to see how turns out, at least in single goroutine form, wipes the floor soundly against red-black trees and radix trees. It's even way faster than the built in Go map, while giving ordered key lookup, not just hash table operations. The only trade-off is that it is suuuuper slow for deletes.
On Friday, March 14, 2025 at 5:32:08 AM UTC Robert Engels wrote:
I know some people are put off by stuff like this, but reading the Java JDK concurrent package provides a wealth of information- it is well documented and almost all are referenced implementations of academic papers. In this case, the Java concurrent hash map would be an applicable design.
oh nice. I like the hashing idea to pick a shard lock out of array...that way
I don't have to stick locks on, and bloat, every node in the btree. I can just take the hash value modulo a the size of a fixed set of locks... Thanks Robert.
p.s. awl, thanks, yes... saw that. thank you.
On Friday, March 14, 2025 at 4:29:46 AM UTC Robert Engels wrote:
I think it is easier to just hash and shard the data set the lock is protecting - ie a lock per shard.
Is there a common way to do sharded read-write locks now?I mean faster than sync.RWMutex.
while back...
Have you read the original thread that spawned this, you might find it pretty informative if not:
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/d3081e16-37f2-4509-95d6-9cbd32bb38ebn%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/B0944270-4B45-45D5-BF21-EBD71316D5AF%40ix.netcom.com.
|
