Java has a new FFI API https://openjdk.java.net/jeps/419
which has different performance characteristics.
Using jdk 18 (stable) would be fair too.

Also for Java c++ interop, the best library is
https://github.com/bytedeco/javacpp

While dmd does generate reasonable code, dmd's backend isn't exactly this century (even though it does very well).

For a better comparison against C++ with gcc, it would be best to use ldc (maybe even gdc?) as well.

The results from your test showed go was really slow. For simplicity I combined everything into it's own file. I'm getting a result of 110 ms (vs 37879). I may be misunderstanding something.

package main

/*
#include <stdio.h>
#include <sys/time.h>

int plus(int x, int y)
{
    return x + y;
}

int plusone(int x)
{
    return x + 1;
}

long long current_timestamp()
{
    struct timeval te; 
    gettimeofday(&te, NULL); // get current time
    long long milliseconds = te.tv_sec*1000LL + te.tv_usec/1000; // caculate milliseconds
    
    return milliseconds;
}
*/
import "C"
import "fmt"
import "os"
import "strconv"

func run(count C.int) {
    start := C.current_timestamp()
    
    var x C.int = 0
    for x < count {
        x = C.plusone(x)
    }
    
    fmt.Println(C.current_timestamp() - start)
}

func main() {
    if (len(os.Args) == 1) {
        fmt.Println("First arg (0 - 2000000000) is required.")
        return
    }
    
    count, err := strconv.Atoi(os.Args[1])
    if err != nil || count <= 0 || count > 2000000000 {
        fmt.Println("Must be a positive number not exceeding 2 billion.");
        return
    }
    
    // load
    C.plusone(C.int(C.current_timestamp()))
    
    // start
    run(C.int(count))
}

go version go1.9.2 darwin/amd64

Core i5 Mac

It would be useful to have C/C++ measurements for direct addressed calls (i.e. non-PLT) as this is likely the fastest call possible and would make for a common baseline to compare other languages against.

Python is another language which commonly calls into C functions.

Since you benchmark the entire program elapsed time, the loop itself — evaluating the exit condition, looking up the variable, and jumping back or out — adds to the execution time. The body of the loop is tiny, just a single FFI call, so the loop overhead is very likely significant, especially in the interpreted languages.

A simple fix is to unroll the loop several times. Maybe something like (here's the Wren one):

class FFI {
    foreign static plusone(x)
    foreign static count()
    foreign static start()
    foreign static stop()
}
var x = 0
var count = FFI.count()
// try call
FFI.plusone(x)

FFI.start()
while (x < count) {
    x = FFI.plusone(FFI.plusone(FFI.plusone(FFI.plusone(FFI.plusone(x)))))
}
FFI.stop()

My hunch is that you'll see quite different relative numbers if you do this for all the languages. Right now, your benchmarks probably show the relative performance of assigning variables and looping more than they do FFI.

.NET Core 2.1 runs on linux and installs-compiles from command line. I hope to see C# or F# test. Just plug here issues so that will return and do the stuff when trying dotnet toolchain on linux.

Go and Dart have had optimization passes on their FFI implementations. Rust has also gotten some compiler improvements that may impact this. A fresh update of the benchmark is due.

Hey I was looking more into the Java test and I found your comment of the added 25%. You should remove that and just do a + b inline because you are already paying the price of jumping from Java to native land so it makes no sense to add yet another indirection that is not needed. I would like to see what the best possible is.