Detect synchronization-only FFI calls that can piggyback on the next native operation #869

Generalizable finding

A dependency-tracked GPU graph can lose its kernel-side gain when every producer-consumer fence is emitted through a separate language boundary.

In GoAI's M2 Metal decode prototype, the first correct implementation called a tiny CGo Barrier function at every graph dependency (about 264 new Go-to-C crossings per token), immediately before an existing CGo kernel-recording call. Seven order-alternated same-binary pairs retained only 1.0184x median GPU improvement and regressed median wall throughput to 0.9302x under host contention.

The retained implementation stores the pending fence in Go and piggybacks one barrierBefore bit on the next existing native kernel call. The Objective-C side executes the identical memoryBarrierWithScope:MTLBarrierScopeBuffers before encoding that kernel. The same seven-pair gate then measured:

• GPU duration speedup: 1.0350x median
• wall duration speedup: 1.0300x median
• paired GPU-ratio spread: 1.0053x
• identical final-logit digest in every arm: d706f8fb616cef3b

This is not Metal-specific: a hot loop containing a trivial CGo/FFI synchronization call immediately followed by another call into the same native subsystem is a candidate for state deferral or flag piggybacking. A perfscan check could flag adjacent hot-path native calls where the first has synchronization-only semantics and its state can be consumed by the second, with an explicit suppression for calls that must take effect before arbitrary host work.

Related prior issue: #732 (persistent Metal command encoding). This finding isolates the cross-language scheduling overhead that determines whether the GPU-side improvement survives end to end.