Does that mean cgo is away too ?
Go in Go
81–90 of 156 posts
Re: Go in Go
#82I am most excited for the new SSA backend in go. I have been following commits to it here: https://github.com/golang/go/tree/dev.ssa No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.
I was exited by this:
> Generate machine descriptions from PDFs (or maybe XML).
> Will have a purely machine-generated instruction definition:
> "Read in PDF, write out an assembler configuration".
> Already deployed for the disassemblers.
(my emphasis)
That coupled with a whole tool chain in a friendly language like go, makes be exited for how this might be used by other language designers. While "compile to go" might not be as attractive as "compile to c" -- it's not half-bad. More importantly it kind of smells like part of this tool chain should make it quite easy to generate machine code quite easily.
Nothing against llvm, rpython/pypy, graal etc - but the more the merrier!
Re: Go in Go
#83Earlier quoted context omitted.
If I'm not mistaken, these graphs refer to the speed of the code generated with the compiler, not of the compiler itself.
This slide mentions that initial go-version dropped down to 1/10th of the C in performance: http://talks.golang.org/2015/gogo.slide#15 While the next mentions that the got it back up -- but not by how much. It wasn't exactly crystal clear from the docs/website, but apparently[1] "master" is go1.5 -- so with go1.4 on windows, one can: # from a git bash, already have go1.4 installed git clone https://github.com/golang/…
(I'd be more confident in this test if someone could point me at a past commit where go1.5 works, builds with go1.4 and itself, but is (much 10x) slower...).
Re: Go in Go
#84Unless I missed it, it is surprising the lack of benchmarks or mentioning how compile speed compares with the previous iteration. I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.
Does the speed it takes to compile the compiler really matter? Edit: Of course, faster speeds would be interesting to hear about, so great question.
[deleted]
Re: Go in Go
#85Unless I missed it, it is surprising the lack of benchmarks or mentioning how compile speed compares with the previous iteration. I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.
Does the speed it takes to compile the compiler really matter? Edit: Of course, faster speeds would be interesting to hear about, so great question.
[deleted]
Re: Go in Go
#86Live stream recording here: https://youtu.be/Fx304EfqtMo?t=2468
Re: Go in Go
#87Is there anyway to navigate that presentation using only the mouse? If not, why not?
Re: Go in Go
#88Is there anyway to navigate that presentation using only the mouse? If not, why not?
From the instructions on the page:
> Use the left and right arrow keys _or click the left and right edges of the page_ to navigate between slides.
Re: Go in Go
#89Live stream recording here: https://youtu.be/Fx304EfqtMo?t=2468
Not anymore :)
Re: Go in Go
#90Can some one answer this question. It says that Go1.4 will be needed to compile Go1.5. Does this mean that Go1.4 will always be needed, even for Go1.6 and beyond? So are they essentially locking things to the Go1.4 "C" code, then updating on top of that?
Yes. It means that anytime you want to add a new supported architecture, you'll need to bootstrap through Go 1.4. Otherwise, I'm guessing that for Go 1.6, they'll rely on you having a binary distribution of 1.5 (probably from your distribution, or their website), etc.
>It means that anytime you want to add a new supported architecture, you'll need to bootstrap through Go 1.4.
That's not true at all, (1) you write the backend for the target machine, (2) you recompile the compiler with the new backend included on a supported host, (3) then use the new compiler to compile itself for the target using the new backend, (4) you now have a compiler that runs on the target.
Same process is used to port C compilers (or any self-hosting compiler, really).