As the saying goes, "there are lies, damned lies and benchmarks."
Java is particularly difficult to get good benchmarks in due to the nature of HotSpot and JIT compilation. I was listening to James Gosling recently and he pointed out that there are over 100 flavors of JIT compilation on the JVM for x86 alone. Essentially the JVM can tweak the compilation parameters for the specific processor it is running on. HotSpot also requires warm up time for it to observe sections of code that are running repeatedly which it then inlines and otherwise optimizes and will JIT compile that optimized code as well. That doesn't even get into the JVM version or the type of code being run. Where the JVM is really going to hit its stride is when you have long running code with a lot of libraries where the JVM can profile the code and optimize it over time. I'm a big fan of Go and prefer coding in it but that the JVM ran their code a bit faster doesn't surprise me nor does it surprise me that the footprint was larger. That's a big concern in the Dockerized world. If every container has to has its own JVM before you even start, the memory, thread and other resource overhead can get daunting. Like any geek, I like benchmarks but just have to take them with a grain of salt. On Wednesday, March 6, 2019 at 7:44:21 AM UTC-6, Robert Engels wrote: > > As I pointed out long ago on stackoverflow the benchmark games are > seriously flawed and should not be used for language performance > comparisons. > > As a simple example, look at binary trees. In all of the “fast” > implementations, they resort to specialized memory pools that wouldn’t be > useable in a highly concurrent system. The Go and Java versions use off the > shelf memory management so the code complexity comparisons are not even > close. I’m sure you could replicate the performance using off heap > structures in Go/Java but who would want to? > > On Mar 6, 2019, at 7:17 AM, Haddock <ffm...@web.de <javascript:>> wrote: > > Benchmarks are always limited, I know. But this might indicate some > direction: > > > https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html > > Am Mittwoch, 6. März 2019 14:07:03 UTC+1 schrieb JuciÊ Andrade: >> >> That doesn't surprises me at all. >> >> A couple years ago I worked for a company where I created prototypes in >> Go and production code in C++, using the same architecture and algorithms. >> Go version usually ran 15% faster. After some work both versions could be >> tuned to run faster, but it amazed me to find that just plain Go code was >> faster than the corresponding C++ code. >> >> On Thursday, February 28, 2019 at 2:05:55 PM UTC-3, Isaac Gouy wrote: >>> >>> "We reimplemented elPrep in all three languages and benchmarked their >>> runtime performance and memory use. Results: *The Go implementation >>> performs best*, yielding the best balance between runtime performance >>> and memory use. While the Java benchmarks report a somewhat faster runtime >>> than the Go benchmarks, the memory use of the Java runs is significantly >>> higher." >>> >>> proggit discussion >>> <https://www.reddit.com/r/programming/comments/avsfc6/performance_comparison_of_go_c_and_java_for/> >>> >>> article <https://doi.org/10.1101/558056> >>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
