freenode/#sicl - IRC Chatlog
Search
5:38:54
no-defun-allowed
Though, I did write up another test suite for concurrent hash tables, this one simulating a bad knock-off of an in-memory database (such as Redis), which retrieves and stores stuff in a concurrent hash table. Luckless scales way better than my old segmented hash table at that.
5:41:55
no-defun-allowed
I think that is closer to the scenarios Cliff Click et al put concurrent tables in, as they don't remove anything. It's a bit funny, because I got the idea from a presentation where an Amazon Web Services spokesperson complained about stop-the-world pauses while implementing such a database. Writing to the database is one big memory leak, so if you didn't have to retrieve the values, then you could just never free
5:45:50
no-defun-allowed
Said person also used a non-concurrent hash table with a lock, had unnecessary copying, so I don't think they can talk, but I digress. I saw where that table design works best, and it's really good there.
9:22:19
no-defun-allowed
I'll have to plot my own CPU count/time so I know when to start worrying about locking.
9:30:18
no-defun-allowed
Conclusion: there is insufficient data to draw a conclusion, so clearly I should be panicking now.
15:30:26
shka_
i am under impression that this implies the uniform access of all >50 CPUs to one specific lock, and this is not very common i think