On Tue, 18 Oct 2016 22:12:44 -0700 (PDT) tpoisonooo <tpoison...@gmail.com> wrote:
> My colleague gives me a `face_recognization.so`, > `face_recognization.so` use `libcaffe.so`. > I compiled it with cgo based on arm. [...] > 1. In his C++ demo, `Face_Feature_Extract` function always cost 0.1 > second. > > 2. In my golang code, the `extractFeature` in load_so.c costs 1.8 or > 0.1 second, sometimes the caffe function in libcaffe.so spent 1.8 > second, sometimes it is normal. > > 3. If I loop `extractFeature` function 1000 times in `load_so.c`, > average execution time is 0.1 second. [...] > I doubt that cgo1.7 is not stable, anybody can help me? Does the situation change if, in the goroutine you're measuring your calls, you do runtime.LockOSThread() // cgo calling and measuring code here as it exists now. defer runtime.UnlockOSThread() ? The reason I'm asking is that calling C code via cgo from a Go program works way differently than calling C code from a C program. In the latter case you just perform "normal" call of a function. In the former case it looks more like a syscall because the "C side" is quite alien to the "Go side" (to begin with, they use different stacks). So the first thing I'd try is to acquire a dedicated OS thread for the goroutine calling the C side and see if that helps. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
