> You can't wrap Lightning itself What prevents wrapping lightning? (I'm not at all familiar with Lightning) > any possible gains you could expect are lost at

> You can't wrap Lightning itself What prevents wrapping lightning? (I'm not at all familiar with Lightning) > any possible gains you could expect are lost at the CGO transition I was under the impression that the CGO overhead was due to marshaling data -- could that not be avoided by representing the JIT'd code as unsafe.Pointer's and type annotations (akin to how reflect invokes reflect.Values)? Or is there a whole realm of stuff I'm missing? EDIT: Did a bit of digging; reflect.Value.Call internally uses reflect·call (defined in runtime[1]), which obviously uses the Go ABI. Since any JIT'd code we want to load will expect to be called with the C ABI, presumably, we're stuck with runtime·asmcgocall[2]. Combined with runtime·cgocall[3], it certainly is longer than a vanilla preamble in C, so there's definitely some significant overhead not related to, e.g., cgo.GoString. I don't have enough prowess to determine the actual performance impact, though :( Could be a fun weekend project. -- [1] http://code.google.com/p/go/source/browse/src/pkg/runtime/asm_386.s#229 http://code.google.com/p/go/source/browse/src/pkg/runtime/as... [2] http://code.google.com/p/go/source/browse/src/pkg/runtime/asm_386.s#437 http://code.google.com/p/go/source/browse/src/pkg/runtime/as... [3] http://code.google.com/p/go/source/browse/src/pkg/runtime/cgocall.c#100 http://code.google.com/p/go/source/browse/src/pkg/runtime/cg...