4 ms·

> The standard C library's runtime environment is designed for C, and it generally contains a tangled skein of assumptions about how things work. Forcing all ot

> The standard C library's runtime environment is designed for C, and it generally contains a tangled skein of assumptions about how things work. Forcing all other languages to fit themselves into these undocumented constraints is clearly confining, and the standard C library generally isn't designed to be a transparent API; in fact, at least GNU libc deliberately manipulates what it does under the hood to be more useful to C programs. It's hard to reconcile this with the fact that every other language besides Go manages to interface with the standard c library just fine. It seems like if it were such a big problem, you'd see more languages opting out.

atombender 6y ago
The reason Go does it is because the overhead of calling C code from Go is relatively high. Other languages typically don't suffer from this friction. The closest I can think of is Java, but I have no idea how much is reimplemented in pure Java to avoid the overhead of JNI.
- asdfasgasdgasdg 6y ago
  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.
- pjmlp 6y ago
  One of the goals of Panama is to replace JNI, actually.
- nabla9 6y ago
  This is weird because 2/3 of Go creators are the ultimate C and Unix hackers: Rob Pike and Ken Thompson.
  - tyingq 6y ago
    Both were also key members of Plan9. The golang ABI is influenced by it (though they aren't the same).
    - pjmlp 6y ago
      Including Inferno and Limbo, that everyone keeps forgetting about.
- twic 6y ago
  JNI is expensive, but the JDK implementers give themselves some much more efficient ways to call into native code that aren't available to us mere mortals. For example, "HotSpot intrinsics", which are mostly used to hook into JVM internals, but also for some performance critical stuff: https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc Ordinary native methods implemented by the JVM itself don't need to use JNI either.
- deleted 6y ago
  [deleted]

atombender 6y ago

The reason Go does it is because the overhead of calling C code from Go is relatively high. Other languages typically don't suffer from this friction. The closest I can think of is Java, but I have no idea how much is reimplemented in pure Java to avoid the overhead of JNI.

asdfasgasdgasdg 6y ago
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.
pjmlp 6y ago
One of the goals of Panama is to replace JNI, actually.
nabla9 6y ago
This is weird because 2/3 of Go creators are the ultimate C and Unix hackers: Rob Pike and Ken Thompson.
- tyingq 6y ago
  Both were also key members of Plan9. The golang ABI is influenced by it (though they aren't the same).
  - pjmlp 6y ago
    Including Inferno and Limbo, that everyone keeps forgetting about.
twic 6y ago
JNI is expensive, but the JDK implementers give themselves some much more efficient ways to call into native code that aren't available to us mere mortals. For example, "HotSpot intrinsics", which are mostly used to hook into JVM internals, but also for some performance critical stuff: https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc https://gist.github.com/apangin/7a9b7062a4bd0cd41fcc Ordinary native methods implemented by the JVM itself don't need to use JNI either.
deleted 6y ago
[deleted]