puzpuzpuz-hn

4 ms·

1. 1.▲
   by puzpuzpuz-hn 4mo ago

   Thanks! We do our best to be as transparent as possible when it comes to benchmarking.
2. 2.▲
   by puzpuzpuz-hn 4mo ago

   Thanks for the reference. Will check!
3. 3.▲
   by puzpuzpuz-hn 4mo ago

   Exactly! The task gets even trickier when you're benchmarking lots of systems of different kinds: cloud databases, self-hosted ones, embedded engines, CLI tools.
4. 4.▲
   by puzpuzpuz-hn 8mo ago

   Allocation rates comparison is included. If your application writes into the map most of the time, you should go with plain map + RWMutex (or orcaman/concurrent-map). But if, for instance, you're using the map as a cache, read ope
5. 5.▲
   by puzpuzpuz-hn 8mo ago

   Thanks. There are downsides in each approach, e.g. if you care about minimal allocation rate, you should go with plain map + RWMutex. So yeah, no silver bullet.
6. 6.▲
   by puzpuzpuz-hn 8mo ago

   Unsafe usage in the recent xsync versions is very limited (runtime.cheaprand only). On the other hand, your point is valid and it'd be great to see standard library improvements.
7. 7.▲
   by puzpuzpuz-hn 8mo ago

   My box is 12c/24t only, so it won't make any difference. But on a beefy box, it may improve performance in high cardinality key scenarios.
8. 8.▲
   by puzpuzpuz-hn 8mo ago

   There are multiple GH issues around better sync.Map. Among other alternatives, xsync.Map is also mentioned. But Golang core team doesn't seem interested in sync.Map (or a generic variant of it) improvements.
9. 9.▲
   by puzpuzpuz-hn 8mo ago

   Would be great to see that - there are multiple GH issues for that. But so far, I'm not convinced that Google prioritizes community requests over its own needs.
10. 10.▲
    by puzpuzpuz-hn 8mo ago

    Allocation rates are also compared. Long story short, vanilla map + RWMutex (or a sharded variant of it like orcaman/concurrent-map) is the way to go if you want to minimize allocations. On the other hand, if reads dominate your worklo
11. 11.▲
    by puzpuzpuz-hn 8mo ago

    Yup, that's a valid point. I'll consider adding these metrics.
12. 12.▲
    Benchmarking 5 concurrent map implementations in Go (incl. sync.Map)(github.com)

    1 points by puzpuzpuz-hn 8mo ago|1 comments
13. 13.▲
    by puzpuzpuz-hn 8mo ago

    Benchmarks for 5 concurrent hash map implementations in Go: sync.Map, xsync.Map, cornelk/hashmap, alphadose/haxmap, and orcaman/concurrent-map. Workloads: read-heavy to write-heavy (100%/99%/90%/75% reads), wit
14. 14.▲
    by puzpuzpuz-hn 2y ago

    Nice article, thanks for sharing it. It's a pity kdb+ has a DeWitt Clause, so that no one can benchmark it against other databases from the article. I wonder if they have any public benchmarks held by a 3rd-party.
15. 15.▲
    by puzpuzpuz-hn 3y ago

    Hi, if you're asking about the hash table itself, then currently we use linear probing, i.e. k/v pairs with a collision are inserted sequentially starting with the hash%capacity index.
16. 16.▲
    by puzpuzpuz-hn 3y ago

    That's correct. In practice, there is an insignificant amount of hash collisions, so false comparisons are extremely rare. And thanks for sharing your experience with RH and the links!
17. 17.▲
    by puzpuzpuz-hn 3y ago

    > Unless I'm missing something, hashing function is fast compared to random bouncing around inside ram – very much faster then random memory accesses. So I can't see how it make a difference. In a GROUP BY, you may have a few h
18. 18.▲
    by puzpuzpuz-hn 3y ago

    Thanks, Gavin, I'm pleased to hear that. And thanks for recommending my blog!
19. 19.▲
    by puzpuzpuz-hn 3y ago

    Thanks! We're still benchmarking Robin Hood hashing and are open to further experiments. The benchmarks look promising.
20. 20.▲
    by puzpuzpuz-hn 3y ago

    > Obviously, it's a bit sad when due credit is not given where it should be The post actually references your paper. :)
21. 21.▲
    by puzpuzpuz-hn 3y ago

    Yes, the core idea is pretty close to Epoch-based synchronization.
22. 22.▲
    Optimizing the Optimizer: The Time-Series Benchmark Suite(questdb.io)

    2 points by puzpuzpuz-hn 3y ago|0 comments
23. 23.▲
    by puzpuzpuz-hn 4y ago

    Recently we've started using io_uring for disk access in QuestDB. So far, it's being used in CSV import, but we'd like to expand it to network and other disk access use cases. Apart from the performance boost, the beauty of i
24. 24.▲
    So long, Golang's sync.Map(puzpuzpuz.dev)

    1 points by puzpuzpuz-hn 4y ago|0 comments
25. 25.▲
    Fast and Simple SPSC Queue Written in Java(puzpuzpuz.dev)

    4 points by puzpuzpuz-hn 4y ago|0 comments