Grokbase › Groups › Go › golang-dev › March 2016
FAQ
Hi, golang-dev!

Some of you may already have seen it, I wrote a document on the current
state of bounds-checking elimination. The document is here
<https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit> and
linked from #14808 <https://github.com/golang/go/issues/14808>.

You can request edit/comment permissions by clicking View Only -> Request
edit access. Alternatively, you can leave your questions and comments here.
The feedback I'm looking are examples that show performance regression when
bounds checks are enabled. By default bounds checks are enabled, but they
can be disabled with -gcflags=-B.

Regards,

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

Search Discussions

  • Brendan Tracey at Mar 17, 2016 at 3:12 pm ⇧
    Would you like regressions against 1.6 or against tip?
    On Mar 17, 2016, at 9:08 AM, Alexandru Moșoi wrote:

    Hi, golang-dev!

    Some of you may already have seen it, I wrote a document on the current state of bounds-checking elimination. The document is here <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit> and linked from #14808 <https://github.com/golang/go/issues/14808>.

    You can request edit/comment permissions by clicking View Only -> Request edit access. Alternatively, you can leave your questions and comments here. The feedback I'm looking are examples that show performance regression when bounds checks are enabled. By default bounds checks are enabled, but they can be disabled with -gcflags=-B.

    Regards,

    --
    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+[email protected] For more options, visit https://groups.google.com/d/optout <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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Alexandru Moșoi at Mar 17, 2016 at 3:18 pm ⇧
    Against tip are the most interesting ones wrt to performance.

    Master uses a different compiler backend for amd64 so it may be hard to
    isolate the issue. In any case if you see any performance regression
    between tip and 1.6 you should file a bug.

    joi, 17 martie 2016, 16:12:38 UTC+1, Brendan Tracey a scris:
    Would you like regressions against 1.6 or against tip?

    On Mar 17, 2016, at 9:08 AM, Alexandru Moșoi <[email protected]
    <javascript:>> wrote:

    Hi, golang-dev!

    Some of you may already have seen it, I wrote a document on the current
    state of bounds-checking elimination. The document is here
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit> and
    linked from #14808 <https://github.com/golang/go/issues/14808>.

    You can request edit/comment permissions by clicking View Only -> Request
    edit access. Alternatively, you can leave your questions and comments here.
    The feedback I'm looking are examples that show performance regression when
    bounds checks are enabled. By default bounds checks are enabled, but they
    can be disabled with -gcflags=-B.

    Regards,

    --
    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 [email protected] <javascript:>.
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Klauspost at Mar 19, 2016 at 8:39 am ⇧
    Hi!


    Very nice! Thanks for the writeup.

    Do you know if bounds checks can be eliminated by the maximum value of type
    of the lookup value. For instance a 'byte' can be no more than 255, uint16
    65535?

    For example:

    https://gist.github.com/klauspost/6f5a6ed922c5616c116a#file-boundscheck-go-L37

    It would be a bit silly if you had to write a[i&0xff] if 'i' is already a
    byte. This would be a great help for compression and similar algorithms.

    The other examples seems covered AFAICT.

    /Klaus

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Alexandru Moșoi at Mar 19, 2016 at 9:13 am ⇧
    Yes. I already had something prepared but didn't it mailed out because
    there are only just a few cases in stdlib. I'll send Monday the necessary
    rewrite rules.
    On Sat, Mar 19, 2016, 9:39 AM wrote:

    Hi!


    Very nice! Thanks for the writeup.

    Do you know if bounds checks can be eliminated by the maximum value of
    type of the lookup value. For instance a 'byte' can be no more than 255,
    uint16 65535?

    For example:


    https://gist.github.com/klauspost/6f5a6ed922c5616c116a#file-boundscheck-go-L37

    It would be a bit silly if you had to write a[i&0xff] if 'i' is already a
    byte. This would be a great help for compression and similar algorithms.

    The other examples seems covered AFAICT.

    /Klaus

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-dev" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-dev/VVPG8PXeHCU/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    [email protected].
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Klauspost at Mar 19, 2016 at 9:27 am ⇧

    On Saturday, 19 March 2016 10:13:08 UTC+1, Alexandru Moșoi wrote:
    Yes. I already had something prepared but didn't it mailed out because
    there are only just a few cases in stdlib. I'll send Monday the necessary
    rewrite rules.
    Great stuff - I know at least a few places where it could be added. For
    instance

    https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L679

    I assume it would need a b = b[:256] re-slice (your document doesn't
    explicitly say), but I have a lot of similar cases, where I can make a
    pre-loop assertion and that should help eliminate bounds checks. The
    masking feature already helps this a lot.

    For instance, the code
    above: https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L656
    - doing a "x:= w.bytes[n:n+6]" and write to x[0..5] should already
    eliminate some checks.


    /Klaus

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Alexandru Moșoi at Apr 1, 2016 at 10:04 am ⇧
    I've updated the doc
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit?usp=sharing>
    based on the recent compiler improvements.

    In particular the following examples are working as expected.

    // using a hint
    _ = a[3] // early bounds check
    use a[1], a[2], a[3] // no bounds checks

    // using decreasing constant indexes
    use a[3], a[2], a[1] // one bounds check

    // iterating over a slice
    for i := range a {
       use a[i] // no bounds check
    }


    Find more examples in test/prove.go
    <https://go.googlesource.com/go/+/master/test/prove.go> and in
    test/loopbce.go <https://go.googlesource.com/go/+/master/test/loopbce.go>.

    Again, I'm interested to know examples (especially from stdlib) where the
    compiler doesn't do a good job to eliminate bounds. If you think it should
    please file a bug explaining why (but make sure to check the examples
    first).


    joi, 17 martie 2016, 16:08:49 UTC+1, Alexandru Moșoi a scris:
    Hi, golang-dev!

    Some of you may already have seen it, I wrote a document on the current
    state of bounds-checking elimination. The document is here
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit> and
    linked from #14808 <https://github.com/golang/go/issues/14808>.

    You can request edit/comment permissions by clicking View Only -> Request
    edit access. Alternatively, you can leave your questions and comments here.
    The feedback I'm looking are examples that show performance regression when
    bounds checks are enabled. By default bounds checks are enabled, but they
    can be disabled with -gcflags=-B.

    Regards,
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Klauspost at Apr 3, 2016 at 11:08 am ⇧

    On Friday, 1 April 2016 12:04:41 UTC+2, Alexandru Moșoi wrote:
    I've updated the doc
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit?usp=sharing>
    based on the recent compiler improvements.

    In particular the following examples are working as expected.

    // using a hint
    _ = a[3] // early bounds check
    use a[1], a[2], a[3] // no bounds checks
    This is really great. I already have a few places where this will help,
    particularly places like this:

    https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L296

    and this:

    https://github.com/golang/go/blob/master/src/compress/flate/deflate.go#L273

    Great work - I'm looking forward to testing some numbers.

    Just a quick question - will the bounds check eliminations show on when
    using -ldflags '-m'?


    /Klaus



    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Giovanni Bajo at Apr 3, 2016 at 3:54 pm ⇧

    On Sunday, April 3, 2016 at 1:09:00 PM UTC+2, [email protected] wrote:
    On Friday, 1 April 2016 12:04:41 UTC+2, Alexandru Moșoi wrote:

    I've updated the doc
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit?usp=sharing>
    based on the recent compiler improvements.

    In particular the following examples are working as expected.

    // using a hint
    _ = a[3] // early bounds check
    use a[1], a[2], a[3] // no bounds checks
    This is really great. I already have a few places where this will help,
    particularly places like this:


    https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L296

    and this:

    https://github.com/golang/go/blob/master/src/compress/flate/deflate.go#L273
    Make also sure to check that the generated code compacts multiple byte
    reads/writes to a single word access.

    Giovanni

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Keith Randall at Apr 3, 2016 at 7:38 pm ⇧

    On Sun, Apr 3, 2016 at 4:08 AM, wrote:
    On Friday, 1 April 2016 12:04:41 UTC+2, Alexandru Moșoi wrote:

    I've updated the doc
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit?usp=sharing>
    based on the recent compiler improvements.

    In particular the following examples are working as expected.

    // using a hint
    _ = a[3] // early bounds check
    use a[1], a[2], a[3] // no bounds checks
    This is really great. I already have a few places where this will help,
    particularly places like this:


    https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L296

    and this:

    https://github.com/golang/go/blob/master/src/compress/flate/deflate.go#L273

    Great work - I'm looking forward to testing some numbers.

    Just a quick question - will the bounds check eliminations show on when
    using -ldflags '-m'?

    Right now you'll have to use -d=ssa/prove/debug (in -gcflags, not
    -ldflags). Maybe we should turn on relevant ssa pass flags when -m is
    provided.
    /Klaus



    --
    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 [email protected].
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Alexandru Moșoi at Apr 5, 2016 at 12:51 pm ⇧
    Since bce happens over different passes you can now use checkbce pass to
    debug bounds checks:

    % go build -gcflags="-d=ssa/check_bce/debug=1" boundscheck.go
    # command-line-arguments
    ./boundscheck.go:17: Found IsInBounds
    ./boundscheck.go:22: Found IsSliceInBounds
    ./boundscheck.go:26: Found IsInBounds
    ./boundscheck.go:35: Found IsInBounds
    ./boundscheck.go:71: Found IsInBounds




    duminică, 3 aprilie 2016, 21:38:07 UTC+2, Keith Randall a scris:

    On Sun, Apr 3, 2016 at 4:08 AM, <[email protected] <javascript:>> wrote:
    On Friday, 1 April 2016 12:04:41 UTC+2, Alexandru Moșoi wrote:

    I've updated the doc
    <https://docs.google.com/document/d/1vdAEAjYdzjnPA9WDOQ1e4e05cYVMpqSxJYZT33Cqw2g/edit?usp=sharing>
    based on the recent compiler improvements.

    In particular the following examples are working as expected.

    // using a hint
    _ = a[3] // early bounds check
    use a[1], a[2], a[3] // no bounds checks
    This is really great. I already have a few places where this will help,
    particularly places like this:


    https://github.com/golang/go/blob/master/src/compress/flate/huffman_bit_writer.go#L296

    and this:


    https://github.com/golang/go/blob/master/src/compress/flate/deflate.go#L273

    Great work - I'm looking forward to testing some numbers.

    Just a quick question - will the bounds check eliminations show on when
    using -ldflags '-m'?

    Right now you'll have to use -d=ssa/prove/debug (in -gcflags, not
    -ldflags). Maybe we should turn on relevant ssa pass flags when -m is
    provided.
    /Klaus



    --
    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 [email protected] <javascript:>.
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Klauspost at Apr 10, 2016 at 1:11 pm ⇧
    Thanks a lot for the information. This mode is very helpful!

    By just making it easier for the compiler to spot un-needed bounds checks,
    I was able to get 3-9% faster deflate encoding:

    https://go-review.googlesource.com/#/c/21759/2


    Great work!

    /Klaus

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Marvin Stenger at Apr 10, 2016 at 4:30 pm ⇧
    @Alexandru:
    Could you add the following case:
    https://play.golang.org/p/jR7kltq0xx

    This occurred in a slightly changed version in Klaus' CL

    Best,
    Marvin

    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Alexandru Moșoi at Apr 10, 2016 at 4:58 pm ⇧
    Hi, Marvin!

    In this case you could do for i := range a {} to get rid of the bounds
    check. Specific to your program, bounds checks are inserted because we
    moved the lowering of len(a) (i.e. lowering to max) to a later stage. This
    was a conscious decision and allows us to keep StringLen and SliceLen
    available for the intermediary passes. In reality we need some kind of
    logic to keep track of things like: this argument is now also length of
    this slice / string. This is one example, but I'd like to see several more
    in order to understand how to generalize. Please file a bug and cc me on it.

    Regards,

    duminică, 10 aprilie 2016, 18:30:02 UTC+2, Marvin Stenger a scris:
    @Alexandru:
    Could you add the following case:
    https://play.golang.org/p/jR7kltq0xx

    This occurred in a slightly changed version in Klaus' CL

    Best,
    Marvin
    --
    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 [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Giovanni Bajo at Apr 11, 2016 at 2:00 am ⇧

    On Sunday, April 10, 2016 at 3:11:11 PM UTC+2, [email protected] wrote:
    Thanks a lot for the information. This mode is very helpful!

    By just making it easier for the compiler to spot un-needed bounds checks,
    I was able to get 3-9% faster deflate encoding:

    https://go-review.googlesource.com/#/c/21759/2
    Nice! Are you planning to also see if you can speed up decoding? I still
    fallback to use my hacked fastGzReader
    (https://gist.github.com/d42a52c16683f1a2f4dccdef80e2712d) when performance
    is crucial, which is a pity...

    Giovanni

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 17, '16 at 3:08p
activeApr 11, '16 at 2:00a
posts15
users6
websitegolang.org

6 users in discussion

Alexandru Moșoi: 6 posts Klauspost: 4 posts Giovanni Bajo: 2 posts Brendan Tracey: 1 post Keith Randall: 1 post Marvin Stenger: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase