Hacker News Reader

Comment by swdunlop | Hacker News Reader

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/

You can't wrap Lightning itself, otherwise any possible gains you could expect are lost at the CGO transition.

View on HN

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

[2] http://code.google.com/p/go/source/browse/src/pkg/runtime/as...

[3] http://code.google.com/p/go/source/browse/src/pkg/runtime/cg...

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! :)

Reply on news.ycombinator.com