4 ms·

You can, but Go doesn't really have a good way to link in the product at runtime. Maybe something like a Go version of GNU Lightning would be a fun project --

You can, but Go doesn't really have a good way to link in the product at runtime. Maybe something like a Go version of GNU Lightning would be a fun project -- http://www.gnu.org/software/lightning/ http://www.gnu.org/software/lightning/ You can't wrap Lightning itself, otherwise any possible gains you could expect are lost at the CGO transition.

lcampbell 14y ago
> 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...
- swdunlop 14y ago
  Interesting. It appears that cgocall has improved from the last time I went down this rabbit hole. Previously, it used a pthread_create to construct a C stack and context on each runtime.cgocall and then waited on a mutex for it to return. The overhead was enough to make me favor image/png Encode over libpng for smaller images. Time to go profiling again! :)

lcampbell 14y ago

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

swdunlop 14y ago
Interesting. It appears that cgocall has improved from the last time I went down this rabbit hole. Previously, it used a pthread_create to construct a C stack and context on each runtime.cgocall and then waited on a mutex for it to return. The overhead was enough to make me favor image/png Encode over libpng for smaller images. Time to go profiling again! :)