The best thing about gccgo is that it is not burdened with the weirdness of golang's calling convention, so the FFI overhead is basically the same as calling an extern function from C/C++. Take a look at [0] and see how bad golang's cgo calling latency compare to C. gccgo is not listed there but from my own testing it's the same as C/C++.
[0]: https://github.com/dyu/ffi-overhead
In GCC SC approves inclusion of Algol 68 Front Enddyu
ffi-overhead
C2014–2025
dyu / ffi-overhead
ffi-overhead
comparing the c ffi (foreign function interface) overhead on various programming languages
25Distinct people
28Mentions
0Explicit recommenders
700GitHub stars
What to know before exploring
What it is
comparing the c ffi (foreign function interface) overhead on various programming languages
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year28 dated mentions
Observed mentions: 2014-04-08 01:17:48 UTC to 2025-11-23 13:56:53 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
ffi-overhead
comparing the c ffi overhead on various programming languages
Requirements:
gcc
tup
zig
nim
v
java7
java8
go
rust
d (dmd and ldc2)
haskell (ghc)
ocaml
csharp (mono)
luajit
julia
node
dart
wren
elixir
My environment:
- Intel i7-3630QM laptop (4cores, HT) with 16g ram
- Ubuntu 14.04 x64
- gcc/g++ 5.4.1
- tup 0.7.4
- zig 0.2.0
- nim 0.14.3
- v 0.2.2 aebb551
- java 1.7.0_72 and 1.8.0_91
- go 1.8.0
- rust 1.17.0-nightly (c0b7112ba 2017-03-02)
- dmd 2.0.71.1
- ldc2 1.9.0
- ghc 7.10.3 (at /opt/ghc)
- ocaml 4.06.1
- mono 5.12.0.226
# dynamic languages
- luajit 2.0.4
- julia 0.6.3
- node 6.9.0 (at /opt/node)
- dart 1.22.0 (at /usr/lib/dart)
- wren 0.1.0
- elixir 1.6.5 (Erlang/OTP 20)
Initialize
tup init
Compile
./compile-all.sh
Compile opts:
-O2 (gcc - applies to c/jni/nim)
-C opt-level=2 (rust)
Run
./run-all.sh 1000000
Measurement:
call the c function "plusone" x number of times and print out the elapsed time in millis.
int x = 0;
while (x < count) x = plusone(x);
2 samples/runs
Results (500M calls)
./run-all.sh 500000000
The results are elapsed time in milliseconds
============================================
luajit:
891
905
julia:
894
889
c:
1182
1182
cpp:
1182
1183
zig:
1191
1190
nim:
1330
1330
v:
1779
1781
rust:
1193
1196
d:
1330
1330
d ldc2:
1191
1189
haskell:
1197
1198
ocamlopt:
1634
1634
ocamlc:
4299
4302
csharp mono:
2697
2690
java7:
4469
4472
java8:
4505
4472
node:
9163
9194
node scoped:
15425
15409
go:
37975
37879
dart:
31265
31282
dart scoped:
61906
69043
wren:
14519
14514
elixir:
23852
23752
Read the full README on GitHubWhat Hacker News says
28 sourcesComparing the C FFI overhead in various programming languages (2021)
5 points · Open discussionThe overhead for Go in benchmarks is insane in contrast to other languages - https://github.com/dyu/ffi-overhead Are there reasons why Go does not copy what Julia does?
In Leaving Rust gamedev after 3 yearsIt's not just that it's easy to embed but it's also tiny as well, I've run it on many embedded platforms. It wasn't until quickjs came along that there was anything even in the same ballpark.
When you factor in LuaJIT[1] and the incredible performance/zero-overhead-FFI[2] it really is a neat language.
[1] https://luajit.org/
[2] https://github.com/dyu/ffi-overhead
In Lua: The Little Language That CouldWhat about the other benchmarks on the same site? https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Bio/BCR/ BCR takes about a hundred seconds and is pretty indicative of systems biological models, coming from 1122 ODEs with 24388 terms that describe a stiff chemical reaction network modeling the BCR signaling network from Barua et al. Or the discrete diffusion models https://docs.sciml.ai/SciMLBenchmarksOutput/stable/Jumps/Dif... which are the justification behind the claims in https://www.biorxiv.org/content/10.1101/2022.07.30.502135v1 that the O(1) scaling methods scale better than O(log n) scaling for large enough models? There's lots of benchmarks on that site which show things from small to large. And small models do matter too...
> If you use special routines (BLAS/LAPACK, ...), use them everywhere as the respective community does
Read the rest
.
It tests with and with BLAS/LAPACK (which isn't always helpful, which of course you'd see from the benchmarks if you read them). One of the key differences of course though is that there are some pure Julia tools like https://github.com/JuliaLinearAlgebra/RecursiveFactorization... which outperform the respective OpenBLAS/MKL equivalent in many scenarios, and that's one noted factor for the performance boost (and is not trivial to wrap into the interface of the other solvers, so it's not done). There are other benchmarks showing that it's not apples to apples and is instead conservative in many cases, for example https://github.com/SciML/SciPyDiffEq.jl#measuring-overhead showing the SciPyDiffEq handling with the Julia JIT optimizations gives a lower overhead than direct SciPy+Numba, so we use the lower overhead numbers in https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLang....
> you must compile/write whole programs in each of the respective languages to enable full compiler/interpreter optimizations
You do realize that a .so has lower overhead to call from a JIT compiled language than from a static compiled language like C because you can optimize away some of the bindings at the runtime right? https://github.com/dyu/ffi-overhead is a measurement of that, and you see LuaJIT and Julia as faster than C and Fortran here. This shouldn't be surprising because it's pretty clear how that works?
I mean yes, someone can always ask for more benchmarks, but now we have a site that's auto updating tons and tons of ODE benchmarks with ODE systems ranging from size 2 to the thousands, with as many things as we can wrap in as many scenarios as we can wrap. And we don't even "win" all of our benchmarks because unlike for you, these benchmarks aren't for winning but for tracking development (somehow for Hacker News folks they ignore the utility part and go straight to language wars...).
If you have a concrete change you think can improve the benchmarks, then please share it at https://github.com/SciML/SciMLBenchmarks.jl. We'll be happy to make and maintain another.
Piling on about overhead (and SQLite), many high-level languages take some hit for using an FFI. So you're still incentivized to avoid tons of SQLite calls.
https://github.com/dyu/ffi-overhead
In Understanding the N + 1 queries problemSome of the results look outdated. The Dart results look bad (25x slower than C), but looking at the code (https://github.com/dyu/ffi-overhead/tree/master/dart) it appears to be five years old. Dart has a new FFI as of Dart 2.5 (2019): https://medium.com/dartlang/announcing-dart-2-5-super-charge... I'm curious how the new FFI would fare in these benchmarks.
In Comparing the C FFI overhead on various languagesThere is no Python benchmark but you can find a PR claiming it has 123,198ms. That would be a worst one by a wide margin.
https://github.com/dyu/ffi-overhead/pull/18
In Comparing the C FFI overhead on various languagesComparing the C FFI overhead on various languages
124 points · Open discussionFWIW, the overhead of calls across the cgo barrier is quite high, which can have API architecture implications -- https://github.com/dyu/ffi-overhead#results-500m-calls.
In Why Is SQLite Coded in C (2017)It depends on what's going on. JIT compilers have more information to optimize on so they can do surprising things. For example, FFI calls into shared libraries is generally faster with fast JIT languages.
https://github.com/dyu/ffi-overhead
This is one reason why you could see Julia outperforming Fortran in some cases where the FFI speed matters. But Fortran does have easier aliasing analysis (because you can't alias) so that helps there, but other than that most of the compiler passes are pretty much the same.
In Julia: Dynamism and Performance Reconciled by Design (2018)> C interop is simple and elegant
C interop in go is super slow: https://github.com/dyu/ffi-overhead
In The Value in Go’s Simplicity> Probably Go will be the next hotness in 5 years.
I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects.
[0]: https://github.com/dyu/ffi-overhead
In Python Is Eating the WorldJulia's `ccall` is great in terms of overhead[0], so calling Rust shared libraries is not a problem. On the Rust side, it took me a while to figure out passing in pointers, and then constructing slices via from_raw_parts[_mut], so that I can transition to safe Rust. Perhaps that is obvious to more experienced Rust programmers, but I was left with the impression that receiving pointers and crunching numbers is not yet a common application for Rust (unlike C, C++, or Fortran). Meaning there is not a lot of introductory material coming from that angle at the moment.
Additionally, to get good vectorization seems to require nightly and a fastfloat[1] library. In particular, you'd want associative math / fp-contract for fma and SIMD instructions, and perhaps fno-math-errno to turn off branches in functions like sqrt.
I imagine calling Rust from
Read the rest
Julia will be much more common than calling Julia from Rust. I know approximately nothing about this, but there are plenty of questions about embedding Julia into C/C++[2][3]. May be similar for Rust.
[0] https://github.com/dyu/ffi-overhead
[1] https://github.com/robsmith11/fastfloat
[2] https://discourse.julialang.org/t/support-with-embedding-jul...
[3] https://discourse.julialang.org/t/api-reference-for-julia-em...
Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.