5 ms·

> it's performance is closer to Java Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.de

> it's performance is closer to Java Go vs Java https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Go vs C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > pushing outdated concepts like null and raw pointers on to the programmer I mean this is just a fact. Are you disputing nil and *? > it has a runtime with a stop the world GC https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote "On the Y axis we have GC latency in milliseconds. On the X axis we have time. Each of the points is a stop the world pause time during that GC. " > with no guarantees about object placement on the stack or heap From the F.A.Q. " How do I know whether a variable is allocated on the heap or the stack? From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language." > but every other claim you made above is empirically incorrect. Seems you're empirically incorrect.

weberc2 8y ago
The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders. > Do you dispute nil and * I dispute that Go’s pointer is a “raw pointer” in any meaningful sense of the word. In C++, raw pointers may be uninitialized, they may be cast from any int, they don’t imply any automatic cleanup of the pointee, and they are subject to pointer arithmetic—none of this is possible with Go pointers except via the “unsafe” package. So basically none of the criticism of raw pointers applies to Go pointers. > Go has a stop the world GC You are correct here, Go has a stw GC. It’s probably not suitable for RTOS, but its pauses are on the order of microseconds, so most of the conventional GC criticism doesn’t apply. > Stack vs heap The language doesn’t have semantics for stack vs heap allocation, but that doesn’t mean it’s hard to control where things are allocated. In particular, the compiler can spit out where its allocating and you can adjust accordingly. It’s far easier to do this in the hot path than to have to specify where every piece of memory is allocated across your program. > seems like you’re empirically incorrect Quite the opposite, actually. There’s nothing wrong with not knowing or being mistaken, but there’s no need for overt snarkiness.
- igouy 8y ago
  > The benchmarks game is just that: a game. The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money. It's what you make of it. https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#name-game https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Go programs are prohibited from doing certain optimizations that are permissible for C++ programs Which programs? Which "certain optimizations"?
  - weberc2 8y ago
    That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.
    - igouy 8y ago
      > That benchmarks game quote supports my point… As-long-as your point was not intended to be dismissive in any way. > prohibited optimizations Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do. Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.
      - weberc2 8y ago
        It is dismissive of the idea that the game can tell you meaningful things about a programming language’s average or percentile performance or even its peak performance. > Go programs are not prohibited... Right, and this is why the Go benchmarks for allocations aren’t very meaningful. Using arenas (or other kinds of preallocation) is a common optimization in Go even if Go doesn’t have a library for it. I’m sure you’re well aware of all of this since you evidently contributed to these benchmarks, but for other readers, here’s a good thread about why these benchmarks aren’t meaningful.
igouy 8y ago
> … it's performance is closer to Java … You seem to be quoting yourself out-of-context ;-) In full, you wrote — "… but it's performance is closer to Java, which is a few orders of magnitude slower than C++" — and that is not shown by those measurements.

weberc2 8y ago

The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders. > Do you dispute nil and * I dispute that Go’s pointer is a “raw pointer” in any meaningful sense of the word. In C++, raw pointers may be uninitialized, they may be cast from any int, they don’t imply any automatic cleanup of the pointee, and they are subject to pointer arithmetic—none of this is possible with Go pointers except via the “unsafe” package. So basically none of the criticism of raw pointers applies to Go pointers. > Go has a stop the world GC You are correct here, Go has a stw GC. It’s probably not suitable for RTOS, but its pauses are on the order of microseconds, so most of the conventional GC criticism doesn’t apply. > Stack vs heap The language doesn’t have semantics for stack vs heap allocation, but that doesn’t mean it’s hard to control where things are allocated. In particular, the compiler can spit out where its allocating and you can adjust accordingly. It’s far easier to do this in the hot path than to have to specify where every piece of memory is allocated across your program. > seems like you’re empirically incorrect Quite the opposite, actually. There’s nothing wrong with not knowing or being mistaken, but there’s no need for overt snarkiness.

igouy 8y ago
> The benchmarks game is just that: a game. The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money. It's what you make of it. https://benchmarksgame-team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-stuff.html#name-game https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Go programs are prohibited from doing certain optimizations that are permissible for C++ programs Which programs? Which "certain optimizations"?
- weberc2 8y ago
  That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.
  - igouy 8y ago
    > That benchmarks game quote supports my point… As-long-as your point was not intended to be dismissive in any way. > prohibited optimizations Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do. Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.
    - weberc2 8y ago
      It is dismissive of the idea that the game can tell you meaningful things about a programming language’s average or percentile performance or even its peak performance. > Go programs are not prohibited... Right, and this is why the Go benchmarks for allocations aren’t very meaningful. Using arenas (or other kinds of preallocation) is a common optimization in Go even if Go doesn’t have a library for it. I’m sure you’re well aware of all of this since you evidently contributed to these benchmarks, but for other readers, here’s a good thread about why these benchmarks aren’t meaningful.

igouy 8y ago

> … it's performance is closer to Java … You seem to be quoting yourself out-of-context ;-) In full, you wrote — "… but it's performance is closer to Java, which is a few orders of magnitude slower than C++" — and that is not shown by those measurements.