FAQ
What would be the fastest way, within a single linux process, to signal
between a goroutine and a cgo-induced C thread? Are futex available to
goroutines directly? Or is there a CGO/C-side interface to channels?

Thanks.

-Jason

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Dave Cheney at Jan 6, 2015 at 9:20 am
    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the futex may work, but that will end up consuming one thread per goroutine, so why make your like hard by writing in two languages at once?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jan 6, 2015 at 2:14 pm

    On Tue, Jan 6, 2015 at 1:20 AM, Dave Cheney wrote:
    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the futex may work, but that will end up consuming one thread per goroutine, so why make your like hard by writing in two languages at once?
    If you want some sort of blocking communication, I agree. I just want
    to note that you can do very limited communication by using atomic
    loads and stores of a shared memory location on both sides.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jason E. Aten at Jan 6, 2015 at 5:34 pm
    I have a bunch of fine grain C code I want to reuse, without the call overhead of cgo. I found a comment from 2009 saying if I compile C code with 6c then there would be no register set switching cost to call it from go[1]. Is that still an option today? i.e. compile the C code with 6c and link it with the Go code. If it is, could someone provide an example if how to link it?

    [1] https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsgZi88Q


    Thanks!
    Jason
    On Jan 6, 2015, at 6:14 AM, Ian Lance Taylor wrote:

    On Tue, Jan 6, 2015 at 1:20 AM, Dave Cheney wrote:
    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the futex may work, but that will end up consuming one thread per goroutine, so why make your like hard by writing in two languages at once?
    If you want some sort of blocking communication, I agree. I just want
    to note that you can do very limited communication by using atomic
    loads and stores of a shared memory location on both sides.

    Ian

    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/r-tZDZyifuo/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Jan 6, 2015 at 6:41 pm

    On Tue, Jan 6, 2015 at 9:34 AM, Jason E. Aten wrote:
    I have a bunch of fine grain C code I want to reuse, without the call
    overhead of cgo. I found a comment from 2009 saying if I compile C code with
    6c then there would be no register set switching cost to call it from go[1].
    Is that still an option today? i.e. compile the C code with 6c and link it
    with the Go code. If it is, could someone provide an example if how to link
    it?
    6c is gone on tip, so that is not an option.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Jan 6, 2015 at 8:01 pm

    On Tue, Jan 6, 2015 at 1:41 PM, Ian Lance Taylor wrote:
    On Tue, Jan 6, 2015 at 9:34 AM, Jason E. Aten wrote:

    I have a bunch of fine grain C code I want to reuse, without the call
    overhead of cgo. I found a comment from 2009 saying if I compile C code with
    6c then there would be no register set switching cost to call it from go[1].
    Is that still an option today? i.e. compile the C code with 6c and link it
    with the Go code. If it is, could someone provide an example if how to link
    it?
    6c is gone on tip, so that is not an option.
    There used to be tricks that run gcc compiled code on the Go stack, but
    those tricks are incompatible with the new precise GC and stack copying.

    If you want to call C code, use cgo (or swig).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jason E. Aten at Jan 6, 2015 at 10:01 pm

    On Tue, Jan 6, 2015 at 1:20 AM, Dave Cheney wrote:

    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the
    futex may work, but that will end up consuming one thread per goroutine

    I'm reading at

    https://github.com/golang/go/wiki/cgo

    that if I call into C via CGO first, then I can call back into go. Can
    these go callbacks do select and channel work?

    So the picture would look like:

    goroutine[1] -> cgo -> C-code -> go-callback-code -> receive on go channel
    A, send on go channel B

    goroutine[2] -> send on go channel A, receive on go channel B

    this seems like it should work, should it not? It seems to involve the go
    scheduler at the very least. :-)

    Thanks!

    Jason

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Matthew Zimmerman at Jan 6, 2015 at 10:02 pm
    Yes. That pattern has worked for me in the past.
    On Tue, Jan 6, 2015, 5:01 PM Jason E. Aten wrote:
    On Tue, Jan 6, 2015 at 1:20 AM, Dave Cheney wrote:

    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the
    futex may work, but that will end up consuming one thread per goroutine

    I'm reading at

    https://github.com/golang/go/wiki/cgo

    that if I call into C via CGO first, then I can call back into go. Can
    these go callbacks do select and channel work?

    So the picture would look like:

    goroutine[1] -> cgo -> C-code -> go-callback-code -> receive on go channel
    A, send on go channel B

    goroutine[2] -> send on go channel A, receive on go channel B

    this seems like it should work, should it not? It seems to involve the go
    scheduler at the very least. :-)

    Thanks!

    Jason

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jason E. Aten at Jan 6, 2015 at 10:10 pm

    On Tue, Jan 6, 2015 at 2:02 PM, Matthew Zimmerman wrote:

    Yes. That pattern has worked for me in the past.
    Great! Thanks Matthew.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Jan 6, 2015 at 10:04 pm
    I'd be more concerned with cgo overhead than scheduler overhead.
    On 7 Jan 2015 09:01, "Jason E. Aten" wrote:
    On Tue, Jan 6, 2015 at 1:20 AM, Dave Cheney wrote:

    You won't be able to do this without coordination with the go scheduler.

    If you are very lucky some combination of LockOSThread and invoking the
    futex may work, but that will end up consuming one thread per goroutine

    I'm reading at

    https://github.com/golang/go/wiki/cgo

    that if I call into C via CGO first, then I can call back into go. Can
    these go callbacks do select and channel work?

    So the picture would look like:

    goroutine[1] -> cgo -> C-code -> go-callback-code -> receive on go channel
    A, send on go channel B

    goroutine[2] -> send on go channel A, receive on go channel B

    this seems like it should work, should it not? It seems to involve the go
    scheduler at the very least. :-)

    Thanks!

    Jason
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jason E. Aten at Jan 6, 2015 at 10:09 pm

    On Tue, Jan 6, 2015 at 2:04 PM, Dave Cheney wrote:

    I'd be more concerned with cgo overhead than scheduler overhead.
    Right. Thus the idea is that I would only need to ever make one Go-> CGO ->
    C call, and I'm making the assumption that lots of C -> Go calls are very
    cheap/inexpensive (whereas the initial Go -> CGO is expensive). If the cost
    is symmetric then obviously this isn't a win, but I was assuming the
    gocallbacks were cheaper.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Jan 6, 2015 at 10:11 pm
    Any translation involving c and go is relatively expensive regardless of
    the direction.
    On 7 Jan 2015 09:09, "Jason E. Aten" wrote:
    On Tue, Jan 6, 2015 at 2:04 PM, Dave Cheney wrote:

    I'd be more concerned with cgo overhead than scheduler overhead.
    Right. Thus the idea is that I would only need to ever make one Go-> CGO
    -> C call, and I'm making the assumption that lots of C -> Go calls are
    very cheap/inexpensive (whereas the initial Go -> CGO is expensive). If the
    cost is symmetric then obviously this isn't a win, but I was assuming the
    gocallbacks were cheaper.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jason E. Aten at Jan 7, 2015 at 6:49 am

    On Tue, Jan 6, 2015 at 2:11 PM, Dave Cheney wrote:

    Any translation involving c and go is relatively expensive regardless of
    the direction.
    Oh my. You are certain correct, Dave. And it turns out to be the opposite
    of what I expected. When I measure, I find that the C -> Go transition is
    7x more expensive than the Go -> C transition. Using go 1.3, a C->Go call
    on my box takes on average 50 nsec, while adding a Go->C call adds on
    another 350 nsec.

    //file back.go
    package main

    // int global =
    0;

    //

    // int fortytwo(int
    num)

    //
    {

    // global +=
    num;

    // global += MyGoFunction(global,
    global);

    // global =
    global/3;

    // return
    global;

    //
    }

    import "C"
    import (
         "fmt"
         "time"
    )

    func main() {
         t0 := time.Now()
         N := 10000000
         tot := 0
         for i := 0; i < N; i++ {
             num := 1
             tot = int(C.fortytwo(C.int(num)))
         }
         fmt.Printf("N=%d, tot=%v, elap: %v\n", N, tot, time.Since(t0))
    }

    // go -> C
    only

    // without the MyGoFunction call: N=10000000, tot=0, elap:
    507.453317ms


    // go -> C ->
    go

    // with the MyGoFunction call: N=10000000, tot=10000000, elap:
    3.92221824s



    // file callb.go
    package main

    import "C"

    //export
    MyGoFunction

    func MyGoFunction(arg1, arg2 int) int64 {
         return int64(arg1 + arg2)
    }

    // run with: go run back.go callb.go

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Jan 12, 2015 at 1:45 pm

    On Tue, Jan 6, 2015 at 10:58 AM, Jason E. Aten wrote:
    What would be the fastest way, within a single linux process, to signal
    between a goroutine and a cgo-induced C thread? Are futex available to
    goroutines directly? Or is there a CGO/C-side interface to channels?

    The fastest option, of course, is to just do the work on the same
    thread w/o any blocking/unblocking. If that's not possible (which is
    usually due to artificial architectural limitations), then the answer
    depends on the definition of the fastest. Do you want minimal latency?
    Minimal producer overhead? Minimal consumer overhead? Minimal impact
    on overall system performance?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 6, '15 at 7:58a
activeJan 12, '15 at 1:45p
posts14
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase