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

Go 1.5 Beta

golang.org

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Go 1.5 Beta

#71

Post by 0xdeadbeefbabe »

fgaaldal wrote: post #70
enneff wrote: post #67

Earlier quoted context omitted.

The new GC reduces pauses to the single-digit milliseconds. Rendering every ~15ms seems reasonable under those constraints. Plus I don't think a game engine will typically put a lot of pressure on the garbage collector. I don't think the new GC precludes Go from being suitable for writing games. On the contrary, I think it is now more suitable, and look forward to using Go for writing games myself.

It is funny that just after I wrote this, I spotted another article on the frontpage: https://sourcegraph.com/blog/live/gophercon2015/123574706480 So I admire their goal to reduce latency (it's probably a latency-throuhput tradeoff) and I always get told that real-time (which in my opinion requires low-latency) is possible in GC-languages, I just do not know how to do that reliable. But I hope I am wrong and it is po…

ISTR that producing a clean sign wave on a scope requires a real-time operating system, and it was one of the first tests for seeing if your real time linux patches worked.

Re: Go 1.5 Beta

#72

Post by tyho »

bradfitz wrote: post #65
bsdetector wrote: post #31

Earlier quoted context omitted.

Compilation speed was just a gimmick anyway; the compiler is fast because it doesn't do many expensive optimizations. It was like bragging that using "-O0" makes a compiler so fast. There are languages that require a lot of work just to compile at all, like C++, but for most languages slow compilation is more a measure of how advanced the compiler is. And it's not just the compiler, the linker didn't even know if a p…

Others already pointed out that paragraph 1 isn't really correct. I need to point out that your second point about the linker is totally false. The linker knows and does drop unreferenced code. The import strictness is a language requirement and comes from experience with large codebases at Google and elsewhere. Use goimports in your editor's save hook and don't think about it.

It probably takes more effort to write a whiny blog post about the imports behaviour than hooking goimports on save.

Re: Go 1.5 Beta

#73

Post by pcwalton »

tyho wrote: post #51
codemac wrote: post #48

Earlier quoted context omitted.

You're more than welcome to write C in the fashion that the go compiler enforces, and get much faster builds. Their compiler is young and immature relative to things like GCC and stating that it may be missing expensive optimization features is not "plain wrong".

That suggestion is not really practical as you need to make the same requirement from all your third party libraries. While gcc will spend more time optimizing than go, the main reason for the speed difference at the moment IS unnecessary work done by the preprocessor because of the primitive importing.

No, it's not, unless you count time spent compiling inlined functions and templates as "preprocessing time" (which it isn't—it's compilation time). Time the difference between clang++ on -O0 versus -O3 if you don't believe me.

Re: Go 1.5 Beta

#74

Post by kodablah »

dvirsky wrote: post #69
kodablah wrote: post #35

Earlier quoted context omitted.

According to the release notes [1], "For the amd64 architecture only, the compiler has a new option, -dynlink, that assists dynamic linking by supporting references to Go symbols defined in external shared libraries."...so I assume if you want all of your Go signatures visible in your shared Go libraries, you can do it on x64. I have not tested this myself. 1 - https://tip.golang.org/doc/go1.5#compiler

the question though is how do you go about actually loading it? can it be done without patching the runtime, or without running some C based "bridge" that loads the shared object file? I'm talking about a plugin architecture, say, where I want to load an implementor of an interface from a .so file, etc.

Based on a cursory overview of the design document, this appears to be done by not putting all of the Go signatures in the library (e.g. ELF headers somewhere) but instead based on a hash. From the design document [1]: "The shared library should include a hash of the export data for each package that it contains. It should also include a hash of the export data for each shared library that it imports. These hashes can be used to determine when packages must be recompiled. These hashes should be accessible to any build tool, not just the go tool." To me this is basically saying that so long as the hashes of the .so file match your binary, your dynamic load should be able to trust the uses of the same interface known at compile time.

I have not yet seen the "plugin" package in https://tip.golang.org/pkg/ as promised under the heading of "A new package" in the design doc.

1 - https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...

Re: Go 1.5 Beta

#75

Post by sdevlin »

> Also in the crypto/cipher package, there is now support for nonce lengths other than 96 bytes in AES's Galois/Counter mode (GCM), which some protocols require.

This should be "96 bits".

Re: Go 1.5 Beta

#76

Post by ianchildress »

spenczar5 wrote: post #17
ianchildress wrote: post #5

These are pretty big to me: The garbage collector is now concurrent and provides dramatically lower pause times by running, when possible, in parallel with other goroutines. By default, Go programs run with GOMAXPROCS set to the number of cores available; in prior releases it defaulted to 1. But how important is this? It doesn't seem like it affects the average user: The compiler and runtime are now written entirely…

Rewriting the compiler in Go was a precondition for improving garbage collection, according to Rob Pike. The old C codebase was complex and finicky, and, to an increasing extent, contributors to the Go language often know Go better than C. So, that more complex garbage collector is a product of that less-sexy rewrite.

Great explanation, that explains a lot!

Re: Go 1.5 Beta

#77

Post by 4ad »

binarycrusader wrote: post #44

Of particular note, Solaris support in Go 1.5 is greatly improved thanks to the work of Aram Hăvărneanu; Oracle sponsored most of that work. Notably, cgo is now supported on Solaris as of Go 1.5 beta. The same should hold true of various OpenSolaris-based distributions such as Illumos, et al.

You welcome. Mdb, DTrace, and SPARC64 support coming soon too...

Re: Go 1.5 Beta

#78

Post by dvirsky »

kodablah wrote: post #74
dvirsky wrote: post #69

Earlier quoted context omitted.

the question though is how do you go about actually loading it? can it be done without patching the runtime, or without running some C based "bridge" that loads the shared object file? I'm talking about a plugin architecture, say, where I want to load an implementor of an interface from a .so file, etc.

Based on a cursory overview of the design document, this appears to be done by not putting all of the Go signatures in the library (e.g. ELF headers somewhere) but instead based on a hash. From the design document [1]: "The shared library should include a hash of the export data for each package that it contains. It should also include a hash of the export data for each shared library that it imports. These hashes ca…

But I'm wondering - will this mysterious "plugin" package require changes in Go's core runtime, or can I implement whatever functionality it will expose right now. It looks to me like it can't be done without some C bridge/glue while not changing Go itself.

Re: Go 1.5 Beta

#79

Post by dvirsky »

kodablah wrote: post #74
dvirsky wrote: post #69

Earlier quoted context omitted.

the question though is how do you go about actually loading it? can it be done without patching the runtime, or without running some C based "bridge" that loads the shared object file? I'm talking about a plugin architecture, say, where I want to load an implementor of an interface from a .so file, etc.

Based on a cursory overview of the design document, this appears to be done by not putting all of the Go signatures in the library (e.g. ELF headers somewhere) but instead based on a hash. From the design document [1]: "The shared library should include a hash of the export data for each package that it contains. It should also include a hash of the export data for each shared library that it imports. These hashes ca…

maybe it can be done with some unsafe magic parsing ELF files or something?

Re: Go 1.5 Beta

#80

Post by JulianMorrison »

melle wrote: post #18
vruiz wrote: post #3

changelog: https://tip.golang.org/doc/go1.5 It seems to me like they've included Google's trace viewer[0] into the go tool, nice. [0] https://github.com/google/trace-viewer

From the changelog: > Builds in Go 1.5 will be slower by a factor of about two. The automatic translation of the compiler and linker from C to Go resulted in unidiomatic Go code that performs poorly compared to well-written Go. Analysis tools and refactoring helped to improve the code, but much remains to be done. Further profiling and optimization will continue in Go 1.6 and future releases. This seems quite a drast…

They are porting to self-hosted in Go only. And they are willing to trade off compilation speed, temporarily, for getting there at all. Machine translated code will be full of low hanging fruit to get the old speed back.
Post reply on HN