4 ms·

I think once the garbage collector improves with the 1.5 release, it will be a serious competitor.

by rjammala 12y ago

deleted 12y ago
[deleted]
- rjammala 12y ago
  True. Agree about the size. There is work in progress that will allow a Go executable to be used with shared libraries.
voidlogic 12y ago
Most Go apps can get better than advanced Java GC level allocation-memory performance simply by applying "sync.Pool" (http://golang.org/pkg/sync/#Pool http://golang.org/pkg/sync/#Pool) on applicable pain points. Its also worth mentioning using a custom allocator + mmap is possible in Go if you really needed it. Go is also better than Java about using stack allocation for objects.
- batbomb 12y ago
  I'd like to see some research to backup your first claim if you can point me to some.
  - voidlogic 12y ago
    You want evidence that a object pool with thread-local caching is faster than a garbage collector? Barring major implementation mistakes this should be self-evident, but you could easily write some benchmarks to verify. Its worth noting that if the Java GC was good enough people would not bother to write object pools in Java- but they do. And Go has a very advanced GC/mutliprocessor aware object pool implementation built in its stdlib. In an typical object pool only allocation up to the peak concurrent demand for the given object type will ever be allocated and the kicker is that allocation will only happen once. Adding thread-local caching means that that will scale well on multiprocessor systems. TL;DR: A system that does not generate garbage is going to be faster than a system that does. My argument is that effective use of a good object pool implementation in Go is faster than even a more advanced garbage collector would be.
danieldk 12y ago
Another weak point of Go for high-performance computing (besides the garbage collector, which is indeed making huge strides), is the compiler. Modern C++ compilers do auto-vectorization, offer OpenMP, etc. Of course, you can work around this by writing your numerical code in C or C++, let your C/C++ compiler do the work and bind from cgo. Another shortcoming of Go is that it cannot be used for building non-Go libraries. First of all because the defacto compiler cannot create shared libraries, secondly, because having a garbage collector gives ownership difficulties once you start binding against another language with a garbage collector. I will not repeat the usual generics stuff, except that lots of optimizations in C++ code rely on generics (e.g. algorithm selection based on the data type or data type properties). (No, I am not starting Go bashing season ;), I like Go a lot and it can be used to replace C++ in many projects. Just stating the weak points when coming from C++.)

I think once the garbage collector improves with the 1.5 release, it will be a serious competitor.

deleted 12y ago

[deleted]

rjammala 12y ago
True. Agree about the size. There is work in progress that will allow a Go executable to be used with shared libraries.

voidlogic 12y ago

Most Go apps can get better than advanced Java GC level allocation-memory performance simply by applying "sync.Pool" (http://golang.org/pkg/sync/#Pool http://golang.org/pkg/sync/#Pool) on applicable pain points. Its also worth mentioning using a custom allocator + mmap is possible in Go if you really needed it. Go is also better than Java about using stack allocation for objects.

batbomb 12y ago
I'd like to see some research to backup your first claim if you can point me to some.
- voidlogic 12y ago
  You want evidence that a object pool with thread-local caching is faster than a garbage collector? Barring major implementation mistakes this should be self-evident, but you could easily write some benchmarks to verify. Its worth noting that if the Java GC was good enough people would not bother to write object pools in Java- but they do. And Go has a very advanced GC/mutliprocessor aware object pool implementation built in its stdlib. In an typical object pool only allocation up to the peak concurrent demand for the given object type will ever be allocated and the kicker is that allocation will only happen once. Adding thread-local caching means that that will scale well on multiprocessor systems. TL;DR: A system that does not generate garbage is going to be faster than a system that does. My argument is that effective use of a good object pool implementation in Go is faster than even a more advanced garbage collector would be.

danieldk 12y ago

Another weak point of Go for high-performance computing (besides the garbage collector, which is indeed making huge strides), is the compiler. Modern C++ compilers do auto-vectorization, offer OpenMP, etc. Of course, you can work around this by writing your numerical code in C or C++, let your C/C++ compiler do the work and bind from cgo. Another shortcoming of Go is that it cannot be used for building non-Go libraries. First of all because the defacto compiler cannot create shared libraries, secondly, because having a garbage collector gives ownership difficulties once you start binding against another language with a garbage collector. I will not repeat the usual generics stuff, except that lots of optimizations in C++ code rely on generics (e.g. algorithm selection based on the data type or data type properties). (No, I am not starting Go bashing season ;), I like Go a lot and it can be used to replace C++ in many projects. Just stating the weak points when coming from C++.)