These are chat archives for HdrHistogram/HdrHistogram

Sep 2017
Gil Tene
Sep 15 2017 05:04
Sorry about the late attention to the above. Just got my head above water...
Gil Tene
Sep 15 2017 05:10
I'm good with documentation that gives us a way to say "we told you so" when we end up being one bucket off and such. However, I still want to aim for principle of least surprise where possible. The original behaviors (rounding to nearest or truncating) clearly produced some surprising behaviors (seen if we scroll way way up in this thread) in some easy to hit cases. I think that the various prev stuff we've played with help reduce the surprising cases, but does not eliminate them. There will always be the potential for off-by-count-fp-edge things that turn into off-by-1000000x--in-reported-value behavior (the skip in count can move you across a wide swath of empty buckets), but these occurrences will be right at the noise point, in places that could've/would've happened with +/- one recorded value count too.
The important question for us is actually what we do about math across implementations. I think that the best thing will be to accept that math is allowed to be "slightly different" between implementations, and have our tests that examine common data (e.g. like reference logs and recordings used in tests) deal with fp with a +/- allowed window (that will match the leeway we leave in documentation).
I don't want to try to force all implementations to do the math at the edges the exact same way...
On a separate note: I just released the Java version of HdrHistogram 2.1.10.
Gil Tene
Sep 15 2017 05:15
The release was driven by Java 9. Java 9 broke previous versions, and fixing it so it will work on Java 9 but not break on 6 and 7 took a bunch of ugly gymnastics. See for some serious pretzel twisting examples needed to support Base64 encode and decode across Java 6...9 with the same source code.
I've gotta say, if this is what common libraries on maven central need to do to support Java 9 and not break Java 7 or 6, we're in for a long transition period to Java 9. It will take a while before "doesn't work with Java 9 yet" becomes rare enough for common libraries that large scale things with lots of dependencies will be deployable.
E.g HdrHistogram didn't compile with 9 until now, and some classes (the stuff that did Base64 encode/decode for communicating stuff) wouldn't run on Java 9 either. There is other stuff out there (e.g. Netflix Hystrix) that depends on HdrHistogram, which probably means that stuff didn't work on 9 until now (and may still not work for other reasons). The chains of this sort of stuff will be loooonnnnnngggg.
Friends don't let friends actually delete deprecated methods!
Marshall Pierce
Sep 15 2017 11:52
Yuk, that base64 thing is unpleasant. We seem to have dragged a Scala-esque version transition onto ourselves... I haven't tested my various OSS libraries with the Java 9 pre-releases either; I should get around to that. It seems like the module system is great for the developers of the JVM, and not so useful for everyone else.
Anyway, I'm glad my math rambling seems sensible... reading back, it doesn't seem like I'm foaming at the mouth from floating-point brain fever too badly. ;) I'll start preparing another branch that doesn't have all the extra exploratory tests in it that could actually be merged. I think one other output that would be a good outcome of this whole exploration would be to have some documentation summarizing what we've learned. Where would be a good place for that? Java impl's README? A hypothetical new repo for design documentation?
Marshall Pierce
Sep 15 2017 11:58
This might also be a good impetus for starting on a corpus of test data we could use for cross-implementation comparisons. Aside from figuring out what all the different build system bits would have to be, I think the hard part on that might be figuring out how to specify tests that go with a particular serialized histogram. How might we say "the 0.99805 quantile is 19961, or maybe the next higher value" in a cross-language way?
Sep 15 2017 16:07
I like the approach of best effort per language/implementation. I think the test code should reflect that and allow for match on exact or next higher value on all languages, to highlight that difference.
I am glad I don't have to deal with the Java 9 compatibility hurdles ;-)