在 2016年10月19日星期三 UTC+8下午9:19:01，Konstantin Khomoutov写道： > > On Tue, 18 Oct 2016 22:12:44 -0700 (PDT) > tpoisonooo <tpois...@gmail.com <javascript:>> 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. >
Thanks for your help. It seems that libcaffe.so has thread-restriction. I removed `dlopen`, call `C. Face_Feature_Extract ` in main thread, execution time is stable. I have also checked https://groups.google.com/forum/#!msg/golang-nuts/IiWZ2hUuLDA/SNKYYZBelsYJ. -- 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.
