I take your point, and maybe comparing against C++ is not “fair”. But, as a programmer, you must be aware of the trade-offs you are making.
As I stress in the post, I do like Go.
wmusays:
When we change Daniel’s procedure and pass the length as a parameter, a decent GCC is still able to inline call with the compile-time constant (and unroll the loop accordingly, even using SIMD instructions).
The assembly does not look nice. I give the full command one needs to input to generate the assembly, but I omit the assembly because it is quite verbose.
This being said, the assembly produced by modern-day programming languages is often hard to parse. That’s not necessarily a bad sign… programming languages have gotten more sophisticated and they need to do more…
This makes it harder for programmers to understand the trade-offs involved because so much more is hidden away.
wmusays:
They have replaced the compiler a year ago (or so). It would be nice to recheck the code from your article.
I mention clang in my post (LLVM). For this example, it makes no difference whether you use GNU GCC or LLVM’s clang.
I would not expect good things out of gccgo.
Oren Tiroshsays:
I suspect Swift (llvm based) will optimize the equivalent code nicely.
Not an Apple fanboy here. I almost missed this really nice language because I treated it as “that language for writing iPhone apps”. It is fully supported on Linux and deserves at least as much attention as Go.
The thing is, that’s really unsafe code.
I take your point, and maybe comparing against C++ is not “fair”. But, as a programmer, you must be aware of the trade-offs you are making.
As I stress in the post, I do like Go.
When we change Daniel’s procedure and pass the length as a parameter, a decent GCC is still able to inline call with the compile-time constant (and unroll the loop accordingly, even using SIMD instructions).
Take a look: https://godbolt.org/g/ZzBvJu
I have not checked, but I suspect that Go won’t inline, let alone use SIMD instructions in this scenario.
I need to look at the generated code by the Go compiler from 2017, back in 2014 I take a look at the generated code and it was terrible!
http://www.secnews.pl/2014/09/05/technologiczna-bieda-kompilatora-go/
You can look at the assembly output from my examples, it looks worse than hand written assembly.
The assembly does not look nice. I give the full command one needs to input to generate the assembly, but I omit the assembly because it is quite verbose.
This being said, the assembly produced by modern-day programming languages is often hard to parse. That’s not necessarily a bad sign… programming languages have gotten more sophisticated and they need to do more…
This makes it harder for programmers to understand the trade-offs involved because so much more is hidden away.
They have replaced the compiler a year ago (or so). It would be nice to recheck the code from your article.
How do gccgo or llvm compare?
I mention clang in my post (LLVM). For this example, it makes no difference whether you use GNU GCC or LLVM’s clang.
I would not expect good things out of gccgo.
I suspect Swift (llvm based) will optimize the equivalent code nicely.
Not an Apple fanboy here. I almost missed this really nice language because I treated it as “that language for writing iPhone apps”. It is fully supported on Linux and deserves at least as much attention as Go.
You are correct regarding Swift.
DLang vectorizes this nicely. Look at https://godbolt.org/g/J6Sx6N
Can the D compiler recognize that the parameter is effectively a constant and optimize accordingly?