4 ms·

>Programmers who desire tight control over performance [...] will obviously hate Go. Curious, why do you say that? Go tries very hard to prevent abstracted, hi

by adtac 7y ago

>Programmers who desire tight control over performance [...] will obviously hate Go. Curious, why do you say that? Go tries very hard to prevent abstracted, hidden costs like (con|de)structors, so performance is quite obvious. Could you explain a bit more? I understand the memory management part.

apta 7y ago
The golang gc is not tunable, at least compared to the JVM GC for example. It is tuned for latency, not throughput. So, if you're writing high-throughput code, you can't really do much. You can try to write code that reduces allocations, but so can you in Java or C# (even moreso after Java gets value types). Not to mention that the golang gc cannot handle GBs (let alone TBs of heap space) the way the JVM routinely does. The golang runtime cannot devirtualize interface implementations the way the JVM does[1] or .NET does. I'm sure there are more examples to think of. [1] https://youtu.be/lunJmMBkqLo?t=1072 https://youtu.be/lunJmMBkqLo?t=1072
- Thaxll 7y ago
  Go GC can easily handle GBs of heap, especially if you're careful with pointers.
  - apta 7y ago
    I benchmarked etcd with 10G-50GB heap space and it didn't do a good job at all, lots of CPU time spent in GC.
    - todd8 7y ago
      The performance of the etcd system is complex[1], there’s raft consensus, replication, security, snapshots, networking, and basically a lot going on. Perhaps, your benchmarks really do reflect problems that go has with gc, but perhaps some other part amonst the numerous moving parts are causing the poor benchmark results. I’m not sure that we can conclude from your results that go has gc problems when the heap is large. [1] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md https://github.com/etcd-io/etcd/blob/master/Documentation/op...
      - apta 7y ago
        From what I recall, having a large-ish number of watchers resulted in memory usage to go up significantly. The gc started thrashing as CPU usage went up. Put performance dropped with gc cycles.

by adtac 7y ago

apta 7y ago

The golang gc is not tunable, at least compared to the JVM GC for example. It is tuned for latency, not throughput. So, if you're writing high-throughput code, you can't really do much. You can try to write code that reduces allocations, but so can you in Java or C# (even moreso after Java gets value types). Not to mention that the golang gc cannot handle GBs (let alone TBs of heap space) the way the JVM routinely does. The golang runtime cannot devirtualize interface implementations the way the JVM does[1] or .NET does. I'm sure there are more examples to think of. [1] https://youtu.be/lunJmMBkqLo?t=1072 https://youtu.be/lunJmMBkqLo?t=1072

Thaxll 7y ago
Go GC can easily handle GBs of heap, especially if you're careful with pointers.
- apta 7y ago
  I benchmarked etcd with 10G-50GB heap space and it didn't do a good job at all, lots of CPU time spent in GC.
  - todd8 7y ago
    The performance of the etcd system is complex[1], there’s raft consensus, replication, security, snapshots, networking, and basically a lot going on. Perhaps, your benchmarks really do reflect problems that go has with gc, but perhaps some other part amonst the numerous moving parts are causing the poor benchmark results. I’m not sure that we can conclude from your results that go has gc problems when the heap is large. [1] https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md https://github.com/etcd-io/etcd/blob/master/Documentation/op...
    - apta 7y ago
      From what I recall, having a large-ish number of watchers resulted in memory usage to go up significantly. The gc started thrashing as CPU usage went up. Put performance dropped with gc cycles.