There are hardly any benefits in writing your web app in C ove r Java or Go. That 1% speed increase is nothing compared to the huge amount network wait these apps will be doing.
If you really consider it, what 95% of people write these days is glue between various services, and the parts that do matter, where you need the most performance, are already written in C. The reason why Redis, MongoDB and Postgres have good C bindings, because they themselves are written in C.
So when it comes down to it all you are really doing is string parsing and string transporting, thats really the last thing you want to leave to C. I haven't done straight-C code that has required me to do a lot of string manipulation, but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.
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.
> If you really consider it, what 95% of people write these days is glue between various services, and the parts that do matter, where you need the most performance, are already written in C.
I think that is absolutely on the money?... but what if you are building one of those components?... or what if you are writing a very thin wrapper on one of those components, and it is brand new and only has C bindings?... or what if you need to be portable to dozens of different platforms, many of which don't share much toolchain overlap except for gcc?
> but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
It's pretty easy to avoid that if you are worried about it. There are buffer/blob abstractions that give you "safe" interfaces with 0 risk of buffer overflow. Really, there is no good reason to have those unless you really are trading safety for performance.
> Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.
Sometimes you can, sometimes you can't. It depends on the problem... and your levels of skill with both Java & C.
> So when it comes down to it all you are really doing is string parsing and string transporting, thats really the last thing you want to leave to C.
Exactly. String parsing is the biggest shortcoming in C that always gives me a second thought when I'm about to choose a language for a higher level application (especially if it incorporates user input as strings). Even such trivial thing as AT command parser is a pain in C. Of course, there are parser generators as Bison, but still it's tedious amount of work and usually not worth it.
If you really consider it, what 95% of people write these days is glue between various services, and the parts that do matter, where you need the most performance, are already written in C. The reason why Redis, MongoDB and Postgres have good C bindings, because they themselves are written in C.
So when it comes down to it all you are really doing is string parsing and string transporting, thats really the last thing you want to leave to C. I haven't done straight-C code that has required me to do a lot of string manipulation, but I guarantee I'll probably leave a buffer overflow exploit open when trying to parse GET variables.
Or I can just do it in Java, and get all the performance and almost all the advantages of doing it in C.