12 ms·
It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still
by bradfitz 9y ago
It increasingly does.
But it's been a process.
Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax.
Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like.
Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 (https://golang.org/doc/go1.7#compiler https://golang.org/doc/go1.7#compiler).
Go 1.8 included it for all architectures and added more SSA goodness.
Go 1.9 adds yet more, but some things are still not pushed down into SSA as well as they could be. (e.g. https://github.com/golang/go/issues/5147#issuecomment-247685599 https://github.com/golang/go/issues/5147#issuecomment-247685...)
Nowadays we can add optimizations much more easily, including writing matching rules like in https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/gen/generic.rules https://github.com/golang/go/blob/master/src/cmd/compile/int...
Meanwhile the whole toolchain keeps getting cleaned up and more hackable.
In Go 1.9, the compiler is now parallelized, which would've been impossible earlier. (https://tip.golang.org/doc/go1.9#parallel-compile https://tip.golang.org/doc/go1.9#parallel-compile)
So, it keeps improving. Just remember the Hello World compiler we started with.
Also amusing in retrospect is that when Go first came out, despite having a very basic compiler at the time, people coming from scripting languages thought we were so fast.
- pcwalton 9y agoJust for what it's worth, the way I'd fix that problem in the compiler would be to implement dead store elimination via global value numbering. With trivial alias analysis, the compiler would be able to detect that the result of the "duffzero" instruction (which I assume is a memset) is always killed by the "duffcopy" instructions and would eliminate it. See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...
- heythere124 9y agoNot my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads? var x Int // Pass x to a thread by reference x = 0 time.Sleep(1000) x = 1
- Filligree 9y agoThe answer to that one would be to embed thread-safety in the type system, aka. Rust. For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).
- heythere124 9y agoYour "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system. In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.
- Filligree 9y agoThe constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.
- heythere124 9y agoNot sure those optimisations are worth much. And it's only safety by forcing lowest common denominator code and making you justify everything to a dumb compiler. Rust serves a niche, but it is a tight niche IMO.
- pcwalton 9y agoAliasing info is hugely important in optimization. In fact, it's needed to solve this very bug. Aliasing info is, fundamentally, what allows Rust to have memory safety without GC.
- the8472 9y agoHow can you be sure that the other threads ever see it in time? they might be suspended for a whole second because a HDD needs to spin up or something like that. So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.
- dom0 9y agoWhy does Go not use LLVM? Are there technical reasons to reinvent the wheel, or is it just because LLVM is Apple's pet?
- pkroll 9y agoFirst part of the "Implementation" section: they thought it was too large and slow for their compiler speed goals. https://golang.org/doc/faq#Implementation https://golang.org/doc/faq#Implementation
- oelmekki 9y agoI hope this won't come out harsher than I intend to, but I'm so tired to hear this expression "not reinventing the wheel" to justify using third party code. This is not what it means. Note that there is not a single wheel that was built once in prehistory and now every human gets it lent when they need it. People build wheels everyday to fit their needs, reusing the concept of wheel, that is, knowing that a circular object allows for smooth movements with less friction. The analogy in software development means that you've better know of designs that help you solve your problem, not that you should blindly use code built by someone else to bypass the whole problem solving. This is basically trying to use a bicycle wheel for everything. This may work well on an other bicycle, not on a car.
- bradfitz 9y agoSee this answer from Russ Cox: https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
- dom0 9y agoThank you for an insightful answer.