On 18.02.2016 16:00, Jonas Scholl wrote:
While your code does not contain any conflicts, the stm-stats library seems to contain some. Replacing trackNamedSTM with atomically speeds things up quite a bit, so most of the time is lost in the library. A short look at the code of the library shows that it uses atomicModifyIORef on some global IORef holding a map of the statistics.
Yes, the instrumentation was the culprit. Thank you! I'm trying to come up with a (Ord a, Hashable a) => STM (Set a), internally partitioned for reduced contention. Looks like my code for the Set itself was right, but my code for testing it was ...four transactions, inserting one milion elements each. This coudn't have worked well, I don't know why it worked at all. Now that I switched to four million transactions, inserting one element each, things work much better. Perhaps not great, as the 1 OS thread case is still the fastest, but 4 OS threads are much faster on the partitioned set then on its unpartitioned counterpart. Overall, inserting transactionally four milion Ints into a Set in one second ain't bad at all. Counting them afterwards takes much longer... -- Wojtek