[Lerc]

I'm not familiar with go but I seem to recall it is garbage collected.

If so it may be something to do with the creation of new vectors on the heap instead of the stack. The compiler would have to determine the full lifetime of the vector value to be able to bump it to the stack. That's an optimization, and sometimes it's just not possible (but probably is here).

In the C instance no such optimization is necessary. They ask for it on the stack, and if you try to use it after the stack is gone, Bad Things™ happen.

A hypothesis to test would be that languages above the jump are managing to work on the stack and ones below are allocating objects on the heap.

[weberc2]

Is it creating vectors in the hot path? I'm not seeing it. Go does some escape analysis (the optimization you're referring to), but it's pretty conservative.

[Lerc]

All of the vector operations return new vectors instead of mutating.

    func v3_add (a, b v3) v3 {
     return v3{x: a.x + b.x, y: a.y + b.y, z: a.z + b.z}
    }

A sensible approach for maintainable code but without knowing if a and b are used elsewhere the compiler can't reuse the space they occupy. If C can't figure it out, it can just stick a new one on the stack which doesn't cost too much.

This is, of course, Rust's bread and butter which is probably why it takes the top spot.

[weberc2]

Those are copied on the stack, not heap allocated, so the GC wouldn't come into play.