3 ms·

> (and an order of magnitude faster) alternative to Python Python is increasingly an easy to use wrapper over low-level C/C++ code. So in many use cases it is

> (and an order of magnitude faster) alternative to Python Python is increasingly an easy to use wrapper over low-level C/C++ code. So in many use cases it is faster than Go.

justinclift 3y ago
Than pure Go code, sure. But not really faster than Go code that's a wrapper over the same low-level C/C++ code.
- Merovius 3y ago
  That depends. C function call overhead for Go is quite large (it needs to allocate a larger stack, put it on its own thread and prevent pre-emption) and possibly larger than for CPython, which relies on calling into C for pretty much everything it does, so obviously has that path well-optimized. So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go.
  - gwd 3y ago
    > So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go. I don't have experience with Python, but I can definitely say switching between Go and C is super slow. I'm using a golang package which is a wrapper around SQLite: at some point I had a custom function written as a call-back to a Go function; profiling showed that a huge amount of time was spent in the transition code marshalling stuff back and forth between Go and C. I ended up writing the function in C so that the C sqlite3 library could call it directly, and it sped up my benchmarks significantly, maybe 5x. Even though sqlite3 is local, I still end up trying to minimize requests and data shipped out of the database, because transferring data in and out is so expensive. (And if you're curious, yes I have considered trying to use one of the "pure go" sqlite3 packages; in large part it's a question of trust: the core sqlite3 library is tested fantastically well; do I trust the reimplementations enough not to lose my data? The performance would have to be pretty compelling to make it worth the risk.) I think in general discouraging CGo makes sense, as in the vast majority of cases a re-implementation is better in the long run; so de-prioritizing CGo performance also makes sense. But there are exceptions, particularly for libraries where you want functionality to be identical, like sqlite3 or Qt, and there the CGo performance is a distinct downside.
- iainmerrick 3y ago
  Do you have an example of that? What I’ve heard over and over in comments here is that a) C interop in Go is slow, and b) Go devs discourage using it. (Java is a similar story in my experience.) In Python, (b) at least is definitely not true.
  - deleted 3y ago
    [deleted]

> (and an order of magnitude faster) alternative to Python Python is increasingly an easy to use wrapper over low-level C/C++ code. So in many use cases it is faster than Go.

justinclift 3y ago

Than pure Go code, sure. But not really faster than Go code that's a wrapper over the same low-level C/C++ code.

Merovius 3y ago
That depends. C function call overhead for Go is quite large (it needs to allocate a larger stack, put it on its own thread and prevent pre-emption) and possibly larger than for CPython, which relies on calling into C for pretty much everything it does, so obviously has that path well-optimized. So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go.
- gwd 3y ago
  > So I wouldn't be surprised if, for some use cases, Python calling C in a tight loop could outperform Go. I don't have experience with Python, but I can definitely say switching between Go and C is super slow. I'm using a golang package which is a wrapper around SQLite: at some point I had a custom function written as a call-back to a Go function; profiling showed that a huge amount of time was spent in the transition code marshalling stuff back and forth between Go and C. I ended up writing the function in C so that the C sqlite3 library could call it directly, and it sped up my benchmarks significantly, maybe 5x. Even though sqlite3 is local, I still end up trying to minimize requests and data shipped out of the database, because transferring data in and out is so expensive. (And if you're curious, yes I have considered trying to use one of the "pure go" sqlite3 packages; in large part it's a question of trust: the core sqlite3 library is tested fantastically well; do I trust the reimplementations enough not to lose my data? The performance would have to be pretty compelling to make it worth the risk.) I think in general discouraging CGo makes sense, as in the vast majority of cases a re-implementation is better in the long run; so de-prioritizing CGo performance also makes sense. But there are exceptions, particularly for libraries where you want functionality to be identical, like sqlite3 or Qt, and there the CGo performance is a distinct downside.
iainmerrick 3y ago
Do you have an example of that? What I’ve heard over and over in comments here is that a) C interop in Go is slow, and b) Go devs discourage using it. (Java is a similar story in my experience.) In Python, (b) at least is definitely not true.
- deleted 3y ago
  [deleted]