Grokbase › Groups › Go › golang-nuts › July 2013
FAQ
I've noticed that re-writing functions in assembler seems to disable
Go's escape analysis.

In the particular example I'm working on that causes go to allocate
objects on the heap rather than the stack in the calling Go function
which for some test cases outweighs the goodness of converting the
called function to assembler!

To be specific in the below g() has been converted to assembler. That
seems to force f() to allocate `data` on the heap rather than the stack
like it used to when g() was in Go.

func f() {
     var data [64]byte
     g(data)
}

Any ideas on how to get round this?

Thanks

Nick
--
Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dave Cheney at Jul 17, 2013 at 9:47 pm ⇧
    Grep for //go:noescape
    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
    I've noticed that re-writing functions in assembler seems to disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to assembler. That
    seems to force f() to allocate `data` on the heap rather than the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Jul 17, 2013 at 10:09 pm ⇧
    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape
    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
    I've noticed that re-writing functions in assembler seems to disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to assembler. That
    seems to force f() to allocate `data` on the heap rather than the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Jul 17, 2013 at 10:14 pm ⇧
    It's an undocumented secret annotation that only the gc compilers support. Don't tell anyone.
    On 18/07/2013, at 8:08, Nick Craig-Wood wrote:

    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape
    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
    I've noticed that re-writing functions in assembler seems to disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to assembler. That
    seems to force f() to allocate `data` on the heap rather than the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick
    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Jul 18, 2013 at 6:00 pm ⇧

    On 17/07/13 23:14, Dave Cheney wrote:
    It's an undocumented secret annotation that only the gc compilers support. Don't tell anyone.
    http://golang.org/cmd/gc/ - compiler directives ;-)

    I can't seem to make it work though :-(

    I made a before and after test here to demonstrate. I hope I'm just
    doing something stupid!

    https://github.com/ncw/go-noescape-test

    Thanks in advance for any help!
    On 18/07/2013, at 8:08, Nick Craig-Wood wrote:

    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape
    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
    I've noticed that re-writing functions in assembler seems to disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to assembler. That
    seems to force f() to allocate `data` on the heap rather than the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Jul 18, 2013 at 6:25 pm ⇧
    please don't leave any empty lines between the annotation and the
    declaration.

    search for the annotation in the go tree for examples.
      On Jul 19, 2013 2:00 AM, "Nick Craig-Wood" wrote:
    On 17/07/13 23:14, Dave Cheney wrote:
    It's an undocumented secret annotation that only the gc compilers
    support. Don't tell anyone.

    http://golang.org/cmd/gc/ - compiler directives ;-)

    I can't seem to make it work though :-(

    I made a before and after test here to demonstrate. I hope I'm just
    doing something stupid!

    https://github.com/ncw/go-noescape-test

    Thanks in advance for any help!
    On 18/07/2013, at 8:08, Nick Craig-Wood wrote:

    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape
    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood wrote:
    I've noticed that re-writing functions in assembler seems to disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to assembler. That
    seems to force f() to allocate `data` on the heap rather than the
    stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> --
    http://www.craig-wood.com/nick
    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Jul 18, 2013 at 6:34 pm ⇧
    That doesn't fix it unfortunately.

    Also there are examples of exactly that style in the go source, eg

    http://golang.org/src/pkg/bytes/bytes_decl.go
    On 18/07/13 19:25, minux wrote:
    please don't leave any empty lines between the annotation and the
    declaration.

    search for the annotation in the go tree for examples.

    On Jul 19, 2013 2:00 AM, "Nick Craig-Wood" wrote:
    On 17/07/13 23:14, Dave Cheney wrote:
    It's an undocumented secret annotation that only the gc compilers
    support. Don't tell anyone.

    http://golang.org/cmd/gc/ - compiler directives ;-)

    I can't seem to make it work though :-(

    I made a before and after test here to demonstrate. I hope I'm just
    doing something stupid!

    https://github.com/ncw/go-noescape-test

    Thanks in advance for any help!
    On 18/07/2013, at 8:08, Nick Craig-Wood wrote:

    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape

    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood
    wrote:
    I've noticed that re-writing functions in assembler seems to
    disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to allocate
    objects on the heap rather than the stack in the calling Go
    function
    which for some test cases outweighs the goodness of converting the
    called function to assembler!

    To be specific in the below g() has been converted to
    assembler. That
    seems to force f() to allocate `data` on the heap rather than
    the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]
    -- http://www.craig-wood.com/nick
    --
    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+[email protected]
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]
    -- http://www.craig-wood.com/nick


    --
    Nick Craig-Wood <[email protected] -- http://www.craig-wood.com/nick

    --
    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+[email protected]
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Jul 18, 2013 at 6:40 pm ⇧

    2013/7/18 Nick Craig-Wood <[email protected]>:
    That doesn't fix it unfortunately.

    Also there are examples of exactly that style in the go source, eg

    http://golang.org/src/pkg/bytes/bytes_decl.go
    If you are using Go 1.1 you may be affected by issue 5773.

    http://code.google.com/p/go/issues/detail?id=5773

    Rémy.

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Jul 18, 2013 at 10:30 pm ⇧

    On 18/07/13 19:40, Rémy Oudompheng wrote:
    2013/7/18 Nick Craig-Wood <[email protected]>:
    That doesn't fix it unfortunately.

    Also there are examples of exactly that style in the go source, eg

    http://golang.org/src/pkg/bytes/bytes_decl.go
    If you are using Go 1.1 you may be affected by issue 5773.

    http://code.google.com/p/go/issues/detail?id=5773
    Yes that sounds like it!

    I've been using go 1.1.1 - I'll try again with go tip.

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Craig-Wood at Jul 18, 2013 at 11:09 pm ⇧

    On 18/07/13 23:30, Nick Craig-Wood wrote:
    On 18/07/13 19:40, Rémy Oudompheng wrote:
    2013/7/18 Nick Craig-Wood <[email protected]>:
    That doesn't fix it unfortunately.

    Also there are examples of exactly that style in the go source, eg

    http://golang.org/src/pkg/bytes/bytes_decl.go
    If you are using Go 1.1 you may be affected by issue 5773.

    http://code.google.com/p/go/issues/detail?id=5773
    Yes that sounds like it!

    I've been using go 1.1.1 - I'll try again with go tip.
    I tried again with go tip and can confirm that //go:noescape is now
    working as expected!

    --
    Nick Craig-Wood <[email protected]> -- http://www.craig-wood.com/nick

    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • David DENG at Jul 18, 2013 at 10:42 pm ⇧
    I think the compiler should fail for this situation instead of ignoring it
    silently, as what the compiler does to unused variables.

    David
    On Friday, July 19, 2013 2:34:05 AM UTC+8, Nick Craig-Wood wrote:

    That doesn't fix it unfortunately.

    Also there are examples of exactly that style in the go source, eg

    http://golang.org/src/pkg/bytes/bytes_decl.go
    On 18/07/13 19:25, minux wrote:
    please don't leave any empty lines between the annotation and the
    declaration.

    search for the annotation in the go tree for examples.

    On Jul 19, 2013 2:00 AM, "Nick Craig-Wood" <[email protected]<javascript:>
    <mailto:[email protected] <javascript:>>> wrote:
    On 17/07/13 23:14, Dave Cheney wrote:
    It's an undocumented secret annotation that only the gc compilers
    support. Don't tell anyone.

    http://golang.org/cmd/gc/ - compiler directives ;-)

    I can't seem to make it work though :-(

    I made a before and after test here to demonstrate. I hope I'm just
    doing something stupid!

    https://github.com/ncw/go-noescape-test

    Thanks in advance for any help!
    On 18/07/2013, at 8:08, Nick Craig-Wood <[email protected]<javascript:>
    <mailto:[email protected] <javascript:>>> wrote:
    Exactly what I was looking for - thanks!

    It didn't work immediately - I'll try some more in the morning.
    On 17/07/13 22:47, Dave Cheney wrote:
    Grep for //go:noescape

    On Thu, Jul 18, 2013 at 7:45 AM, Nick Craig-Wood
    <[email protected] <javascript:> wrote:
    I've noticed that re-writing functions in assembler seems to
    disable
    Go's escape analysis.

    In the particular example I'm working on that causes go to
    allocate
    objects on the heap rather than the stack in the calling Go
    function
    which for some test cases outweighs the goodness of converting
    the
    called function to assembler!

    To be specific in the below g() has been converted to
    assembler. That
    seems to force f() to allocate `data` on the heap rather than
    the stack
    like it used to when g() was in Go.

    func f() {
    var data [64]byte
    g(data)
    }

    Any ideas on how to get round this?

    Thanks

    Nick
    --
    Nick Craig-Wood <[email protected] <javascript:>
    <mailto:[email protected] <javascript:>>> --
    http://www.craig-wood.com/nick
    --
    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 [email protected] <javascript:>
    <mailto:golang-nuts%[email protected] <javascript:>>.
    For more options, visit
    https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected] <javascript:>
    <mailto:[email protected] <javascript:>>> --
    http://www.craig-wood.com/nick

    --
    Nick Craig-Wood <[email protected] <javascript:> <mailto:
    [email protected] <javascript:>>>
    -- http://www.craig-wood.com/nick

    --
    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 [email protected] <javascript:>
    <mailto:golang-nuts%[email protected] <javascript:>>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    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 [email protected] <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    Nick Craig-Wood <[email protected] <javascript:>> --
    http://www.craig-wood.com/nick
    --
    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 [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 17, '13 at 9:45p
activeJul 18, '13 at 11:09p
posts11
users5
websitegolang.org

5 users in discussion

Nick Craig-Wood: 6 posts Dave Cheney: 2 posts Minux: 1 post David DENG: 1 post Rémy Oudompheng: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase