3 ms·

Sure you can have a million goroutines, but you’ll now have more scheduler and gc overhead, and this is part of the issue. Calling out to ffi requires preparin

by raggi 2y ago

Sure you can have a million goroutines, but you’ll now have more scheduler and gc overhead, and this is part of the issue. Calling out to ffi requires preparing both the stack and the runtime for that call. It’s theoretically possible to avoid the need for this preparation, but with some caveats - you have to block the gc view of parts of the world (the parts ffi could be using) and you need to ensure that your runtime isn’t interacting badly with the ffi environment (e.g. not sending it signals and so on). Go’s arrangement (as is common with most runtimes) needs to active work to prevent both problems, and the cost of cgo is largely the cost of doing those things. Most managed runtime/gc languages have these challenges and it’s one of the axes that people say makes them not systems languages (a poorly defined term for sure, but fair on an axis of “can’t make calls to other software modules at base call cost”)

neonsunset 2y ago
The cause of this is not a technical limitation of "this is not possible" but rather "Go does this poorly due to tradeoffs* it insists on". C# trivially pins only select buffers or other data that need to be observed by whatever it is being called across FFI while GC is free to move and handle everything else (or, should the data need to be marshalled, it can be stack-allocated and pointer to such is passed instead, or it can be malloc and freed just like you can do in C). Years of work in this area made the impact of FFI as minimal as possible, with extra levers available to the user to completely erase the overhead (suppressing GC frame transition, using methods to allocate objects on the dedicated pinned heap, static linking for aot binaries, etc.). Go's GC implementation is comparatively simple and has other inefficiencies such as very expensive write barriers. *sometimes the tradeoff is just a product, which Go is, that was cheaper to produce, despite common beliefs
- raggi 2y ago
  Yup, and far too much spinning going on in the runtime too.

by raggi 2y ago

neonsunset 2y ago

The cause of this is not a technical limitation of "this is not possible" but rather "Go does this poorly due to tradeoffs* it insists on". C# trivially pins only select buffers or other data that need to be observed by whatever it is being called across FFI while GC is free to move and handle everything else (or, should the data need to be marshalled, it can be stack-allocated and pointer to such is passed instead, or it can be malloc and freed just like you can do in C). Years of work in this area made the impact of FFI as minimal as possible, with extra levers available to the user to completely erase the overhead (suppressing GC frame transition, using methods to allocate objects on the dedicated pinned heap, static linking for aot binaries, etc.). Go's GC implementation is comparatively simple and has other inefficiencies such as very expensive write barriers. *sometimes the tradeoff is just a product, which Go is, that was cheaper to produce, despite common beliefs

raggi 2y ago
Yup, and far too much spinning going on in the runtime too.