[generics] I think it's better have higher perfomance than lower compiling time

[Ronald Davilla]

Just if perfomance will decrease with every release/version, it'd be not really good, and it's might be necessary to pay more attention to this

[howar...@gmail.com]

I think in general this is not the attitude of the Go developers, nor the Go community - fast compilation was an explicit design goal of the original creation of Go (as a reaction to slow compile times with C++), and has remained a concern.

From the FAQ, https://golang.org/doc/faq#creating_a_new_language , " Finally, working with Go is intended to be fast: it should take at most a few seconds to build a large executable on a single computer."

It is certainly not their only concern or focus, they also mention "One had to choose either efficient compilation, efficient execution, or ease of programming; all three were not available in the same mainstream language."

We have seen performance decreases in some language versions, but we have also seen performance increases. Efficient execution is a project goal, but efficient compilation is as well, so I would not recommend hoping for or expecting that performance issues in execution would be resolved via additional passes in or excessive time added to compilation.

However, if you do see any major performance regression in a new version, do report it - they have historically paid attention to these reports and often resolved issues in subsequent updates; see https://github.com/golang/go/issues/19096 , https://github.com/golang/go/issues/16407 , and https://go-review.googlesource.com/c/go/+/30163/

Consider also these headlines:

Go 1.7 to Improve Compilation Speed and Generate Faster Code

Google's Go language takes on compilation speed (about Go 1.8)

Faster builds in Docker with Go 1.11

Howard

[David Skinner]

I remember going on a two-hour lunch break at a Cajun restaurant and returning to my office to discover that my precompiled C++ headers were still compiling. I really love that Go compiles quickly and links quickly.

The day comes when code needs to ship, final compile, and final quality control tests,  why not have a final build that compiles quite slowly and optimizes to the max. There is no need to do either/or and compromise, just do both.

On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:

[Tyler Compton]

The idea of having development and release compilation modes sounds appealing at first, though I'm a bit skeptical about how it would turn out. This would mean that, during development, you wouldn't have a full understanding of the performance characteristics of your program. Admittedly, that's not something you always care about, but when you do care you'll have to deal with slow compilation times.

I've found that in C++ certain memory safety bugs will only rear their ugly head after a certain compiler optimization level, meaning that these bugs can be missed during development. Go's memory safety would probably make this significantly less of a problem, but it still concerns me somewhat.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fd72210d-5a04-4be3-b51c-50b8313bf3dao%40googlegroups.com.

[Axel Wagner]

Why not just build your release-build with gccgo? It often already gives better performance than gc, AIUI. If enough of the people who really care about it would focus their energy on it, that could probably get even more pronounced. There's no reason that gc needs to grow optimization knobs, if you can just use a different compiler.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu1mBzN6YJJLtAOb1ZBPuDgXoCDzuG34x5XGPwTk1u-q8A%40mail.gmail.com.

[David Skinner]

Tyler Compton is correct. In the early 90s, the plethora of C++ optimization switches resulted in obscure memory errors which resulted in major software houses shipping bad products, declaring bankruptcy, and disappearing from the face of the earth like dinosaurs. I am totally opposed to optimization switches, reliability is number one, productivity is number two, speed is number three.

Fast compile times are not so fast on my machine because of comprehensive unit tests, but I am not willing to give up my unit tests.

I am only suggesting that we have a fast and slow compile.

[Jesper Louis Andersen]

On Fri, Jun 19, 2020 at 8:13 PM <howar...@gmail.com> wrote:

We have seen performance decreases in some language versions, but we have also seen performance increases. Efficient execution is a project goal, but efficient compilation is as well, so I would not recommend hoping for or expecting that performance issues in execution would be resolved via additional passes in or excessive time added to compilation.

It is important to look at the general trend, rather than single releases. If you restructure the internals of a compiler, you may have to accept a slight decrease for certain programs short term, only to win that in again in the long term as more optimizations come online in the new structure.

It is also a balance. If the program is small, then efficient compilation isn't that important. For large programs, where much of the code isn't traversed more than once, efficient compilation is very important. One thing I enjoy in Go is the fast compilation speed and feedback loop. And programs tend to be quite fast in Go as well, because you have good control over memory layout.

[Viktor Kojouharov]

I seem to recall that the compilation time of C (and C++) programs is directly proportional to the number of includes your program has. I'm sure that monomorphisation in C++ exacts some kind of cost to the compilation time, but perhaps it's not as much as people seem to think.