These are chat archives for HdrHistogram/HdrHistogram

18th
Dec 2014
Kyle Kingsbury
@aphyr
Dec 18 2014 02:28
Hi there!
Gil Tene
@giltene
Dec 18 2014 02:29
Looking at your DoubleHistogram encode/decode fail case now.
Kyle Kingsbury
@aphyr
Dec 18 2014 02:29
Only got a few minutes before I gotta head out, but I wanted to let you know I'd be happy to help with SignedHistogram's logic. :)
Gil Tene
@giltene
Dec 18 2014 02:29
You mentioned corner cases to watch for.
Kyle Kingsbury
@aphyr
Dec 18 2014 02:29
I also have extensive test.check infra in place which helped me work through a bunch of bugs, so if you want validation just let me know and I'll give it a whirl. :)
Yeah, there's a bunch of wrong ways to do the arithmetic for negative offsets which are right in the limit as n -> inf, but wrong for small n
Gil Tene
@giltene
Dec 18 2014 02:30
That's cool! (the test.check stuff). I might just want to add that into the Java set of tests.
Gil Tene
@giltene
Dec 18 2014 02:32
BTW, do think wrapping the Java version for Clojure is so lightweight that there is no point in putting up a version for others to use?
I don't do much clojure (I can read it, sort of), so I really don't know how much pain/effort we can save people by providing the clojure-dialect thing
Kyle Kingsbury
@aphyr
Dec 18 2014 02:34
I essentially wrapped the native types in a protocol for Tesser
and I could happily extend that to a proper clj-hdr-histogram library
But I'm not sure if there's any real benefit; the API is pretty much 1:1
Gil Tene
@giltene
Dec 18 2014 02:35
It would it save someone who wants to use it from clojure some work. But on the other hand, they'd probably still go read the JavaDoc.
Kyle Kingsbury
@aphyr
Dec 18 2014 02:35
For sure. I had to do a fair bit of source digging to use it, and I'm still not sure I understand it all.
I can certainly seed a project, but I dunno if I've got time to track upstream changes aggressively
Gil Tene
@giltene
Dec 18 2014 02:36
If I keep the API stable, there shouldn't be much to track.
Kyle Kingsbury
@aphyr
Dec 18 2014 02:38
Is that test.check case readable at all? Any translation I can do for you?
Gil Tene
@giltene
Dec 18 2014 02:39
I'm mostly looking at the value sets that replicate the problem. I'll do a JUnit test with those and debug
Kyle Kingsbury
@aphyr
Dec 18 2014 02:39
(basically (.call object arg1 arg2) -> object.call(arg1, arg2)
Righto. I gotta head out, but I'll be back online tomorrow morning PST!
Gil Tene
@giltene
Dec 18 2014 02:42
Ok. seeya.
Michael Barker
@mikeb01
Dec 18 2014 02:42
@giltene BTW, I'm just about to commit the c version of atomic histogram.
Gil Tene
@giltene
Dec 18 2014 02:43
And what about ConcurrentHistogram?
Well, until you do auto-sizing and value shifting in C, you won't need a ConcurrentHistogram equivalent.
Michael Barker
@mikeb01
Dec 18 2014 02:44
On the list. Managed to make the data access abstract with some function pointer stuff, and it doesn't seem to cost too much. Having a null check on the function pointer and having a built in default implementation seems to save about 10% performance.
I'll probably do the double histogram next where that stuff will start to come into play.
Gil Tene
@giltene
Dec 18 2014 02:45
The logical order is: DoubleHistogram needs value shifting in Histogram.
And Value shifting in histogram is not supported in AtomicHistogram, only in ConcurrentHistogram
Michael Barker
@mikeb01
Dec 18 2014 02:46
I've done the index normalisation part of that, but need to deep dive in double histogram to understand the rest.
Gil Tene
@giltene
Dec 18 2014 02:46
And without MT-safe value shifting you can't have an atomic/concurrent DoubleHistogram
So ConcurrentHistogram really came about to support safe multi-writer DoubleHistigrams (ConcurrentDoubleHistogram).
Michael Barker
@mikeb01
Dec 18 2014 02:48
I see that is uses the WriterReaderPhaser under the covers.
Gil Tene
@giltene
Dec 18 2014 02:48
The auto-sizing thing is just cool for all forms, and again, needs ConcurrentHistogram for safe MT support