These are chat archives for HdrHistogram/HdrHistogram

21st
May 2018
Alec
@ahothan
May 21 2018 13:44
@mikeb01 could you confirm the C implementation is thread-safe for read? In my setting, I will have 1 same thread writing frequently to a histogram (add) and another thread reading from the same histogram (ie getting things like min/max/average/values from percentile/etc...). Given that all data structures are allocated up front and there is no dynamic extension I think it should be safe.
Gil Tene
@giltene
May 21 2018 14:11
@ahothan without surrounding locking, synchronization, or coordination, histograms on their own cannot be thread-safe for reads in the presence of concurrent writers. The “recorder” (Recorder and SingleWriterRevorder in the java implementation, hdr_interval_recorder in C) is the friendliest-to-writers form of coordination, and provides wait-free behavior for writers on architectures that support atomic add instructions (and lock free on there’s).
You can see a good example of its use in https://github.com/HdrHistogram/HdrHistogram_c/blob/master/examples/hiccup.c
Gil Tene
@giltene
May 21 2018 14:19
In java, We have Histogram (not threadsafe for anything), synchronizedHistogram (completely threadsafe but serialized for everything), atomicHistogram (lossless recording, with nothing else threadsafe), and ConcurrentHistogram (lossless recording, autosizing, and value shifting, nothing else threadsafe). I find that the Recorder and SingleWriterRevorder are the most common fit for actual use cases tho.
Gil Tene
@giltene
May 21 2018 14:34
@ahothan for slides, @alexvictoor did a talk at Devoxx France, which you can find here: https://www.youtube.com/watch?v=VIfo1i3Az3I . I don’t speak French, but I do speak HdrHistogram, so I could sort of follow along. The data structure discussion is about half way through.
Alec
@ahothan
May 21 2018 17:57
Thanks for the pointer @giltene, French is no problem for me ;-)
Alexandre Victoor
@Alex_Victoor_twitter
May 21 2018 18:40
Great! @ahothan I am happy to help if you need anything :)
Alec
@ahothan
May 21 2018 19:31
@giltene what I need in fact is to be able to keep recording values from 1 thread and get an encode of a snapshot from another.
I think working with 3 histograms to achieve this will work: 1 to aggregate, 1 to record live and 1 to swap out from the live recording to be added to the aggregate one.
with that I only need to protect the swapping of the 2 recording histograms
Marshall Pierce
@marshallpierce
May 21 2018 19:33
That's basically what a Recorder does
Alec
@ahothan
May 21 2018 19:36
@marshallpierce thanks for the tip and I should have read the code of the recorder more carefully - although I see that it is just using 2 histograms, one active and 1 inactive
ok with that implementation the swapping cost would be equal to the cost of adding a histiogram to another
Marshall Pierce
@marshallpierce
May 21 2018 19:37
Keep one to aggregate into, and use the recorder to swap between hot/cold histograms. Each time you swap, add the now-cold histogram into the aggregator.
Alec
@ahothan
May 21 2018 19:37
while what I was looking at would just be the cost of swapping 2 pointers
Marshall Pierce
@marshallpierce
May 21 2018 19:38
Well, swapping pointers plus the necessary thread safety, right? :)
Alec
@ahothan
May 21 2018 19:38
cost of adding a histogram to another would probably be in the 10s to 100s usec I guess
Marshall Pierce
@marshallpierce
May 21 2018 19:38
sure but that's off the critical path
Alec
@ahothan
May 21 2018 19:38
not with 2 histograms
Marshall Pierce
@marshallpierce
May 21 2018 19:39
OK, let me explain with some pseudocode.
I'm assuming the C api supports providing the recorder a snapshot to write into (the Java one does) so that it remains allocation-free
Alec
@ahothan
May 21 2018 19:43
ok thanks on L19, while you're adding snapshot to aggregate (non atomic), snapshot can be changed?
Marshall Pierce
@marshallpierce
May 21 2018 19:43
no, because the recorder has given it to you for you to do what you want with.
You've given it another one to write to in the meantime, and its job is to handle the thread safety aspects of switching them out
Alec
@ahothan
May 21 2018 19:44
ok so we basically have 3 histogram instances total no?
Marshall Pierce
@marshallpierce
May 21 2018 19:44
Yup! And you don't have to write the thread safety yourself. :)
(I should really get around to implementing Recorder for the Rust version; it's so useful)
Alec
@ahothan
May 21 2018 19:45
ok I agree, it is the same scheme I was thinking about
I'm so glad @mikeb01 implemented it in C !!
Michael Barker
@mikeb01
May 21 2018 21:14
@ahothan I make no guarantees about the thread safety of the C HdrHistogram :-).
At the moment it will probably work with a single writer multiple read model, but in the future I was thinking about adding the ability to dynamically grow (it's on the list of features), which would break that. So definitely going with the recorder is the best approach.
@ahothan Last time I benchmarked I was getting around 100M per second, so about ~10ns per recording. Gil is correct that the Java version can beat the C version with it's aggressive JIT.
Michael Barker
@mikeb01
May 21 2018 23:33
Just retested. With a release build (-O3) on Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz I get 160M ops/sec. With a debug build (-O0) that drops to 24M ops/sec.
Michael Barker
@mikeb01
May 21 2018 23:38
That compares with 213M on the Java version.
Alec
@ahothan
May 21 2018 23:54
@mikeb01 do you use any special flag for cmake? My numbers is close to your debug number
I am vexed ;-)