FAQ
We've banned C in user packages. But assembly is not less dangerous to
use with respect to stack pointers information. Do we want to say
something about assembly in docs or in release notes?

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Russ Cox at Sep 24, 2014 at 9:10 pm

    On Wed, Sep 24, 2014 at 4:56 PM, 'Dmitry Vyukov' via golang-dev wrote:

    We've banned C in user packages. But assembly is not less dangerous to
    use with respect to stack pointers information. Do we want to say
    something about assembly in docs or in release notes?
    issue 8712

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ahmed Waheed at Sep 29, 2014 at 12:12 pm
    Please don't remove the assembler too, at least until cgo isn't stupidly
    slow.

    Maybe using .syso files should be documented better too.
    On Wednesday, September 24, 2014 11:56:49 PM UTC+3, Dmitry Vyukov wrote:

    We've banned C in user packages. But assembly is not less dangerous to
    use with respect to stack pointers information. Do we want to say
    something about assembly in docs or in release notes?
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Sep 29, 2014 at 12:39 pm

    On Mon, Sep 29, 2014 at 4:12 PM, Ahmed Waheed wrote:
    Please don't remove the assembler too, at least until cgo isn't stupidly
    slow.
    What's the problem with cgo? I don't see any open issue on cgo performance.

    Maybe using .syso files should be documented better too.
    On Wednesday, September 24, 2014 11:56:49 PM UTC+3, Dmitry Vyukov wrote:

    We've banned C in user packages. But assembly is not less dangerous to
    use with respect to stack pointers information. Do we want to say
    something about assembly in docs or in release notes?
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+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-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Sep 29, 2014 at 1:28 pm
    Issue #8712 that Russ mentions is about documenting the assembler
    rather than forbidding its execution from the go tool. I don't think
    there are plans to discourage its use when necessary.
    On Mon, Sep 29, 2014 at 9:12 AM, Ahmed Waheed wrote:
    Please don't remove the assembler too, at least until cgo isn't stupidly
    slow.

    Maybe using .syso files should be documented better too.
    On Wednesday, September 24, 2014 11:56:49 PM UTC+3, Dmitry Vyukov wrote:

    We've banned C in user packages. But assembly is not less dangerous to
    use with respect to stack pointers information. Do we want to say
    something about assembly in docs or in release notes?
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --

    gustavo @ http://niemeyer.net

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Sep 29, 2014 at 1:45 pm

    On Mon, Sep 29, 2014 at 8:12 AM, Ahmed Waheed wrote:

    Please don't remove the assembler too, at least until cgo isn't stupidly
    slow.
    I don't think cgo is slow at all. We've spent a lot of time working on its
    performance and making it about as fast as it can reasonably be. There is
    certainly nothing about its speed caused by stupidity.

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ahmed Waheed at Sep 29, 2014 at 2:34 pm
    My apologizes, stupidly is a little harsh, I blame the caffeine and lack of
    sleep.

    I just miss being easily able to embed C without cgo or using an external
    build script to build a syso.

    And at the risk of being off topic, here's a little observation.

          git clone https://github.com/OneOfOne/cgoVSsyso && cd cgoVSsyso &&
    ./test.sh

    On my computer that prints:

    syso: 12000000 50000000 37.3 ns/op 8 B/op 1
    allocs/op
    cgo: 12000000 10000000 166 ns/op 0 B/op 0 allocs/op


    I understand the need for stack splitting for cgo, but if there's any way
    to turn that off for some functions it would be nice.

    Again apologizes for calling cgo stupidly slow and being off topic for the
    list.

    I'll be quiet now and go to bed.
    On Monday, September 29, 2014 3:45:21 PM UTC+2, rsc wrote:

    On Mon, Sep 29, 2014 at 8:12 AM, Ahmed Waheed <oneo...@gmail.com
    <javascript:>> wrote:
    Please don't remove the assembler too, at least until cgo isn't stupidly
    slow.
    I don't think cgo is slow at all. We've spent a lot of time working on its
    performance and making it about as fast as it can reasonably be. There is
    certainly nothing about its speed caused by stupidity.

    Russ
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Sep 29, 2014 at 2:46 pm

    On Mon, Sep 29, 2014 at 10:34 AM, Ahmed Waheed wrote:
    And at the risk of being off topic, here's a little observation.

    git clone https://github.com/OneOfOne/cgoVSsyso && cd cgoVSsyso &&
    ./test.sh

    On my computer that prints:

    syso: 12000000 50000000 37.3 ns/op 8 B/op 1
    allocs/op
    cgo: 12000000 10000000 166 ns/op 0 B/op 0 allocs/op


    I understand the need for stack splitting for cgo, but if there's any way
    to turn that off for some functions it would be nice.
    You're skating on very thin ice jumping into gcc-compiled code that way. I
    would strongly encourage you not to do that. If you get unexplained memory
    corruption, you get to keep all the pieces.

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Sep 30, 2014 at 6:28 am

    On Mon, Sep 29, 2014 at 6:46 PM, Russ Cox wrote:
    On Mon, Sep 29, 2014 at 10:34 AM, Ahmed Waheed wrote:

    And at the risk of being off topic, here's a little observation.

    git clone https://github.com/OneOfOne/cgoVSsyso && cd cgoVSsyso &&
    ./test.sh

    On my computer that prints:

    syso: 12000000 50000000 37.3 ns/op 8 B/op 1
    allocs/op
    cgo: 12000000 10000000 166 ns/op 0 B/op 0 allocs/op


    I understand the need for stack splitting for cgo, but if there's any way
    to turn that off for some functions it would be nice.

    You're skating on very thin ice jumping into gcc-compiled code that way. I
    would strongly encourage you not to do that. If you get unexplained memory
    corruption, you get to keep all the pieces.
    What do you mean? Looks like a normal cgo call:

    func BenchmarkCgo(b *testing.B) {
       for i := 0; i < b.N; i++ {
         _ = C.mul(10, 20, 30, 40, 50)
       }
    }

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Sep 30, 2014 at 6:29 am

    On Tue, Sep 30, 2014 at 10:28 AM, Dmitry Vyukov wrote:
    On Mon, Sep 29, 2014 at 6:46 PM, Russ Cox wrote:
    On Mon, Sep 29, 2014 at 10:34 AM, Ahmed Waheed wrote:

    And at the risk of being off topic, here's a little observation.

    git clone https://github.com/OneOfOne/cgoVSsyso && cd cgoVSsyso &&
    ./test.sh

    On my computer that prints:

    syso: 12000000 50000000 37.3 ns/op 8 B/op 1
    allocs/op
    cgo: 12000000 10000000 166 ns/op 0 B/op 0 allocs/op


    I understand the need for stack splitting for cgo, but if there's any way
    to turn that off for some functions it would be nice.

    You're skating on very thin ice jumping into gcc-compiled code that way. I
    would strongly encourage you not to do that. If you get unexplained memory
    corruption, you get to keep all the pieces.
    What do you mean? Looks like a normal cgo call:

    func BenchmarkCgo(b *testing.B) {
    for i := 0; i < b.N; i++ {
    _ = C.mul(10, 20, 30, 40, 50)
    }
    }
    Ah, you meant the syso thing. YEs, looks scary.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Sep 30, 2014 at 6:30 am

    On Mon, Sep 29, 2014 at 6:34 PM, Ahmed Waheed wrote:
    My apologizes, stupidly is a little harsh, I blame the caffeine and lack of
    sleep.

    I just miss being easily able to embed C without cgo or using an external
    build script to build a syso.

    And at the risk of being off topic, here's a little observation.

    git clone https://github.com/OneOfOne/cgoVSsyso && cd cgoVSsyso &&
    ./test.sh

    On my computer that prints:

    syso: 12000000 50000000 37.3 ns/op 8 B/op 1
    allocs/op
    cgo: 12000000 10000000 166 ns/op 0 B/op 0 allocs/op


    I understand the need for stack splitting for cgo, but if there's any way to
    turn that off for some functions it would be nice.

    Again apologizes for calling cgo stupidly slow and being off topic for the
    list.

    I'll be quiet now and go to bed.


    If you need to multiply just 4 integers, then it's probably irrelevant
    whether it takes 10 ns or 100 ns. If you need to multiply mullions of
    integers, then squeeze it into a single cgo call. Then the cgo call
    overhead will be negligible.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Eloff at Oct 3, 2014 at 5:56 pm
    Please don't ban assembly in user packages. If people are using assembly
    it's because they have no better option, it's really the last option in a
    long list of distasteful options for improving the speed of the code.

    I suspect nobody uses lightly, I only use it when I have exhausted all
    other options and it's still too slow. Often this is because the compiled
    Go code cannot compete with cases where there is a processor instruction
    that does the same (e.g. bsr or bswap).

    Because most of the benefit in such cases is lost to the function call (no
    inlinable asm functions yet) I manually inline the asm by compiling,
    disassembling the caller, copying it into a .s file and then manually
    inlining the asm function. I think most cases I have to do this manual
    inlining because if the asm function were sufficiently bulky that the call
    overhead didn't matter, then I would have just written it in C and used cgo
    (again using assembly is the very last resort.)

    I really like that Go empowers me by at least allowing assembler if I find
    myself in the unhappy situation of having exhausted all other available
    options. I don't care that it's not documented and that it may break with
    future releases, I just care that it is possible rather than impossible.

    Cheers,
    Dan
    On Wednesday, September 24, 2014 3:56:49 PM UTC-5, Dmitry Vyukov wrote:

    We've banned C in user packages. But assembly is not less dangerous to
    use with respect to stack pointers information. Do we want to say
    something about assembly in docs or in release notes?
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Oct 3, 2014 at 6:11 pm
    Assembly will continue to be supported in user packages, at least for now.
    (I can't see it ever going away, actually, but no promises.)

    If you choose to use assembly, though, you will need to cooperate with the
    garbage collector to make sure everyone is on the same page about where the
    live pointers are. In practice this means your assembly functions should
    either have no stack frame at all or should store no pointers in the stack
    frame. Those are the cases that are easy to write and that are supported..

    Your trick of manually editing 6g -S output may continue to work, but it is
    definitely not something we are trying to support. You will have to keep
    the PCDATA and FUNCDATA annotations too, along with the data they refer to.
    It may stop working at any time.

    If I were you I would focus on trying to understand where the performance
    critical inner loop is and write that in clean assembly instead of tweaking
    6g -S output. A good example of this separation is the crypto hash
    functions like crypto/sha1. Only the sha1block function really needs to be
    fast, and it has a clean definition and can be generated without starting
    from 6g -S.

    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedSep 24, '14 at 8:56p
activeOct 3, '14 at 6:11p
posts13
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase