61–70 of 82 posts
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.
is this worth learning
Earlier quoted context omitted.
I'd be really surprised if that results in programs in parallel mode becoming slower than sequential I'm going to guess that you haven't played too much with executing things in parallel? In Clojure groups, people have heard beginners express surprise about parallel mode programs running slower so often, it's somewhat shaped the reaction to such questions. few people use concurrent read-write data structures anyway (…
I think you're overstating how much false sharing in particular causes parallel slowdowns. In the case of Clojure, for example, it's probably just straightforward synchronization overhead (cost of atomic ops), just as it is in Go. False sharing is a very specific type of synchronization problem whereby data tightly packed in memory gets shared between multiple processors because the cache line size is larger than des…
> The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. Well we can toss out Go as a suitable language for real-time applications such as video games and audio processing.
Earlier quoted context omitted.
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…
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…
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.
is this worth learning
> The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. Well we can toss out Go as a suitable language for real-time applications such as video games and audio processing.
Why the down-votes, I think this is a valid point. In case of real-time, e.g. video games, you want to render every ~15ms and doing that with a GC is really NOT trivial. I do not say, GC-languages perform bad, they actually are great for throughput, but doing low-latency stuff is still hard.
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.
Earlier quoted context omitted.
Is it possible to dynamically load libraries that have been compiled with -buildmode=shared in runtime from within a running Go program? The design doc talked about it IIRC.
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
Earlier quoted context omitted.
Why the down-votes, I think this is a valid point. In case of real-time, e.g. video games, you want to render every ~15ms and doing that with a GC is really NOT trivial. I do not say, GC-languages perform bad, they actually are great for throughput, but doing low-latency stuff is still hard.
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.
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 possible to go real-time with a GC as it is often a prerequisite for high-level language features.