FAQ
After upgrading to Go 1.1 on my Windows 7 system, I was curious about
performance improvements, so I went through some old Euler Project problem
code to see if it was faster.

Most of the time it was, but there was a peculiar case where I ugly-hacked
some code into using more CPU cores, and despite making sure all the ints
and uints were explicitly 32-bit, the code would run much slower (68s
instead of the earlier 43s). Looking at the CPU graph, I noticed that while
the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
binary hovered around 58% (4 cores bouncing up and down).

Now, I know my code is a terrible thing and should probably be locked up in
a dark dungeon, but it'd still be nice to know why this is happening
specifically, and how to avoid it in the future. For that reason, I've put
my test code up here:
http://play.golang.org/p/VvQYR97vym

And this is a graph of my CPU usage in 1.0.3 and 1.1:
http://i.imgur.com/xdhBvM6.png

I'm guessing something happened to the scheduler that Windows isn't happy
with. I can get around it by artificially increasing the cores variable
(and thus active goroutines) by 4 (to 16 on my system), but I don't fully
understand why, so explanations would be appreciated.

--
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/groups/opt_out.

Search Discussions

  • Dmitry Vyukov at May 29, 2013 at 1:02 pm
    Please file a bug at http://golang.org/issue/new
    I suspect that's because loosely speaking the runtime favors "server"
    workload over "computational".

    On Wed, May 29, 2013 at 4:53 PM, darkgray wrote:
    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I ugly-hacked
    some code into using more CPU cores, and despite making sure all the ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).

    Now, I know my code is a terrible thing and should probably be locked up in
    a dark dungeon, but it'd still be nice to know why this is happening
    specifically, and how to avoid it in the future. For that reason, I've put
    my test code up here:
    http://play.golang.org/p/VvQYR97vym

    And this is a graph of my CPU usage in 1.0.3 and 1.1:
    http://i.imgur.com/xdhBvM6.png

    I'm guessing something happened to the scheduler that Windows isn't happy
    with. I can get around it by artificially increasing the cores variable (and
    thus active goroutines) by 4 (to 16 on my system), but I don't fully
    understand why, so explanations would be appreciated.

    --
    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/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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Patrik Roos at May 29, 2013 at 1:08 pm
    Alright, posted https://code.google.com/p/go/issues/detail?id=5586
    On Wed, May 29, 2013 at 3:02 PM, Dmitry Vyukov wrote:
    Please file a bug at http://golang.org/issue/new
    I suspect that's because loosely speaking the runtime favors "server"
    workload over "computational".

    On Wed, May 29, 2013 at 4:53 PM, darkgray wrote:
    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I ugly-hacked
    some code into using more CPU cores, and despite making sure all the ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).

    Now, I know my code is a terrible thing and should probably be locked up in
    a dark dungeon, but it'd still be nice to know why this is happening
    specifically, and how to avoid it in the future. For that reason, I've put
    my test code up here:
    http://play.golang.org/p/VvQYR97vym

    And this is a graph of my CPU usage in 1.0.3 and 1.1:
    http://i.imgur.com/xdhBvM6.png

    I'm guessing something happened to the scheduler that Windows isn't happy
    with. I can get around it by artificially increasing the cores variable (and
    thus active goroutines) by 4 (to 16 on my system), but I don't fully
    understand why, so explanations would be appreciated.

    --
    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/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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at May 29, 2013 at 2:35 pm

    On Wednesday, May 29, 2013 6:02:56 AM UTC-7, Dmitry Vyukov wrote:
    Please file a bug at http://golang.org/issue/new
    I suspect that's because loosely speaking the runtime favors "server"
    workload over "computational".

    Could you explain what this means a little more?




    On Wed, May 29, 2013 at 4:53 PM, darkgray <dark...@gmail.com <javascript:>>
    wrote:
    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I
    ugly-hacked
    some code into using more CPU cores, and despite making sure all the ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).

    Now, I know my code is a terrible thing and should probably be locked up in
    a dark dungeon, but it'd still be nice to know why this is happening
    specifically, and how to avoid it in the future. For that reason, I've put
    my test code up here:
    http://play.golang.org/p/VvQYR97vym

    And this is a graph of my CPU usage in 1.0.3 and 1.1:
    http://i.imgur.com/xdhBvM6.png

    I'm guessing something happened to the scheduler that Windows isn't happy
    with. I can get around it by artificially increasing the cores variable (and
    thus active goroutines) by 4 (to 16 on my system), but I don't fully
    understand why, so explanations would be appreciated.

    --
    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...@googlegroups.com <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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jun 2, 2013 at 6:47 pm

    On Wed, May 29, 2013 at 6:35 PM, Brendan Tracey wrote:

    On Wednesday, May 29, 2013 6:02:56 AM UTC-7, Dmitry Vyukov wrote:

    Please file a bug at http://golang.org/issue/new
    I suspect that's because loosely speaking the runtime favors "server"
    workload over "computational".

    Could you explain what this means a little more?

    The scheduler is deliberately somewhat sloppy about waking new worker
    threads. This is required to not consume all available cores all the
    time in servers under moderate load.
    I think it can be fixed to reasonably satisfy both types of workload.

    On Wed, May 29, 2013 at 4:53 PM, darkgray wrote:
    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project
    problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I
    ugly-hacked
    some code into using more CPU cores, and despite making sure all the
    ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that
    while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).

    Now, I know my code is a terrible thing and should probably be locked up
    in
    a dark dungeon, but it'd still be nice to know why this is happening
    specifically, and how to avoid it in the future. For that reason, I've
    put
    my test code up here:
    http://play.golang.org/p/VvQYR97vym

    And this is a graph of my CPU usage in 1.0.3 and 1.1:
    http://i.imgur.com/xdhBvM6.png

    I'm guessing something happened to the scheduler that Windows isn't
    happy
    with. I can get around it by artificially increasing the cores variable
    (and
    thus active goroutines) by 4 (to 16 on my system), but I don't fully
    understand why, so explanations would be appreciated.

    --
    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...@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • James Bardin at May 29, 2013 at 3:40 pm

    On Wednesday, May 29, 2013 8:53:27 AM UTC-4, darkgray wrote:
    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I ugly-hacked
    some code into using more CPU cores, and despite making sure all the ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).
    I can't replicate this on OSX, but interestingly, if I hoist the anonymous
    function out of the for loop, and pass the channel in instead of closing
    over it, I get a >50% speedup (though only 2 cores available for me to test
    right now).
    http://play.golang.org/p/kSZAVWKYtq


    --
    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/groups/opt_out.
  • Dave Cheney at May 30, 2013 at 1:19 am
    I can replicate the problem on darwin/amd64, 10.7.5 and linux/amd64. A
    quick profile suggests cost of there is an awful lot of waiting on
    channels going on. I had a quick play but couldn't see an easy fix.
    On Thu, May 30, 2013 at 1:40 AM, James Bardin wrote:

    On Wednesday, May 29, 2013 8:53:27 AM UTC-4, darkgray wrote:

    After upgrading to Go 1.1 on my Windows 7 system, I was curious about
    performance improvements, so I went through some old Euler Project problem
    code to see if it was faster.

    Most of the time it was, but there was a peculiar case where I ugly-hacked
    some code into using more CPU cores, and despite making sure all the ints
    and uints were explicitly 32-bit, the code would run much slower (68s
    instead of the earlier 43s). Looking at the CPU graph, I noticed that while
    the 1.0.3 binary would use 100% CPU (4 cores at full capacity), the 1.1
    binary hovered around 58% (4 cores bouncing up and down).
    I can't replicate this on OSX, but interestingly, if I hoist the anonymous
    function out of the for loop, and pass the channel in instead of closing
    over it, I get a >50% speedup (though only 2 cores available for me to test
    right now).
    http://play.golang.org/p/kSZAVWKYtq


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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 29, '13 at 12:53p
activeJun 2, '13 at 6:47p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase