FAQ
The changes from yesterday to today give me a 4%-5% speedup (64 bit intel.)
This is huge to me, as I'm willing to do almost anything in terms of
rewriting, data layout changes, etc. to get 2% and I've already done
everything I could think of to coax a little bit more out of the compilers
(extra braces to narrow variable lifetimes, profiling and switch
reordering, recursion removal, DIY CSE, and so on.) Bravo!

Sample output is from a my exact cover solver (in this case running single
threaded) at about 64 million updates per second on my MacBookPro. This is
up from 61 Mu/s on yesterday's tip, which is really super. Updates are
Knuth's Dancing Links updates and Gap(15,1) is the 30-element Langford
pairing. (http://oeis.org/A014552)

# Gap(13, 4): 129220 solutions 2406091 nodes
34510000 updates 0.534 s 64.619 Mu/s
# Gap(13, 2): 360876 solutions 5586798 nodes
81469260 updates 1.224 s 66.576 Mu/s
# Gap(13, 0): 1520280 solutions 14940920 nodes
219953588 updates 3.391 s 64.872 Mu/s
# Gap(15, 7): 329816 solutions 6433598 nodes
94719176 updates 1.503 s 63.030 Mu/s
# Gap(15, 5): 3912272 solutions 82944237 nodes
1180126632 updates 18.014 s 65.511 Mu/s
# Gap(15, 3): 10346528 solutions 197704780 nodes
2866894951 updates 44.190 s 64.876 Mu/s
# Gap(15, 1): 39809640 solutions 550148348 nodes
7965822480 updates 122.084 s 65.249 Mu/s
Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
650-335-5765

Search Discussions

  • Kyle Lemons at Nov 2, 2012 at 1:19 am
    Just to satisfy my own curiosity... what's your speedup from go1.0.3 to tip?

    On Thu, Nov 1, 2012 at 3:59 PM, Michael Jones wrote:

    The changes from yesterday to today give me a 4%-5% speedup (64 bit
    intel.) This is huge to me, as I'm willing to do almost anything in terms
    of rewriting, data layout changes, etc. to get 2% and I've already done
    everything I could think of to coax a little bit more out of the compilers
    (extra braces to narrow variable lifetimes, profiling and switch
    reordering, recursion removal, DIY CSE, and so on.) Bravo!

    Sample output is from a my exact cover solver (in this case running single
    threaded) at about 64 million updates per second on my MacBookPro. This is
    up from 61 Mu/s on yesterday's tip, which is really super. Updates are
    Knuth's Dancing Links updates and Gap(15,1) is the 30-element Langford
    pairing. (http://oeis.org/A014552)

    # Gap(13, 4): 129220 solutions 2406091 nodes
    34510000 updates 0.534 s 64.619 Mu/s
    # Gap(13, 2): 360876 solutions 5586798 nodes
    81469260 updates 1.224 s 66.576 Mu/s
    # Gap(13, 0): 1520280 solutions 14940920 nodes
    219953588 updates 3.391 s 64.872 Mu/s
    # Gap(15, 7): 329816 solutions 6433598 nodes
    94719176 updates 1.503 s 63.030 Mu/s
    # Gap(15, 5): 3912272 solutions 82944237 nodes
    1180126632 updates 18.014 s 65.511 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes
    2866894951 updates 44.190 s 64.876 Mu/s
    # Gap(15, 1): 39809640 solutions 550148348 nodes
    7965822480 updates 122.084 s 65.249 Mu/s
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • Michael Jones at Nov 2, 2012 at 2:44 pm
    Hmm...

    babar:src mtj$ ./all.bash
    # Building C bootstrap tool.
    cmd/dist

    # Building compilers and Go bootstrap tool for host, darwin/amd64.
    go tool dist: /Users/mtj/go/src/cmd/cov should not exist in release build
    On Thu, Nov 1, 2012 at 6:18 PM, Kyle Lemons wrote:
    Just to satisfy my own curiosity... what's your speedup from go1.0.3 to tip?

    On Thu, Nov 1, 2012 at 3:59 PM, Michael Jones wrote:

    The changes from yesterday to today give me a 4%-5% speedup (64 bit
    intel.) This is huge to me, as I'm willing to do almost anything in terms of
    rewriting, data layout changes, etc. to get 2% and I've already done
    everything I could think of to coax a little bit more out of the compilers
    (extra braces to narrow variable lifetimes, profiling and switch reordering,
    recursion removal, DIY CSE, and so on.) Bravo!

    Sample output is from a my exact cover solver (in this case running single
    threaded) at about 64 million updates per second on my MacBookPro. This is
    up from 61 Mu/s on yesterday's tip, which is really super. Updates are
    Knuth's Dancing Links updates and Gap(15,1) is the 30-element Langford
    pairing. (http://oeis.org/A014552)

    # Gap(13, 4): 129220 solutions 2406091 nodes
    34510000 updates 0.534 s 64.619 Mu/s
    # Gap(13, 2): 360876 solutions 5586798 nodes
    81469260 updates 1.224 s 66.576 Mu/s
    # Gap(13, 0): 1520280 solutions 14940920 nodes
    219953588 updates 3.391 s 64.872 Mu/s
    # Gap(15, 7): 329816 solutions 6433598 nodes
    94719176 updates 1.503 s 63.030 Mu/s
    # Gap(15, 5): 3912272 solutions 82944237 nodes
    1180126632 updates 18.014 s 65.511 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes
    2866894951 updates 44.190 s 64.876 Mu/s
    # Gap(15, 1): 39809640 solutions 550148348 nodes
    7965822480 updates 122.084 s 65.249 Mu/s
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • Rob Pike at Nov 2, 2012 at 2:50 pm
    The release build requires you not to have things not meant for
    release. Just wipe that directory. It'll come back when you return to
    tip.

    -rob
  • Michael Jones at Nov 2, 2012 at 3:01 pm
    thanks. building now...

    rm -rf /Users/mtj/go/src/cmd/cov
    rm -rf /Users/mtj/go/src/cmd/prof
    ./all.bash
    On Fri, Nov 2, 2012 at 7:50 AM, Rob Pike wrote:
    The release build requires you not to have things not meant for
    release. Just wipe that directory. It'll come back when you return to
    tip.

    -rob


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • Michael Jones at Nov 2, 2012 at 3:25 pm
    Single CPU (on 3.0 GHz X5365 Quad-core Intel Xeon "Clovertown"):

    Go 1.0.3:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 16.267 s 72.546 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 39.268 s 73.009 Mu/s

    Go tip:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 15.518 s 76.049 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 37.663 s 76.119 Mu/s

    16.267s => 15.518s = -4.6%
    39.268s => 37.663s = -4.1%
    On Fri, Nov 2, 2012 at 8:01 AM, Michael Jones wrote:
    thanks. building now...

    rm -rf /Users/mtj/go/src/cmd/cov
    rm -rf /Users/mtj/go/src/cmd/prof
    ./all.bash
    On Fri, Nov 2, 2012 at 7:50 AM, Rob Pike wrote:
    The release build requires you not to have things not meant for
    release. Just wipe that directory. It'll come back when you return to
    tip.

    -rob


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • Kyle Lemons at Nov 2, 2012 at 3:43 pm
    Not too shabby. I love that with Go, at least for the near future, your
    programs are somewhat likely to get faster without you having to do
    anything but recompile periodically :).

    On Fri, Nov 2, 2012 at 8:24 AM, Michael Jones wrote:

    Single CPU (on 3.0 GHz X5365 Quad-core Intel Xeon "Clovertown"):

    Go 1.0.3:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 16.267 s 72.546 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 39.268 s 73.009 Mu/s

    Go tip:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 15.518 s 76.049 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 37.663 s 76.119 Mu/s

    16.267s => 15.518s = -4.6%
    39.268s => 37.663s = -4.1%

    On Fri, Nov 2, 2012 at 8:01 AM, Michael Jones wrote:
    thanks. building now...

    rm -rf /Users/mtj/go/src/cmd/cov
    rm -rf /Users/mtj/go/src/cmd/prof
    ./all.bash
    On Fri, Nov 2, 2012 at 7:50 AM, Rob Pike wrote:
    The release build requires you not to have things not meant for
    release. Just wipe that directory. It'll come back when you return to
    tip.

    -rob


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • J L Vanderzwan at Nov 2, 2012 at 5:55 pm
    On that note: did someone optimise the image libraries? When I switched to
    tip I after hearing claims of performance improvements, I got the
    impression one of my toy programs that does a lot of PNG encoding/decoding
    became a lot faster.
    On Friday, 2 November 2012 16:43:01 UTC+1, Kyle Lemons wrote:

    Not too shabby. I love that with Go, at least for the near future, your
    programs are somewhat likely to get faster without you having to do
    anything but recompile periodically :).


    On Fri, Nov 2, 2012 at 8:24 AM, Michael Jones <m...@google.com<javascript:>
    wrote:
    Single CPU (on 3.0 GHz X5365 Quad-core Intel Xeon "Clovertown"):

    Go 1.0.3:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 16.267 s 72.546 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 39.268 s 73.009 Mu/s

    Go tip:
    # Gap(15, 5): 3912272 solutions 82944237 nodes 1180126632
    updates 15.518 s 76.049 Mu/s
    # Gap(15, 3): 10346528 solutions 197704780 nodes 2866894951
    updates 37.663 s 76.119 Mu/s

    16.267s => 15.518s = -4.6%
    39.268s => 37.663s = -4.1%


    On Fri, Nov 2, 2012 at 8:01 AM, Michael Jones <m...@google.com<javascript:>>
    wrote:
    thanks. building now...

    rm -rf /Users/mtj/go/src/cmd/cov
    rm -rf /Users/mtj/go/src/cmd/prof
    ./all.bash

    On Fri, Nov 2, 2012 at 7:50 AM, Rob Pike <r...@golang.org <javascript:>>
    wrote:
    The release build requires you not to have things not meant for
    release. Just wipe that directory. It'll come back when you return to
    tip.

    -rob


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +1
    650-335-5765


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +1
    650-335-5765
  • Minux at Nov 2, 2012 at 6:41 pm

    On Sat, Nov 3, 2012 at 1:55 AM, wrote:

    On that note: did someone optimise the image libraries? When I switched to
    tip I after hearing claims of performance improvements, I got the
    impression one of my toy programs that does a lot of PNG encoding/decoding
    became a lot faster.
    yes.
    please read the output of:
    hg log -r default:release-branch.go1 src/pkg/image/png
    src/pkg/compress/flate
    for more details.
  • J L Vanderzwan at Nov 2, 2012 at 8:28 pm
    Maybe I'm doing something wrong, but that doesn't produce any output for me
    whatsoever. I've tried hg log --help, but I don't see what could be wrong
    with the command..
    On Friday, 2 November 2012 19:41:41 UTC+1, minux wrote:


    On Sat, Nov 3, 2012 at 1:55 AM, <j.l.van...@gmail.com <javascript:>>wrote:
    On that note: did someone optimise the image libraries? When I switched
    to tip I after hearing claims of performance improvements, I got the
    impression one of my toy programs that does a lot of PNG encoding/decoding
    became a lot faster.
    yes.
    please read the output of:
    hg log -r default:release-branch.go1 src/pkg/image/png
    src/pkg/compress/flate
    for more details.
  • Devon H. O'Dell at Nov 2, 2012 at 8:33 pm
    2012/11/2 <j.l.vanderzwan@gmail.com>
    Maybe I'm doing something wrong, but that doesn't produce any output for me whatsoever. I've tried hg log --help, but I don't see what could be wrong with the command..
    Maybe you need to update:

    $ hg pull -u
    $ hg log -r default:release-branch.go1 src/pkg/image/png src/pkg/compress/flate
    changeset: 14784:4f5ad3a5b26d
    user: Nigel Tao <nigeltao@golang.org>
    date: Fri Nov 02 17:20:19 2012 +1100
    summary: image/png: update palette out-of-bounds comment.

    changeset: 14760:d6e11ab78b7d
    user: Ryan Hitchman <hitchmanr@gmail.com>
    date: Thu Nov 01 13:57:24 2012 -0400
    summary: compress/flate: shrink decompressor struct for better performance

    changeset: 14749:58206fbe45a9
    user: Nigel Tao <nigeltao@golang.org>
    date: Thu Nov 01 11:46:06 2012 +1100
    summary: image/png: degrade gracefully for palette index values that aren't

    --dho
    On Friday, 2 November 2012 19:41:41 UTC+1, minux wrote:

    On Sat, Nov 3, 2012 at 1:55 AM, wrote:

    On that note: did someone optimise the image libraries? When I switched to tip I after hearing claims of performance improvements, I got the impression one of my toy programs that does a lot of PNG encoding/decoding became a lot faster.
    yes.
    please read the output of:
    hg log -r default:release-branch.go1 src/pkg/image/png src/pkg/compress/flate
    for more details.
  • Nigel Tao at Nov 2, 2012 at 11:24 pm

    On Sat, Nov 3, 2012 at 7:33 AM, Devon H. O'Dell wrote:
    $ hg log -r default:release-branch.go1 src/pkg/image/png src/pkg/compress/flate
    I may be mangling the hg branch model here, but I think that that only
    lists differences from since the release branch was most recently
    cut?? That "hg log" only lists changes since November 1. The Go
    release has backported some image/png changes from tip, but only bug
    fixes, and not performance enhancements, and the rough estimate is
    that e.g. PNG decoding is 2x faster in tip compared to release:
    https://groups.google.com/d/msg/golang-nuts/RxQ96lckPQ4/ydCJL51Xko4J
  • J L Vanderzwan at Nov 3, 2012 at 8:31 am

    On Saturday, 3 November 2012 00:24:10 UTC+1, Nigel Tao wrote:
    On Sat, Nov 3, 2012 at 7:33 AM, Devon H. O'Dell wrote:
    $ hg log -r default:release-branch.go1 src/pkg/image/png
    src/pkg/compress/flate

    I may be mangling the hg branch model here, but I think that that only
    lists differences from since the release branch was most recently
    cut?? That "hg log" only lists changes since November 1. The Go
    release has backported some image/png changes from tip, but only bug
    fixes, and not performance enhancements, and the rough estimate is
    that e.g. PNG decoding is 2x faster in tip compared to release:
    https://groups.google.com/d/msg/golang-nuts/RxQ96lckPQ4/ydCJL51Xko4J
    I'm using Gray16 images, so if I read those patch sets correctly the
    speed-up is even greater. I'm running Go on an old slow netbook, so when
    measured in absolute time (meaning seconds, not percentages) this is a
    substantial improvement for me. Thank you for these optimisations!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 1, '12 at 11:06p
activeNov 3, '12 at 8:31a
posts13
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase