C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up.
It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for performance.
Modern JVMs do support SIMD vectorisation now and I've seen at least one example where JVM outperformed GCC 4.5 in loop vectorisation by 2x. There is no reason JIT compilers cannot do all the same SIMD optimisations that static compilers do.
If you want really top performance for non-trivial cases, e.g. matrix multiplication, I guess you need to probably vectorise by hand and go down right to assembly level.
> C and C++ compilers can produce faster execution than Go or JVMs as they support SIMD vectorization e.g. SSE/AVX. For CPU-bound workloads you can get more than 2x speed up.
This is an implementation issue.
Nothing prevents a compiler vendor to offer the same capabilities to their language compilers.
Vectorization is not part of ANSI/ISO C or ANSI/ISO C++.
For the time being, do you want vectorization in Go? Write a tiny assembler routine. Done.
It's an implementation issue that matters if you're writing a system that needs to offer high performance today.
Regarding writing assembly - that's fine, you could also write a routine in C and call it. The thrust of my comment is that it is untrue to argue that native Go and Java match the performance of C/C++. They don't. They might in the future.
sumatra is for parallelizing mainly on GPU, not for SIMD - current C/C++ compilers neither do that. Java has SIMD support for quite a long while now, probably since Java 6 or even earlier and generally C-like Java code using raw arrays and primitives is as-fast-as-C these days. I'd be more afraid of lack of true value types in Java. This one thing makes C still a better choice for high performance stuff.
It doesn't mean you should write your entire server stack in C vs calling a C function for heavy computation, but the idea that Java and Go approach 99% the speed of C/C++/Fortran is generally only true for programs that are not optimized for performance.