Hacker News Re-Imagined

Comparing the C FFI overhead on various languages

  • 111 points
  • 15 hours ago

  • @generichuman
  • Created a post

Comparing the C FFI overhead on various languages


@KSPAtlas 12 hours

Replying to @generichuman 🎙

What about Common Lisp?

Reply


@cube2222 12 hours

Just a caveat, not sure if it matters in practice, but this benchmark is using very old versions of many languages it's comparing (5 year old ones).

Reply


@haberman 10 hours

Some 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.

Reply


@SemanticStrengh 11 hours

Java has a new API for FFI called the foreign memory interface

Reply


@throw827474737 13 hours

So why isn't C the baseline (and zig and rust being pretty close to it quite expected), but both luajit and julia are significantly faster??

Reply


@exebook 13 hours

I developed a terminal emulator, file manager and text editor Deodar 8 years ago in JavaScript/V8 with native C++ calls, it worked but I was extremely disappointed by speed, it felt so slow like you need to do a passport control each time you call a C++ function.

Reply


@ksec 1 hour

Missing 2014, or 2018 in the title.

Reply


@dgan 8 hours

I had to run it to believe, I confirm it's 183 seconds(!) for python3 on my laptop

Also, OCaml because I was interested (milliseconds):

    ocaml(int,noalloc,native) = 2022
    ocaml(int,alloc,native) = 2344
    ocaml(int,untagged,native) = 1912
    ocaml(int32,noalloc,native) = 1049
    ocaml(int32,alloc,native) = 1556
    ocaml(int32,boxed,native) = 7544

Reply


@khoobid_shoma 13 hours

I guess it is better to measure CPU time instead of wall time (e.g. using clock() ).

Reply


@tomas789 11 hours

There 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

Reply


@ta988 10 hours

Java has project Panama coming that may improve things a little.

Reply


@planetis 7 hours

That Nim version has just left kindergarten and is prepping for elementary.

Reply


@WalterBright 8 hours

The D programming language has literally a zero overhead to interface with C. The same calling conventions are used, the types are the same.

D can also access C code by simply importing a .c file:

    import foo;  // call functions from foo.c
analogously to how you can `#include "foo.h"` in C++.

Reply


@mhh__ 10 hours

Needs LTO, with that it will have 0 overhead in the compiled languages.

D can actually compile the C code in this test now.

Reply


@sdze 11 hours

Can you try PHP?

Reply


@sk0g 10 hours

For a game scripting language, Wren posts a pretty bad result here. Think it has isn't explicitly game focused though. The version tested is quite old however, having released in 2016.

Reply


@kllrnohj 12 hours

Another major caveat to this benchmark is it doesn't include any significant marshalling costs. For example, passing strings or arrays from Java to C is much, much slower than passing a single integer. Same is going to be true for a lot (all?) of the GC'd languages, and especially true for strings when the language isn't utf8 natively (as in, even though Java can store in utf8 internally, it doesn't expose that publicly so JNI doesn't benefit)

Reply


@alkonaut 12 hours

Any idea why mono is used rather than .NET here?

Reply


@ryukoposting 11 hours

This ia a cool concept, but the implementation is contrived (as many others describe). e.g. JNI array marshalling/unmarshalling has a lot of overhead. The Nim version is super outdated too (not sure about the other languages).

Reply


@dunefox 10 hours

> - julia 0.6.3

That's an ancient version, the current version is v1.7.2.

Reply


@thot_experiment 2 hours

n.b. this is using an absolutely ancient version of node, though i'm not sure that would change anything, worth nothing

Reply


@TazeTSchnitzel 9 hours

It seems Rust has basically no overhead versus C, but it could have negative overhead if you use cross-language LTO. Of course, you can do LTO between C files too, so that would be unfair. But I think this sets it apart from languages that, even with a highly optimised FFI, don't have compiler support for LTO with C code.

Reply


About Us

site design / logo © 2022 Box Piper