7 ms·

> It’s not only working it’s as fast and sometimes faster than the C code The C version calls latLngToCell() and the Go version calls FromGeo(). What an amazi

> It’s not only working it’s as fast and sometimes faster than the C code The C version calls latLngToCell() and the Go version calls FromGeo(). What an amazing tool that can completely change function names when it converts from C to Go. > probably due to Go runtime scaling on multiple cores. I'm sure that's it... on a single-threaded microbenchmark not running the same code.

floor_ 4y ago
My bullshit detector is going off as well.
benhoyt 4y ago
I think your pushback is good - I didn't think the explanation about multiple cores made sense either. The Go runtime doesn't magically spread things across cores. However, I don't think your sarcasm helps the conversation.
- Thaxll 4y ago
  Hmm yes it does actually, when you run something in a goroutine ( go keyword ) that's what I would call "magic".
  - rowanG077 4y ago
    what? Magic would be if Go could run single threaded code in multiple threads automatically and efficiently. The Go keyword is just a thread start for a green thread. There is nothing magical about it.
    - Thaxll 4y ago
      The runtime multiplex goroutine on posix threads without user intervention. You don't have to deal with thread pool, blocking etc ...
      - rowanG077 4y ago
        I'm not sure what you mean. You don't have to deal with those in (all?) green thread implementation at all. That's not specific to Go.
mypalmike 4y ago
I will translate from sarcasm to productive comment: "The analysis appears to be flawed. The C code and Go code ultimately call different functions, making performance comparisons unreliable at best. Furthermore, the code is single-threaded and will not benefit from 'Go runtime scaling on multiple cores.'"
- tut-urut-utut 4y ago
  - belter 4y ago
    - kjeetgill 4y ago
      There are other choices besides cynicism and sarcasm vs being over-seriously stern. I wouldn't downvote on this basis, but earnest sincerity certainly makes for better conversations — imho.
    - Beltalowda 4y ago
      Sure, but there's a time and place for everything. I think this is the wrong place and time.
    - jonahx 4y ago
      > If we had more of it It's the default mode of twitter and other places where conversation is a wasteland. Sure, I'll take a cynical terrorist over a true-believer murdering people, but here we're debating conversation among non-terrorists with and without sarcasm.
      - belter 4y ago
        I appreciate your reply, but there are different tones to it. I see most technical cynicism as frustration and ambition for technical excellence. Most emotionally detached debate gives some undertones of something creepy, I can't really put my finger on. I would not waste sweat on a vim vs emacs war :-) but if you don't get your heart pounding on a Windows vs Linux vs Mac debate for example, there something unsettling about it also. :-) Quoting from the article below: "..So as cynicism about many – perhaps most – things rises, so too does our appreciation and affection for what is good and true. Cynicism leads to more tender feelings towards what is truly lovable..." "In praise of cynicism": https://www.theguardian.com/world/2013/jul/10/in-praise-of-cynicism#:~:text=So%20as%20cynicism%20about%20many,towards%20what%20is%20truly%20lovable https://www.theguardian.com/world/2013/jul/10/in-praise-of-c....
usgroup 4y ago
Personally I appreciate the sarcasm —- for me, it speaks to the very often shoddy analysis that ends up in common circulation.
masklinn 4y ago
To be even less charitable, TFAA changed the code from apparently establishing a TLS connection per coordinate (so 1 million connections) to establishing just one and sending a million requests over it. I’m not surprised this is a 90% perf gain. The issue is not initialising the libc.
- jmillikin 4y ago
  TLS in the article stands for "Thread-Local Storage". https://pkg.go.dev/modernc.org/libc#TLS https://pkg.go.dev/modernc.org/libc#TLS
  - deleted 4y ago
    [deleted]
idoubtit 4y ago
> What an amazing tool that can completely change function names when it converts from C to Go. How can one read the code of the benchmark, then switch into virulent sarcasm mode without trying to understand the code? And seeing "+1" comments without any effort to understand is also disheartening. The blog post had a link about the Go helper functions the author used. It lands on https://github.com/akhenakh/goh3/blob/main/h3.go https://github.com/akhenakh/goh3/blob/main/h3.go This shows that the `FromGeo()` function used by the Go benchmark is a helper that calls transpiled functions. The benchmark code itself was of course not transpiled, so the sarcasm was unneeded and wrong. If anyone wants to dig in deeper, the C function `latLngToCell()` calls 2 functions, see https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index.c#L773 https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index... The Go function `XgeoToH3()` allocates a TLS then calls the same functions, see https://github.com/akhenakh/goh3/blob/main/ch3/a_linux_amd64.go#L9393 https://github.com/akhenakh/goh3/blob/main/ch3/a_linux_amd64... The C and Go code may not be strictly identical, but they seem pretty close. Enough to suppose the blog post was sincere. I believe the right thing to do is to ask the author why they used a custom rewrite of `latLngToCell()` in Go instead of calling the transpiled function.
- whimsicalism 4y ago
  Describing the GP as "virulent" is a silly over exaggeration.
- bsdetector 4y ago
  > The Go function `XgeoToH3()` allocates a TLS then calls the same functions And when author 'batches' the thread local storage he changes the code from thread-safe (C version) to not thread safe. The transpiled code is littered with TLS alloc and free calls to emulate stack variables that must be matched in order and that use the heap for temporary storage rather than the stack, with different cache access patterns that can very much affect tiny benchmarks. Contrary to what the author supposed about the performance, the fast Go version can't even be run over multiple threads. This is analogous to converting locks to NOPs and improving performance on a single-threaded microbenchmark, but doing so isn't an appropriate comparison even though the code may look identical except for one or two lines.
cogman10 4y ago
Sarcasm aside, it is possible for Go to beat C in some scenarios. The secret is the garbage collector. In high memory allocation applications a GC can be more efficient than direct heap allocations. This is especially true if the C/C++ application is making heavy use of reference counting. A GC will ultimately have lower overhead than managing the reference counting. All that said, in pure CPU calc scenarios with low allocations, C will almost certainly beat the pants off of go. Go's compiler is... subpar. Yes, it compiles fast, but it does that by ditching optimizations (perhaps this changes with LLVMGo).
- krylon 4y ago
  Does escape analysis play into it? This could allow the Go compiler to reduce the number of heap allocations (which are not free in either language), which in turn also reduces the load on the GC.
  - cogman10 4y ago
    I'm not familiar with the state of go escape analysis. It would play into it, but then you'd also argue that you don't need it in C because you'd simply put that sort of thing on the stack rather than the heap. GC will win when heap allocations are frequent, short lived, and unavoidable.
- generichuman 4y ago
  > In high memory allocation applications a GC can be more efficient than direct heap allocations. Anybody who cares about allocation speed in C or C++ (or Rust or <insert low level language>) will use arena / bump / slab allocators. GC is more efficient when you're writing naive code and you don't get to write naive code if you care about speed / memory usage. I'm not saying it's not possible to reach or surpass C-like speeds with Go, but when comparing C to higher level languages with GC there should be an asterisk next to the statement you're making.
  - socialdemocrat 4y ago
    But this is hardly like comparing to Java as Go gives you a lot of flexibility in how you organize, allocate and use memory thanks to pointer support and composite value types. Making an Arena allocator is something you could do in Go as well. But it is hard to manage memory effectively everywhere in C without creating a lot of overhead for the programmer.
deleted 4y ago
[deleted]

floor_ 4y ago

My bullshit detector is going off as well.

benhoyt 4y ago

I think your pushback is good - I didn't think the explanation about multiple cores made sense either. The Go runtime doesn't magically spread things across cores. However, I don't think your sarcasm helps the conversation.

Thaxll 4y ago
Hmm yes it does actually, when you run something in a goroutine ( go keyword ) that's what I would call "magic".
- rowanG077 4y ago
  what? Magic would be if Go could run single threaded code in multiple threads automatically and efficiently. The Go keyword is just a thread start for a green thread. There is nothing magical about it.
  - Thaxll 4y ago
    The runtime multiplex goroutine on posix threads without user intervention. You don't have to deal with thread pool, blocking etc ...
    - rowanG077 4y ago
      I'm not sure what you mean. You don't have to deal with those in (all?) green thread implementation at all. That's not specific to Go.

mypalmike 4y ago

I will translate from sarcasm to productive comment: "The analysis appears to be flawed. The C code and Go code ultimately call different functions, making performance comparisons unreliable at best. Furthermore, the code is single-threaded and will not benefit from 'Go runtime scaling on multiple cores.'"

tut-urut-utut 4y ago
- belter 4y ago
  - kjeetgill 4y ago
    There are other choices besides cynicism and sarcasm vs being over-seriously stern. I wouldn't downvote on this basis, but earnest sincerity certainly makes for better conversations — imho.
  - Beltalowda 4y ago
    Sure, but there's a time and place for everything. I think this is the wrong place and time.
  - jonahx 4y ago
    > If we had more of it It's the default mode of twitter and other places where conversation is a wasteland. Sure, I'll take a cynical terrorist over a true-believer murdering people, but here we're debating conversation among non-terrorists with and without sarcasm.
    - belter 4y ago
      I appreciate your reply, but there are different tones to it. I see most technical cynicism as frustration and ambition for technical excellence. Most emotionally detached debate gives some undertones of something creepy, I can't really put my finger on. I would not waste sweat on a vim vs emacs war :-) but if you don't get your heart pounding on a Windows vs Linux vs Mac debate for example, there something unsettling about it also. :-) Quoting from the article below: "..So as cynicism about many – perhaps most – things rises, so too does our appreciation and affection for what is good and true. Cynicism leads to more tender feelings towards what is truly lovable..." "In praise of cynicism": https://www.theguardian.com/world/2013/jul/10/in-praise-of-cynicism#:~:text=So%20as%20cynicism%20about%20many,towards%20what%20is%20truly%20lovable https://www.theguardian.com/world/2013/jul/10/in-praise-of-c....

usgroup 4y ago

Personally I appreciate the sarcasm —- for me, it speaks to the very often shoddy analysis that ends up in common circulation.

masklinn 4y ago

To be even less charitable, TFAA changed the code from apparently establishing a TLS connection per coordinate (so 1 million connections) to establishing just one and sending a million requests over it. I’m not surprised this is a 90% perf gain. The issue is not initialising the libc.

jmillikin 4y ago
TLS in the article stands for "Thread-Local Storage". https://pkg.go.dev/modernc.org/libc#TLS https://pkg.go.dev/modernc.org/libc#TLS
- deleted 4y ago
  [deleted]

idoubtit 4y ago

> What an amazing tool that can completely change function names when it converts from C to Go. How can one read the code of the benchmark, then switch into virulent sarcasm mode without trying to understand the code? And seeing "+1" comments without any effort to understand is also disheartening. The blog post had a link about the Go helper functions the author used. It lands on https://github.com/akhenakh/goh3/blob/main/h3.go https://github.com/akhenakh/goh3/blob/main/h3.go This shows that the `FromGeo()` function used by the Go benchmark is a helper that calls transpiled functions. The benchmark code itself was of course not transpiled, so the sarcasm was unneeded and wrong. If anyone wants to dig in deeper, the C function `latLngToCell()` calls 2 functions, see https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index.c#L773 https://github.com/uber/h3/blob/master/src/h3lib/lib/h3Index... The Go function `XgeoToH3()` allocates a TLS then calls the same functions, see https://github.com/akhenakh/goh3/blob/main/ch3/a_linux_amd64.go#L9393 https://github.com/akhenakh/goh3/blob/main/ch3/a_linux_amd64... The C and Go code may not be strictly identical, but they seem pretty close. Enough to suppose the blog post was sincere. I believe the right thing to do is to ask the author why they used a custom rewrite of `latLngToCell()` in Go instead of calling the transpiled function.

whimsicalism 4y ago
Describing the GP as "virulent" is a silly over exaggeration.
bsdetector 4y ago
> The Go function `XgeoToH3()` allocates a TLS then calls the same functions And when author 'batches' the thread local storage he changes the code from thread-safe (C version) to not thread safe. The transpiled code is littered with TLS alloc and free calls to emulate stack variables that must be matched in order and that use the heap for temporary storage rather than the stack, with different cache access patterns that can very much affect tiny benchmarks. Contrary to what the author supposed about the performance, the fast Go version can't even be run over multiple threads. This is analogous to converting locks to NOPs and improving performance on a single-threaded microbenchmark, but doing so isn't an appropriate comparison even though the code may look identical except for one or two lines.

cogman10 4y ago

Sarcasm aside, it is possible for Go to beat C in some scenarios. The secret is the garbage collector. In high memory allocation applications a GC can be more efficient than direct heap allocations. This is especially true if the C/C++ application is making heavy use of reference counting. A GC will ultimately have lower overhead than managing the reference counting. All that said, in pure CPU calc scenarios with low allocations, C will almost certainly beat the pants off of go. Go's compiler is... subpar. Yes, it compiles fast, but it does that by ditching optimizations (perhaps this changes with LLVMGo).

krylon 4y ago
Does escape analysis play into it? This could allow the Go compiler to reduce the number of heap allocations (which are not free in either language), which in turn also reduces the load on the GC.
- cogman10 4y ago
  I'm not familiar with the state of go escape analysis. It would play into it, but then you'd also argue that you don't need it in C because you'd simply put that sort of thing on the stack rather than the heap. GC will win when heap allocations are frequent, short lived, and unavoidable.
generichuman 4y ago
> In high memory allocation applications a GC can be more efficient than direct heap allocations. Anybody who cares about allocation speed in C or C++ (or Rust or <insert low level language>) will use arena / bump / slab allocators. GC is more efficient when you're writing naive code and you don't get to write naive code if you care about speed / memory usage. I'm not saying it's not possible to reach or surpass C-like speeds with Go, but when comparing C to higher level languages with GC there should be an asterisk next to the statement you're making.
- socialdemocrat 4y ago
  But this is hardly like comparing to Java as Go gives you a lot of flexibility in how you organize, allocate and use memory thanks to pointer support and composite value types. Making an Arena allocator is something you could do in Go as well. But it is hard to manage memory effectively everywhere in C without creating a lot of overhead for the programmer.

deleted 4y ago

[deleted]