Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you are implying that it is the "optimizing compiler" I mentioned, I have not seen good performance numbers that show it as being any better than the official Go compiler.

Were I going to start the company to produce the compiler, the question of "why isn't gccgo about 2x faster than Go?" is one of the first I'd examine, though. I personally have zero idea what the answer is. Or, indeed, if it's even still true. However, I am active enough in the Go community that if good benchmarks were going around I'd expect to have seen them. (They'd probably make it to HN.)



I rarely hear much about gccgo than what I hear in the Go release notes (usually "gccgo is now feature complete at <old version>"). I wonder if it still uses the plain thread implementation of goroutines like it did early on (which provides quite different performance characteristics)?

I am frankly too lazy to set up gccgo for comparisons again, but if I recall correctly, it takes considerably longer to compile whilst providing similar quality output. Thus, I would ask the opposite question that you presented:

If gccgo isn't notably faster than gc, why is compilation so much slower?

If one compiler spends more time generating identical quality output with an identical input language, it is hard to argue against the fact that there are wasted cycles at play. It may of course partly be due to an immature Go frontend. Who knows.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: