Original post

Hi, i have been wondering if a compiler written in it’s own language ever be better than the parent language compiler written in a particular language? Like in this case, can a -based compiler generate outcome better than that of the parent C-based compiler? I guess performance wise it will be either equivalent or lower in performance (as size of generated assembly code increases with new complex features). Had published a small article on the subject here.

Wouldn’t maintaining & improving a C-based Go Compiler be a better option from performance and optimization point of view? I do understand that having a higher level language for the compiler code enables the community to contribute more, and makes writing newer features easier, but doesn’t comfort & ease of writing also lead to loss of performance / optimizations? I am just a little worried if Go based programs may end up being slower in future (losing it’s USP), like the way Java has been.

These are just my raw thoughts, looking forward to thoughts & views of the community & core contributors.

There is no parent-child relationship between Go and C. (And would a C compiler then be better if written in B or assembler?)

Besides, Go provides easy concurrency which the Go compiler utilizes. This likely makes it faster then a similarly complex C implementation on current multi core machines.

But if Go 1.5 compiler is written in Go 1.4, and Go 1.4 has some C code and rest Go 1.3 code, wouldn’t it all come down to the Go 1.2 compiler code which was purely C code (if i am not mistaken)? Then wouldn’t it be the underlying code we depend on to create assembly code and thereby binary?

If implemented correctly, a compiler written in C and a compiler in Go can emit the same code for the same input. Even one in Rust, in Erlang or R could do that.

The implementation language for a compiler is irrelevant if you only compare the emitted code, you can implement them all in the way to emit the same.

Of , they might differ in their runtime to produce the result, the memory used while creating the result, etc.

Though duration of compilation or memory consumption of the compiler are often only considered secondary, its more important that the code emitted is “good”.

Having said that, many languages strive to beeing self hosted, it is kind of proof the language is ready for production use, also it enables every developer to help optimising and improving the compiler that knows the language.

From what i understand, the C code of Go compiler was translated to Go code (complying with previous Go version) & the output compared to certify that the compiler was as good as the previous C based Go. But isn’t that essentially compiling the Go-based compiler code using a C-based Go compiler to convert it to assembly code? And those base features/constructs of the Go lang will always use the same C based Go compiler to convert to assembly.

Unless Go-coded Go compiler actually has written some constructs/features that directly generates new assembly code, without having used C based assembly generation code. Is that so for the concurrency features of Go?

The compiler has nothing to do with gos concurrency features, those are a property of the go runtime.

All the compiler needs to know about concurrency, is into what VM instruction spawning go routines needs to be translated, as well as what kind of instructions needs to be emitted for sending and receiving.

@NobbZ I guess i need to understand the working of Go compiler and runtime better to understand how concurrency is handled by Go. Do you have any good references to documentation that explains it better?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.