4 ms·
As with all of these forays, I applaud the author for learning new things, but these benchmarks are primarily testing reading from stdin and format printing to
by lkey 5y ago
As with all of these forays, I applaud the author for learning new things, but these benchmarks are primarily testing reading from stdin and format printing to stdout, followed by testing bignum impls as mentioned elsewhere. For this reason, the title and benchmarks are a bit misleading.
- xxs 5y ago...also testing half-compiled code. JIT compiled tests that run few seconds just discredit their authors. It's yet another example of how not to perform microbenchmarks.
- twicetwice 5y agoWorth pointing out for those who don't know that the Java runtime does JIT optimizations of bytecode based on observed runtime patterns. Blew my mind when engineers were talking about "warming up the code paths" during startup of a large Java service and I found out it wasn't joke/superstition.
- mhh__ 5y agoI just tentatively found a 10% speedup in the D compiler frontend by enabling profile guided optimization.
- xxs 5y agoJava effectively always have guided compilation with perf. counters and all.
- xxs 5y agoWarming is a tiny part of microbenchmarking actually. Knowing how and what the compiler optimizes, like purpose lattice checks to ensure no extra array boundaries in the code. Call site optimizations (class hierarchy analysis) - single site (direct calls, inclines), dual site - guarded checks, vs 3-5 - inline caches vs. full virtual calls. Card-marking of stores for concurrent GC. L2 and L3 CPU cache sizes awareness (certain dataset may fit and the results are misleading)... There are a lot other techniques to consider, including looking directly at the assembly code. Microbenchmarking requires rather deep knowledge how the JIT works, how the hardware - CPU/cache/memory operates, the costs of calls certain system calls and what not.
- brabel 5y agoIt doesn't discredit anything. Sometimes what you care about is performance from cold start. Serverless And CLIs for example. JIT aint gonna help you there , and this problem falls into that category. EDIT: did you read the article? It is not a microbenchmark.
- kaba0 5y agoThat’s such an extreme niche that unless specifically pointed out, it should not be given such attention. But I do agree that the post is not a benchmark.
- xxs 5y agoIf you want a fast cli and java, you'd have the java process running and feed the input/output where by some means. Overall Java is not a good fit for a classic CLI, at least not with the JIT - it works in a pinch of course but it's well known it has a slow bootstrap. Of course I read the article, the benchmarks are at the end. The rest is about LoC (which is yet another benchmark, albeit even more useless). I even read all the code on github, there is a room for improvement there as well.