I'm skeptical.
If it can prove that the input actually matches the hint, then why does it need the hint?
If it can't, what happens at runtime if the input is something else?
> We replaced a complex chain of method calls with one CPU instruction.
JVM bytecodes and CPU instructions really shouldn't be conflated like that, although I assume this was just being a bit casual with the prose.
I'm not certain I understand your first point. When I add the type hint, it's me asserting the type, not the compiler proving anything. If the value at runtime isn't actually a byte array, I would expect a ClassCastException.
But I am new to Clojure, and I may well be mistaken about what the compiler is doing.
(And the possible "JIT hotpath optimization" could be something like, at the bottom level, branch-predicting that cast.)
ClassCastException
If the whole enclosing function became inlinable after the reflective call path disappeared, that could explain why the end-to-end speedup under load was even larger than the isolated microbench.
I admit that I don't understand the JIT optimization deeply enough to say that confidently... as I mentioned in the blog post, I was quite flummoxed by the results. I’d genuinely love to learn more.
Oh that's cool. Apparently one of the protocol's goal is to catch lying parties and to prove they were lying about the (rough) time.
The ecosystem is currently very young. Each additional deployment meaningfully strengthens the ecosystem (ours is only the fifth server) and each additional implementation helps harden the spec (which is soon approaching 1.0).
We wrote a bit more about it in a separate article: https://blog.sturdystatistics.com/posts/roughtime/
Official protocol document: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-roughti...
