21–30 of 71 posts
Earlier quoted context omitted.
Really? I know 1.5 is slower than previous versions, but it's still by far the fastest compiler I've ever worked with.
In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.
Earlier quoted context omitted.
In the global scheme of things it's still pretty fast, but builds on 1.5 take 2x the time of 1.4, it's pretty bad for existing golang users.
Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?
It seems they accepted this sacrifice for some other unimportant feature*
*edit: Looks as though the feature they sacrificed performance for was writing Go in Go.
Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ program.
Lua might be a decent option too.
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms.
Of course, if Go was just an LLVM frontend instead of using gcc then it wouldn't even need the platform specific C code... And it would support a shitton more platforms like asm.js. But I guess Google just hates Apple that much?
Earlier quoted context omitted.
Why is that a problem for you? With golint / gocode I never have any need for extremely fast compilation. What's your setup like that you're rebuilding so often?
Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling. It seems they accepted this sacrifice for some other unimportant feature* *edit: Looks as though the feature they sacrificed performance for was writing Go in Go.
This is one of Go's best features for me. You can trivially cross-compile statically linked binaries, copy them over to an ARM system and they run fine. Contrast that with C/C++ - sure you can cross-compile, and I have in the past, but it's a huge pain to set up and who ever remembers the command line options. Those "target triples" aren't even documented anywhere. Plus, good luck building a statically linked C++ pro…
What about LLVM? Go's support of cross compilation is laughable in comparison to the different LLVM backends. And you can just use the -arch armv7 and -arch arm64 shortcuts instead of those target triples. Also, FWIW, the reason why Go can even be cross compiled in the first place is because it has platform specific C and assembly code from cgo's runtime so it can support the different architectures/platforms. Of cou…
This is silly. Google contributes a huge amount to LLVM. They're very invested in the project.
(NB: I'm not defending, and don't agree with, the choice to avoid LLVM in Go.)
How about the support by the LLVM. Shouldn't this be enough?
Go already has 2 compiler implementations. There is gc (Go Compiler) and gccgo[0]. [0] https://golang.org/doc/install/gccgo
Earlier quoted context omitted.
Personally, my biggest beef would be that the go developers specifically stood against generics on account of compiler complexity => slow compiling. It seems they accepted this sacrifice for some other unimportant feature* *edit: Looks as though the feature they sacrificed performance for was writing Go in Go.
Compilation in Go remains lightning fast, again, faster than any other compiler I use; fast enough that it's sane to run the compiler every time I save a file so my editor can highlight the errors.
1) Perf for a product should be marked against some shipping benchmark and intermediate regressions don't matter as long as we come below the benchmark at ship time.
2) Perf improvements should be "locked in" and not regressed, unless strenuously justified.
I think the parent is of group (2), where it doesn't necessarily matter that it's better than the benchmark of "against other compilers" but only that Go regressed from their earlier perf metrics for what they believe to be inadequate justification.
I think both groups have valid points. I think (2) is especially good at preventing "perf creep" wherein you continually justify small perf regressions for new features, explaining it away that competitors are doing the same. Eventually, you get to the point where everyone's just slow, but they have no impetus to improve because they're still better than the competition.
Maybe I'm in the minority but I would rather have resources devoted to improving compile times in 1.5+ versions vs. having golang work on arm. Isn't the best course usually to build a solid foundation, then branch out?
ARM is really important. It's probably the fastest growing architecture other than x86 where people use things like this. I'd also like to see Go on MIPS64, though probably less important than ARM.
It's incredible to run buildall.sh on a recent go repo and see all the cross-compilers get built with no fuss or hassle. There are at least 30 different target platforms I can get to from my ubuntu box with a single command line. I'm not aware of anything that even comes close to tooling out cross compilation so easily.
I do nightly binaries for Prometheus in all the possible archs, while things should compile perfectly there can be small things that prevent things from cross-compiling. darwin/arm, darwin/arm64, plan9/386, plan9/amd64 and solaris/amd64 don't compile for any of the 11 binaries (e.g. plan9 doesn't work due to logrus not having support for it). This leaves me with the list at http://www.robustperception.io/prometheus-n…