Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go in Go

talks.golang.org

Post reply on HN
Print view View original

71–80 of 156 posts

Re: Go in Go

#71

Post by Kurtz79 »

shurcooL wrote: post #70
Kurtz79 wrote: post #68

Unless 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.

There were a few slides with numbers and detailed performance graphs in Andrew's preceding talk. See http://talks.golang.org/2015/state-of-go-may.slide#10 and nearby slides.

If I'm not mistaken, these graphs refer to the speed of the code generated with the compiler, not of the compiler itself.

Re: Go in Go

#72

Post by shocks »

FlailFast wrote: post #26
comboy wrote: post #6

Oh, I was hoping for some go (aka baduk or weiqi) playing program written in go. These are a bit tricky to google ;)

Finally, my moment! I submit my own library, which is really meant for two players and scoring...and like much of what I do, was purely pun-driven. Maybe one day I'll add AI: https://github.com/acityinohio/baduk

Cool! Thanks for sharing.

Re: Go in Go

#73

Post by bojo »

Kurtz79 wrote: post #68

Unless 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.

Re: Go in Go

#74

Post by jballanc »

Aissen wrote: post #69
ClassicFarris wrote: post #19

Can 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.

I think it would be much more likely that new architectures would be added as cross-compilation targets than to work back through a v1.4 bootstrap.

Re: Go in Go

#75

Post by jballanc »

fizixer wrote: post #47

Fun fact: what's common between Rob Pike, Bjarne Stroustrup, Larry Wall, Guido van Rossum, and so many other language inventors? They're all C programmers!

Well, C is essentially "portable assembly", so it's to be expected...

Re: Go in Go

#76

Post by shultays »

segmondy wrote: post #58
smaili wrote: post #23

Just out of curiosity, is this the first time a language is written using itself?

It's a sign of maturity to show that a language can bootstrap itself, prolog has been written in prolog, erlang was written with prolog first, then later rewritten in erlang, as other's have pointed out, it's pretty common for C/C++, Lisp, Assembly. This of course applies more to compiled languages.

Hell, brainfuck can interprete itself

Re: Go in Go

#78

Post by billpg »

I've created my own programming language and they always tell me that the best languages are always self-hosted, so I wrote the compiler in my new language too.

I'm having trouble running the compiler.

     bpgcomp bpgcomp.bpg -o bpgcomp
But I keep getting a "bpgcomp not found" error.

Re: Go in Go

#79

Post by e12e »

Kurtz79 wrote: post #71
shurcooL wrote: post #70

Earlier quoted context omitted.

There were a few slides with numbers and detailed performance graphs in Andrew's preceding talk. See http://talks.golang.org/2015/state-of-go-may.slide#10 and nearby slides.

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/go.git go.git
    cd go.git/src
    git checkout master
    export GOROOT_BOOTSTRAP=$GOROOT
    time cmd "/c all.bat"

    real    0m29.078s
    user    0m0.015s
    sys     0m0.030s

    # with our fresh go1.5 (see more below):
   
    real    0m33.034s
    user    0m0.000s
    sys     0m0.000s
So, apparently doing the same job (compiling go1.5 "master") with go1.5 and go1.5 -- there's a small hit (I ran a couple of runs with each, the numbers are consistent to ~1sec, so call it 29 for 1.4 and 33 for 1.5).

Note that if you want to do this, in particular the second part, it gets a bit hairy, as "go.exe" needs to be in your path, and you need to change your gopath (easy).

On my system, I had everything in $HOME/opt (%HOME%\opt), so all i did was move opt\go to opt\go1.4, and copy go.git to \opt\go. One can confirm the right version is being run with 'go version' (and 'cmd "/c go version"' from bash).

[1] After a few useless hits, I found: https://godoc.org/golang.org/x/mobile/cmd/gomobile -- which mentions what's needed to actually test go 1.5. If they want testers, they should probably add something under "install from source" on golang.org about "And if you want to live on the edge, or say, test go in go, use "master")

Re: Go in Go

#80

Post by Dewie3 »

Kurtz79 wrote: post #71
shurcooL wrote: post #70

Earlier quoted context omitted.

There were a few slides with numbers and detailed performance graphs in Andrew's preceding talk. See http://talks.golang.org/2015/state-of-go-may.slide#10 and nearby slides.

If I'm not mistaken, these graphs refer to the speed of the code generated with the compiler, not of the compiler itself.

Distinctions like that makes googling for speed of the compiler itself annoying.. :-)
Post reply on HN