3 ms·

That may be so. But that just seems like another way of saying, "Go has an issue with this and other languages don't." Why is calling into C so slow on Go and s

That may be so. But that just seems like another way of saying, "Go has an issue with this and other languages don't." Why is calling into C so slow on Go and so not slow in other languages like Java or C#?

atombender 6y ago
Because Go decided on a runtime design that doesn't play well with the OS. As far as I can gather: * Go uses its own calling convention that's different from C. * Go doesn't use system stacks (goroutines have their own growable stacks). * Goroutines are implemented as green threads using collaborative scheduling. Any call to C has to play nice with the scheduler to avoid blocking other goroutines running on the same thread. * Garbage collection often requires that data be copied in order to be passed to the C library, since the original data may be freed by GC during execution.
- Joker_vD 6y ago
  IAFAIK all of managed environments, be it Java or .NET or even Erlang/OTP, suffer from the last three points. And the Cygwin deffinitely suffers from the first one, because it uses SysV ABI instead of any of customary Win32 calling conventions (on x86, there was no "the" calling convention on Windows, everyone and their dog invented their own and then had to somehow interoperate with the others and with Win API itself... it wasn't pretty but it worked okay). Still, all those environments do pretty fine. Honestly, as someone who started their software developer education from Turbo Pascal/Delphi on DOS/Windows, system-level libc, and system-dictated ABI was a very surprising concept. Why do I have to follow some arbitrary register-usage rules inside my code? Why do I have to export functions from .so files using exactly this calling convention? Why does no one export "FreeXxx" from their libraries, why do they think I can just call "free()" when I'm done with the object they returned to me, I don't even have C's "free()" in my language? When the whole custom-memallocs rage hit the Linux scene, it was very amusing to watch how people were suddenly realizing the existence of "wait, a program can have several "malloc()/free()" inside it, how to chose right ones?" problem.
  - pjmlp 6y ago
    Same here. In what concerns Java and .NET, there are intrics (with annotations) that jump through some of the safety restrictions for AOT code and when running on JIT, it eventually short circuits some calls after it realises them as being safe. In any case, both platforms are pursuing alternative solutions to bring back those Delphi/Turbo Pascal like of calling into external code. Android also has such annotations that allows ART just to direct call into NDK code.

atombender 6y ago

Because Go decided on a runtime design that doesn't play well with the OS. As far as I can gather: * Go uses its own calling convention that's different from C. * Go doesn't use system stacks (goroutines have their own growable stacks). * Goroutines are implemented as green threads using collaborative scheduling. Any call to C has to play nice with the scheduler to avoid blocking other goroutines running on the same thread. * Garbage collection often requires that data be copied in order to be passed to the C library, since the original data may be freed by GC during execution.

Joker_vD 6y ago
IAFAIK all of managed environments, be it Java or .NET or even Erlang/OTP, suffer from the last three points. And the Cygwin deffinitely suffers from the first one, because it uses SysV ABI instead of any of customary Win32 calling conventions (on x86, there was no "the" calling convention on Windows, everyone and their dog invented their own and then had to somehow interoperate with the others and with Win API itself... it wasn't pretty but it worked okay). Still, all those environments do pretty fine. Honestly, as someone who started their software developer education from Turbo Pascal/Delphi on DOS/Windows, system-level libc, and system-dictated ABI was a very surprising concept. Why do I have to follow some arbitrary register-usage rules inside my code? Why do I have to export functions from .so files using exactly this calling convention? Why does no one export "FreeXxx" from their libraries, why do they think I can just call "free()" when I'm done with the object they returned to me, I don't even have C's "free()" in my language? When the whole custom-memallocs rage hit the Linux scene, it was very amusing to watch how people were suddenly realizing the existence of "wait, a program can have several "malloc()/free()" inside it, how to chose right ones?" problem.
- pjmlp 6y ago
  Same here. In what concerns Java and .NET, there are intrics (with annotations) that jump through some of the safety restrictions for AOT code and when running on JIT, it eventually short circuits some calls after it realises them as being safe. In any case, both platforms are pursuing alternative solutions to bring back those Delphi/Turbo Pascal like of calling into external code. Android also has such annotations that allows ART just to direct call into NDK code.