Code review - Issue 14317043: code review 14317043: runtime: change default stack segment size to 8 kBhttps://codereview.appspot.com/2013-10-09T00:37:58+00:00rietveld
Message from unknown
2013-10-03T01:34:40+00:00rscurn:md5:6f171a35bac12997c78fedd909693dfc
Message from unknown
2013-10-03T01:34:45+00:00rscurn:md5:052dad40c08b3f75ab73889b3154213a
Message from unknown
2013-10-03T01:53:00+00:00rscurn:md5:67ac5fb5e001731e94b766ca1e3b586f
Message from rsc@golang.org
2013-10-03T01:53:05+00:00rscurn:md5:e90085d1ededa055166f2d3236e97fc6
Hello golang-dev@googlegroups.com,
I'd like you to review this change to
https://code.google.com/p/go/
Message from khr@google.com
2013-10-03T02:49:44+00:00khr1urn:md5:ec5841bf8e25bdc936358ada0502c859
LGTM.
On Wed, Oct 2, 2013 at 6:53 PM, <rsc@golang.org> wrote:
> Reviewers: golang-dev1,
>
> Message:
> Hello golang-dev@googlegroups.com,
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> runtime: change default stack segment size to 8 kB
>
> Changing from 4 kB to 8 kB brings significant improvement
> on a variety of the Go 1 benchmarks, on both amd64
> and 386 systems.
>
> Significant runtime reductions:
>
> amd64 386
> GoParse -14% -1%
> GobDecode -12% -20%
> GobEncode -64% -1%
> JSONDecode -9% -4%
> JSONEncode -15% -5%
> Template -17% -14%
>
> In the longer term, khr's new stacks will avoid needing to
> make this decision at all, but for Go 1.2 this is a reasonable
> stopgap that makes performance significantly better.
>
> Demand paging should mean that if the second 4 kB is not
> used, it will not be brought into memory, so the change
> should not adversely affect resident set size.
> The same argument could justify bumping as high as 64 kB
> on 64-bit machines, but there are diminishing returns
> after 8 kB, and using 8 kB limits the possible unintended
> memory overheads we are not aware of.
>
> Benchmark graphs at
> http://swtch.com/~rsc/**gostackamd64.html<http://swtch.com/~rsc/gostackamd64.html>
> http://swtch.com/~rsc/**gostack386.html<http://swtch.com/~rsc/gostack386.html>
>
> Full data at
> http://swtch.com/~rsc/gostack.**zip <http://swtch.com/~rsc/gostack.zip>
>
> Please review this at https://codereview.appspot.**com/14317043/<https://codereview.appspot.com/14317043/>
>
> Affected files (+2, -2 lines):
> M src/pkg/runtime/stack.h
>
>
> Index: src/pkg/runtime/stack.h
> ==============================**==============================**=======
> --- a/src/pkg/runtime/stack.h
> +++ b/src/pkg/runtime/stack.h
> @@ -71,12 +71,12 @@
>
> // The amount of extra stack to allocate beyond the size
> // needed for the single frame that triggered the split.
> - StackExtra = 1024,
> + StackExtra = 2048,
>
> // The minimum stack segment size to allocate.
> // If the amount needed for the splitting frame + StackExtra
> // is less than this number, the stack will have this size instead.
> - StackMin = 4096,
> + StackMin = 8192,
> FixedStack = StackMin + StackSystem,
>
> // Functions that need frames bigger than this use an extra
>
>
> --
>
> ---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<golang-dev%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
Message from dave@cheney.net
2013-10-03T03:02:20+00:00dfcurn:md5:065bccfffdfd46a048042b8636441ba2
LGTM. Thank you.
On Thu, Oct 3, 2013 at 12:49 PM, Keith Randall <khr@google.com> wrote:
> LGTM.
>
>
>
> On Wed, Oct 2, 2013 at 6:53 PM, <rsc@golang.org> wrote:
>>
>> Reviewers: golang-dev1,
>>
>> Message:
>> Hello golang-dev@googlegroups.com,
>>
>> I'd like you to review this change to
>> https://code.google.com/p/go/
>>
>>
>> Description:
>> runtime: change default stack segment size to 8 kB
>>
>> Changing from 4 kB to 8 kB brings significant improvement
>> on a variety of the Go 1 benchmarks, on both amd64
>> and 386 systems.
>>
>> Significant runtime reductions:
>>
>> amd64 386
>> GoParse -14% -1%
>> GobDecode -12% -20%
>> GobEncode -64% -1%
>> JSONDecode -9% -4%
>> JSONEncode -15% -5%
>> Template -17% -14%
>>
>> In the longer term, khr's new stacks will avoid needing to
>> make this decision at all, but for Go 1.2 this is a reasonable
>> stopgap that makes performance significantly better.
>>
>> Demand paging should mean that if the second 4 kB is not
>> used, it will not be brought into memory, so the change
>> should not adversely affect resident set size.
>> The same argument could justify bumping as high as 64 kB
>> on 64-bit machines, but there are diminishing returns
>> after 8 kB, and using 8 kB limits the possible unintended
>> memory overheads we are not aware of.
>>
>> Benchmark graphs at
>> http://swtch.com/~rsc/gostackamd64.html
>> http://swtch.com/~rsc/gostack386.html
>>
>> Full data at
>> http://swtch.com/~rsc/gostack.zip
>>
>> Please review this at https://codereview.appspot.com/14317043/
>>
>> Affected files (+2, -2 lines):
>> M src/pkg/runtime/stack.h
>>
>>
>> Index: src/pkg/runtime/stack.h
>> ===================================================================
>> --- a/src/pkg/runtime/stack.h
>> +++ b/src/pkg/runtime/stack.h
>> @@ -71,12 +71,12 @@
>>
>> // The amount of extra stack to allocate beyond the size
>> // needed for the single frame that triggered the split.
>> - StackExtra = 1024,
>> + StackExtra = 2048,
>>
>> // The minimum stack segment size to allocate.
>> // If the amount needed for the splitting frame + StackExtra
>> // is less than this number, the stack will have this size
>> instead.
>> - StackMin = 4096,
>> + StackMin = 8192,
>> FixedStack = StackMin + StackSystem,
>>
>> // Functions that need frames bigger than this use an extra
>>
>>
>> --
>>
>> ---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/groups/opt_out.
>
>
> --
>
> ---
> 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/groups/opt_out.
Message from bradfitz@golang.org
2013-10-03T04:54:34+00:00bradfitzurn:md5:41cef567d50dbf5dbb8871d7f1b1f03b
Where did this come from?
Where was the discussion / bug? CL description has no links.
Seems kinda late in the cycle for something so big.
On Oct 2, 2013 3:53 PM, <rsc@golang.org> wrote:
> Reviewers: golang-dev1,
>
> Message:
> Hello golang-dev@googlegroups.com,
>
> I'd like you to review this change to
> https://code.google.com/p/go/
>
>
> Description:
> runtime: change default stack segment size to 8 kB
>
> Changing from 4 kB to 8 kB brings significant improvement
> on a variety of the Go 1 benchmarks, on both amd64
> and 386 systems.
>
> Significant runtime reductions:
>
> amd64 386
> GoParse -14% -1%
> GobDecode -12% -20%
> GobEncode -64% -1%
> JSONDecode -9% -4%
> JSONEncode -15% -5%
> Template -17% -14%
>
> In the longer term, khr's new stacks will avoid needing to
> make this decision at all, but for Go 1.2 this is a reasonable
> stopgap that makes performance significantly better.
>
> Demand paging should mean that if the second 4 kB is not
> used, it will not be brought into memory, so the change
> should not adversely affect resident set size.
> The same argument could justify bumping as high as 64 kB
> on 64-bit machines, but there are diminishing returns
> after 8 kB, and using 8 kB limits the possible unintended
> memory overheads we are not aware of.
>
> Benchmark graphs at
> http://swtch.com/~rsc/**gostackamd64.html<http://swtch.com/~rsc/gostackamd64.html>
> http://swtch.com/~rsc/**gostack386.html<http://swtch.com/~rsc/gostack386.html>
>
> Full data at
> http://swtch.com/~rsc/gostack.**zip <http://swtch.com/~rsc/gostack.zip>
>
> Please review this at https://codereview.appspot.**com/14317043/<https://codereview.appspot.com/14317043/>
>
> Affected files (+2, -2 lines):
> M src/pkg/runtime/stack.h
>
>
> Index: src/pkg/runtime/stack.h
> ==============================**==============================**=======
> --- a/src/pkg/runtime/stack.h
> +++ b/src/pkg/runtime/stack.h
> @@ -71,12 +71,12 @@
>
> // The amount of extra stack to allocate beyond the size
> // needed for the single frame that triggered the split.
> - StackExtra = 1024,
> + StackExtra = 2048,
>
> // The minimum stack segment size to allocate.
> // If the amount needed for the splitting frame + StackExtra
> // is less than this number, the stack will have this size instead.
> - StackMin = 4096,
> + StackMin = 8192,
> FixedStack = StackMin + StackSystem,
>
> // Functions that need frames bigger than this use an extra
>
>
> --
>
> ---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<golang-dev%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>
Message from dvyukov@google.com
2013-10-03T05:49:55+00:00dvyukovurn:md5:64ad0286054714c257216fe92125db31
Agree.
I can significantly increase performance w/o increasing memory
consumption, as well as leave performance the same and increase memory
consumption (if a goroutine touches 4-8kb range and then the segment
is reused for another goroutine that does not use 4-8kb range). This
can be critical for server apps handling thousands of connections
(where goroutines are usually blocked in read loop with minimal
stack), and this is not captured in the benchmarks. I can imagine that
it can significantly slowdown programs as well, because 4+4 is not
exactly the same as 8 -- there are Stktop and corner effects during
split.
On Thu, Oct 3, 2013 at 8:54 AM, Brad Fitzpatrick <bradfitz@golang.org> wrote:
> Where did this come from?
>
> Where was the discussion / bug? CL description has no links.
>
> Seems kinda late in the cycle for something so big.
>
> On Oct 2, 2013 3:53 PM, <rsc@golang.org> wrote:
>>
>> Reviewers: golang-dev1,
>>
>> Message:
>> Hello golang-dev@googlegroups.com,
>>
>> I'd like you to review this change to
>> https://code.google.com/p/go/
>>
>>
>> Description:
>> runtime: change default stack segment size to 8 kB
>>
>> Changing from 4 kB to 8 kB brings significant improvement
>> on a variety of the Go 1 benchmarks, on both amd64
>> and 386 systems.
>>
>> Significant runtime reductions:
>>
>> amd64 386
>> GoParse -14% -1%
>> GobDecode -12% -20%
>> GobEncode -64% -1%
>> JSONDecode -9% -4%
>> JSONEncode -15% -5%
>> Template -17% -14%
>>
>> In the longer term, khr's new stacks will avoid needing to
>> make this decision at all, but for Go 1.2 this is a reasonable
>> stopgap that makes performance significantly better.
>>
>> Demand paging should mean that if the second 4 kB is not
>> used, it will not be brought into memory, so the change
>> should not adversely affect resident set size.
>> The same argument could justify bumping as high as 64 kB
>> on 64-bit machines, but there are diminishing returns
>> after 8 kB, and using 8 kB limits the possible unintended
>> memory overheads we are not aware of.
>>
>> Benchmark graphs at
>> http://swtch.com/~rsc/gostackamd64.html
>> http://swtch.com/~rsc/gostack386.html
>>
>> Full data at
>> http://swtch.com/~rsc/gostack.zip
>>
>> Please review this at https://codereview.appspot.com/14317043/
>>
>> Affected files (+2, -2 lines):
>> M src/pkg/runtime/stack.h
>>
>>
>> Index: src/pkg/runtime/stack.h
>> ===================================================================
>> --- a/src/pkg/runtime/stack.h
>> +++ b/src/pkg/runtime/stack.h
>> @@ -71,12 +71,12 @@
>>
>> // The amount of extra stack to allocate beyond the size
>> // needed for the single frame that triggered the split.
>> - StackExtra = 1024,
>> + StackExtra = 2048,
>>
>> // The minimum stack segment size to allocate.
>> // If the amount needed for the splitting frame + StackExtra
>> // is less than this number, the stack will have this size
>> instead.
>> - StackMin = 4096,
>> + StackMin = 8192,
>> FixedStack = StackMin + StackSystem,
>>
>> // Functions that need frames bigger than this use an extra
>>
>>
>> --
>>
>> ---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/groups/opt_out.
>
> --
>
> ---
> 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/groups/opt_out.
Message from unknown
2013-10-03T13:19:04+00:00rscurn:md5:847819456b4ddf09685ef324d05747fd
Message from rsc@golang.org
2013-10-03T13:19:19+00:00rscurn:md5:50d1c133e5c3d99c9c7b3ee1862d1082
*** Submitted as https://code.google.com/p/go/source/detail?r=b4a7054c3243 ***
runtime: change default stack segment size to 8 kB
Changing from 4 kB to 8 kB brings significant improvement
on a variety of the Go 1 benchmarks, on both amd64
and 386 systems.
Significant runtime reductions:
amd64 386
GoParse -14% -1%
GobDecode -12% -20%
GobEncode -64% -1%
JSONDecode -9% -4%
JSONEncode -15% -5%
Template -17% -14%
In the longer term, khr's new stacks will avoid needing to
make this decision at all, but for Go 1.2 this is a reasonable
stopgap that makes performance significantly better.
Demand paging should mean that if the second 4 kB is not
used, it will not be brought into memory, so the change
should not adversely affect resident set size.
The same argument could justify bumping as high as 64 kB
on 64-bit machines, but there are diminishing returns
after 8 kB, and using 8 kB limits the possible unintended
memory overheads we are not aware of.
Benchmark graphs at
http://swtch.com/~rsc/gostackamd64.html
http://swtch.com/~rsc/gostack386.html
Full data at
http://swtch.com/~rsc/gostack.zip
R=golang-dev, khr, dave, bradfitz, dvyukov
CC=golang-dev
https://codereview.appspot.com/14317043
Message from ugorji@gmail.com
2013-10-03T13:52:51+00:00ugorjiurn:md5:0dae6b1213d9b496e6e0b965930da126
Thank you.
I'm pleasantly surprised that this was done. I'm very happy it was done.
I maintain the encoder/decoder for msgpack and Binc formats at
https://github.com/ugorji/go (package: github.com/ugorji/go/codec)
and innocuous changes kept tripping up the stack splitting machinery causing
large variances in performance.
To validate my changes, I made similar changes to my local Go install
(StackExtra = 8 * 1024, StackMin = 8 * 4096), and was writing a blog post
about necessity of making such changes when benchmarking recursive algorithms,
especially if some of them have long methods (with associated large stack frames).
Without my local changes to stack.h, performance numbers were 2X worse.
With these changes in this CL, the numbers are now in-line with when I had the
8X multiplier for StackExtra and StackMin.
Although I am surprised this went in so late, I'm glad it did.
P.S. I had raised this concern before at
https://groups.google.com/d/topic/golang-dev/6Vs1sxmSSb0/discussion
but have been patiently waiting on khr's contiguous stacks hoping it resolves the issue.
I appreciate this stop gap.
Message from rsc@golang.org
2013-10-03T14:00:56+00:00rscurn:md5:17995e7a7bad906809bc975ead9f5b99
On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote:
> Where did this come from?
>
> Where was the discussion / bug? CL description has no links.
>
> Seems kinda late in the cycle for something so big.
>
This is the reason JSONDecode was 10% slower than in Go 1.1. This is what
I've been spending the last week on. I didn't file a separate bug for it.
64 kB stacks would have been something big. 8 kB is not.
Russ
Message from rsc@golang.org
2013-10-03T14:02:28+00:00rscurn:md5:32e531a8ba7f4141a50bae9d34f73d83
On Thu, Oct 3, 2013 at 1:49 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> Agree.
> I can significantly increase performance w/o increasing memory
> consumption, as well as leave performance the same and increase memory
> consumption (if a goroutine touches 4-8kb range and then the segment
> is reused for another goroutine that does not use 4-8kb range). This
> can be critical for server apps handling thousands of connections
> (where goroutines are usually blocked in read loop with minimal
> stack), and this is not captured in the benchmarks. I can imagine that
> it can significantly slowdown programs as well, because 4+4 is not
> exactly the same as 8 -- there are Stktop and corner effects during
> split.
>
We still have two months before the release. This will be in the next
release candidate, and if someone does find problems, it is trivial to
revert before the official release.
The benchmarks are quite compelling that for a variety of use cases 4 kB is
simply too small. Did you look at them?
Russ
Message from dvyukov@google.com
2013-10-03T14:14:51+00:00dvyukovurn:md5:e4d26b4b151fa16a19031c969e71e4db
On Thu, Oct 3, 2013 at 6:02 PM, Russ Cox <rsc@golang.org> wrote:
> On Thu, Oct 3, 2013 at 1:49 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>>
>> Agree.
>> I can significantly increase performance w/o increasing memory
>> consumption, as well as leave performance the same and increase memory
>> consumption (if a goroutine touches 4-8kb range and then the segment
>> is reused for another goroutine that does not use 4-8kb range). This
>> can be critical for server apps handling thousands of connections
>> (where goroutines are usually blocked in read loop with minimal
>> stack), and this is not captured in the benchmarks. I can imagine that
>> it can significantly slowdown programs as well, because 4+4 is not
>> exactly the same as 8 -- there are Stktop and corner effects during
>> split.
>
>
> We still have two months before the release. This will be in the next
> release candidate, and if someone does find problems, it is trivial to
> revert before the official release.
>
> The benchmarks are quite compelling that for a variety of use cases 4 kB is
> simply too small. Did you look at them?
I looked at them.
Any X is too small for a variety of use cases. Just add some frames
(server handler code) below JSON parsing frames, and you get JSON
benchmark for which 8kb is too small.
There are no benchmarks that measure memory consumption for server apps.
Message from rsc@golang.org
2013-10-03T14:53:44+00:00rscurn:md5:55c14f02c57e513e35ea8ed7dc4497a6
>
> I looked at them.
> Any X is too small for a variety of use cases. Just add some frames
> (server handler code) below JSON parsing frames, and you get JSON
> benchmark for which 8kb is too small.
> There are no benchmarks that measure memory consumption for server apps.
>
Your argument boils down to "we can't change anything because it might make
some case worse". It is true that changes might make some things better and
some things worse. That is an unfortunate fact of the current design, one
that I really hope will be eliminated in Go 1.3. However, fear of making
some unknown thing worse should not stop us from making known things
better. Also, it is not just JSON that got better. Four unrelated
benchmarks - Go parsing, JSON, Gob, and Template - all got significantly
better, and none of the benchmarks got significantly worse. That suggests
there is a real problem with the stack size and that we are not just
overfitting to one use case.
There is nothing special about the old 4k value. It is just a number I made
up a long time ago. It replaced a number Ken made up even longer ago. Both
were just guesses based on gut feeling. The change I made yesterday was not
a guess. It was based on days spent making actual measurements using the Go
1 benchmark suite. In fact, I was trying to gather data that 64k would be
okay, and it probably would, but the evidence doesn't support that. It
strongly supports the more limited step to 8k. So I did what the evidence
supported instead of making another guess. That is, for the first time,
there is actually evidence behind the choice stack size. I see this as a
significant step forward.
If you can gather evidence that 4k is better than 8k in some important
class of application, then we can reevaluate. But a discussion needs to be
based on evidence, not hypotheticals.
The Go 1 benchmark suite (in test/bench/go1) is what we use to make these
decisions. If you or anyone else believe it is incomplete, additions are
welcome.
Russ
Message from mtj@google.com
2013-10-03T15:18:19+00:00mtj1urn:md5:8134b88a0090641ea190e5380ef21cbe
My finely-optimized exact cover solver is an example code unlike many of
the Go benchmarks in being all CPU/no IO, carefully tuned, unrolled, etc.
Here's the before and after result from a test run that counts (not yet
published) generalized Langford/Skolem sequences.
OLD
# Gap(12, 2): 55696 solutions 818550 nodes
11935776 updates 0.123 s 97.261 Mu/s
# Gap(12, 1): 108144 solutions 1351543 nodes
19494378 updates 0.198 s 98.314 Mu/s
# Gap(12, 0): 227968 solutions 2137237 nodes
31496482 updates 0.312 s 100.873 Mu/s
# Gap(13, 6): 17800 solutions 276931 nodes
4032013 updates 0.037 s
# Gap(13, 4): 129220 solutions 2406091 nodes
34510000 updates 0.328 s 105.111 Mu/s
# Gap(13, 2): 360876 solutions 5586798 nodes
81469260 updates 0.827 s 98.512 Mu/s
# Gap(13, 0): 1520280 solutions 14940920 nodes
219953588 updates 2.056 s 106.981 Mu/s
# Gap(15, 7): 329816 solutions 6433598 nodes
94719176 updates 1.018 s 93.006 Mu/s
# Gap(15, 5): 3912272 solutions 82944237 nodes
1180126632 updates 12.076 s 97.723 Mu/s
# Gap(15, 3): 10346528 solutions 197704780 nodes
2866894951 updates 28.448 s 100.778 Mu/s
# Gap(15, 1): 39809640 solutions 550148348 nodes
7965822480 updates 76.456 s 104.188 Mu/s
# Gap(16, 7): 5097864 solutions 101351300 nodes
1410017217 updates 13.879 s 101.596 Mu/s
# Gap(16, 6): 17367424 solutions 375304505 nodes
5250867254 updates 52.152 s 100.684 Mu/s
# Gap(16, 5): 30346968 solutions 685284939 nodes
9843205022 updates 92.410 s 106.517 Mu/s
# Gap(16, 4): 47829512 solutions 1040552779 nodes
15116720046 updates 148.622 s 101.713 Mu/s
NEW
# Gap(12, 2): 55696 solutions 818550 nodes
11935776 updates 0.110 s 108.205 Mu/s
# Gap(12, 1): 108144 solutions 1351543 nodes
19494378 updates 0.170 s 114.683 Mu/s
# Gap(12, 0): 227968 solutions 2137237 nodes
31496482 updates 0.276 s 114.010 Mu/s
# Gap(13, 6): 17800 solutions 276931 nodes
4032013 updates 0.037 s
# Gap(13, 4): 129220 solutions 2406091 nodes
34510000 updates 0.310 s 111.197 Mu/s
# Gap(13, 2): 360876 solutions 5586798 nodes
81469260 updates 0.725 s 112.378 Mu/s
# Gap(13, 0): 1520280 solutions 14940920 nodes
219953588 updates 1.864 s 118.002 Mu/s
# Gap(15, 7): 329816 solutions 6433598 nodes
94719176 updates 0.885 s 107.027 Mu/s
# Gap(15, 5): 3912272 solutions 82944237 nodes
1180126632 updates 10.996 s 107.326 Mu/s
# Gap(15, 3): 10346528 solutions 197704780 nodes
2866894951 updates 25.947 s 110.491 Mu/s
# Gap(15, 1): 39809640 solutions 550148348 nodes
7965822480 updates 74.196 s 107.363 Mu/s
# Gap(16, 7): 5097864 solutions 101351300 nodes
1410017217 updates 13.438 s 104.931 Mu/s
# Gap(16, 6): 17367424 solutions 375304505 nodes
5250867254 updates 48.374 s 108.547 Mu/s
# Gap(16, 5): 30346968 solutions 685284939 nodes
9843205022 updates 90.294 s 109.013 Mu/s
# Gap(16, 4): 47829512 solutions 1040552779 nodes
15116720046 updates 140.146 s 107.864 Mu/s
CHANGE
OLD S NEW S DELTA %
Gap(12,2) 0.123 0.110 -10.57%
Gap(12,1) 0.198 0.170 -14.14%
Gap(12,0) 0.312 0.276 -11.54%
Gap(13,6) 0.037 0.037 0.00%
Gap(13,4) 0.328 0.310 -5.49%
Gap(13,2) 0.827 0.725 -12.33%
Gap(13,0) 2.056 1.864 -9.34%
Gap(15,7) 1.018 0.885 -13.06%
Gap(15,5) 12.076 10.996 -8.94%
Gap(15,3) 28.448 25.947 -8.79%
Gap(15,1) 76.456 74.196 -2.96%
Gap(16,7) 13.879 13.438 -3.18%
Gap(16,6) 52.152 48.374 -7.24%
Gap(16,5) 92.410 90.294 -2.29%
Gap(16,4) 148.622 140.146 -5.70%
Nice!
Saving 8% means that a 6 month (182.5 day) run will shrink by two weeks
(14.6 days).
On Thu, Oct 3, 2013 at 7:53 AM, Russ Cox <rsc@golang.org> wrote:
> I looked at them.
>> Any X is too small for a variety of use cases. Just add some frames
>> (server handler code) below JSON parsing frames, and you get JSON
>> benchmark for which 8kb is too small.
>> There are no benchmarks that measure memory consumption for server apps.
>>
>
> Your argument boils down to "we can't change anything because it might
> make some case worse". It is true that changes might make some things
> better and some things worse. That is an unfortunate fact of the current
> design, one that I really hope will be eliminated in Go 1.3. However, fear
> of making some unknown thing worse should not stop us from making known
> things better. Also, it is not just JSON that got better. Four unrelated
> benchmarks - Go parsing, JSON, Gob, and Template - all got significantly
> better, and none of the benchmarks got significantly worse. That suggests
> there is a real problem with the stack size and that we are not just
> overfitting to one use case.
>
> There is nothing special about the old 4k value. It is just a number I
> made up a long time ago. It replaced a number Ken made up even longer ago.
> Both were just guesses based on gut feeling. The change I made yesterday
> was not a guess. It was based on days spent making actual measurements
> using the Go 1 benchmark suite. In fact, I was trying to gather data that
> 64k would be okay, and it probably would, but the evidence doesn't support
> that. It strongly supports the more limited step to 8k. So I did what the
> evidence supported instead of making another guess. That is, for the first
> time, there is actually evidence behind the choice stack size. I see this
> as a significant step forward.
>
> If you can gather evidence that 4k is better than 8k in some important
> class of application, then we can reevaluate. But a discussion needs to be
> based on evidence, not hypotheticals.
>
> The Go 1 benchmark suite (in test/bench/go1) is what we use to make these
> decisions. If you or anyone else believe it is incomplete, additions are
> welcome.
>
> 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/groups/opt_out.
>
--
Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
650-335-5765
Message from bradfitz@golang.org
2013-10-03T17:04:15+00:00bradfitzurn:md5:8cda0fe4b3edfc8de5ff98e23c33ec80
On Oct 3, 2013 4:00 AM, "Russ Cox" <rsc@golang.org> wrote:
>
> On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <bradfitz@golang.org>
wrote:
>>
>> Where did this come from?
>>
>> Where was the discussion / bug? CL description has no links.
>>
>> Seems kinda late in the cycle for something so big.
>
> This is the reason JSONDecode was 10% slower than in Go 1.1.
Did stack frames get bigger? At which CLs? Just curious.
> This is what I've been spending the last week on. I didn't file a
separate bug for it.
>
> 64 kB stacks would have been something big. 8 kB is not.
>
> Russ
Message from rsc@golang.org
2013-10-03T17:28:38+00:00rscurn:md5:840f24052168addd1ff2162178188fda
On Thu, Oct 3, 2013 at 1:04 PM, Brad Fitzpatrick <bradfitz@golang.org>wrote:
>
> On Oct 3, 2013 4:00 AM, "Russ Cox" <rsc@golang.org> wrote:
> >
> > On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <bradfitz@golang.org>
> wrote:
> >>
> >> Where did this come from?
> >>
> >> Where was the discussion / bug? CL description has no links.
> >>
> >> Seems kinda late in the cycle for something so big.
> >
> > This is the reason JSONDecode was 10% slower than in Go 1.1.
>
> Did stack frames get bigger? At which CLs? Just curious.
>
The biggest performance dip was due to CL 12829043, which made stack frames
smaller.
Russ
Message from mtj@google.com
2013-10-09T00:21:17+00:00mtj1urn:md5:6b2c0ce017901fdf2c3b90a9e7a2194e
Additional 3.45% faster today...8.2% faster over the last two weeks!
# Gap(12, 2): 55696 solutions 818550 nodes
11935776 updates 0.108 s 110.173 Mu/s
# Gap(12, 1): 108144 solutions 1351543 nodes
19494378 updates 0.168 s 115.913 Mu/s
# Gap(12, 0): 227968 solutions 2137237 nodes
31496482 updates 0.261 s 120.868 Mu/s
# Gap(13, 6): 17800 solutions 276931 nodes
4032013 updates 0.037 s
# Gap(13, 4): 129220 solutions 2406091 nodes
34510000 updates 0.302 s 114.125 Mu/s
# Gap(13, 2): 360876 solutions 5586798 nodes
81469260 updates 0.710 s 114.785 Mu/s
# Gap(13, 0): 1520280 solutions 14940920 nodes
219953588 updates 1.933 s 113.760 Mu/s
# Gap(15, 7): 329816 solutions 6433598 nodes
94719176 updates 0.867 s 109.256 Mu/s
# Gap(15, 5): 3912272 solutions 82944237 nodes
1180126632 updates 10.502 s 112.377 Mu/s
# Gap(15, 3): 10346528 solutions 197704780 nodes
2866894951 updates 25.618 s 111.909 Mu/s
# Gap(15, 1): 39809640 solutions 550148348 nodes
7965822480 updates 71.657 s 111.165 Mu/s
# Gap(16, 7): 5097864 solutions 101351300 nodes
1410017217 updates 12.974 s 108.677 Mu/s
# Gap(16, 6): 17367424 solutions 375304505 nodes
5250867254 updates 47.744 s 109.981 Mu/s
# Gap(16, 5): 30346968 solutions 685284939 nodes
9843205022 updates 88.756 s 110.902 Mu/s
On Thu, Oct 3, 2013 at 10:28 AM, Russ Cox <rsc@golang.org> wrote:
> On Thu, Oct 3, 2013 at 1:04 PM, Brad Fitzpatrick <bradfitz@golang.org>wrote:
>
>>
>> On Oct 3, 2013 4:00 AM, "Russ Cox" <rsc@golang.org> wrote:
>> >
>> > On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <bradfitz@golang.org>
>> wrote:
>> >>
>> >> Where did this come from?
>> >>
>> >> Where was the discussion / bug? CL description has no links.
>> >>
>> >> Seems kinda late in the cycle for something so big.
>> >
>> > This is the reason JSONDecode was 10% slower than in Go 1.1.
>>
>> Did stack frames get bigger? At which CLs? Just curious.
>>
> The biggest performance dip was due to CL 12829043, which made stack
> frames smaller.
>
> 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/groups/opt_out.
>
--
Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
650-335-5765
Message from dave@cheney.net
2013-10-09T00:31:19+00:00dfcurn:md5:4828033bb8747e52f3f7c6267d988c2d
Michael,
What do you attribute this 3.45% improvement to ? I can't see any
changes the last few days that actually change code, just docs and
examples.
On Wed, Oct 9, 2013 at 11:20 AM, Michael Jones <mtj@google.com> wrote:
> Additional 3.45% faster today...8.2% faster over the last two weeks!
>
> # Gap(12, 2): 55696 solutions 818550 nodes
> 11935776 updates 0.108 s 110.173 Mu/s
> # Gap(12, 1): 108144 solutions 1351543 nodes
> 19494378 updates 0.168 s 115.913 Mu/s
> # Gap(12, 0): 227968 solutions 2137237 nodes
> 31496482 updates 0.261 s 120.868 Mu/s
> # Gap(13, 6): 17800 solutions 276931 nodes
> 4032013 updates 0.037 s
> # Gap(13, 4): 129220 solutions 2406091 nodes
> 34510000 updates 0.302 s 114.125 Mu/s
> # Gap(13, 2): 360876 solutions 5586798 nodes
> 81469260 updates 0.710 s 114.785 Mu/s
> # Gap(13, 0): 1520280 solutions 14940920 nodes
> 219953588 updates 1.933 s 113.760 Mu/s
> # Gap(15, 7): 329816 solutions 6433598 nodes
> 94719176 updates 0.867 s 109.256 Mu/s
> # Gap(15, 5): 3912272 solutions 82944237 nodes
> 1180126632 updates 10.502 s 112.377 Mu/s
> # Gap(15, 3): 10346528 solutions 197704780 nodes
> 2866894951 updates 25.618 s 111.909 Mu/s
> # Gap(15, 1): 39809640 solutions 550148348 nodes
> 7965822480 updates 71.657 s 111.165 Mu/s
> # Gap(16, 7): 5097864 solutions 101351300 nodes
> 1410017217 updates 12.974 s 108.677 Mu/s
> # Gap(16, 6): 17367424 solutions 375304505 nodes
> 5250867254 updates 47.744 s 109.981 Mu/s
> # Gap(16, 5): 30346968 solutions 685284939 nodes
> 9843205022 updates 88.756 s 110.902 Mu/s
>
>
> On Thu, Oct 3, 2013 at 10:28 AM, Russ Cox <rsc@golang.org> wrote:
>>
>> On Thu, Oct 3, 2013 at 1:04 PM, Brad Fitzpatrick <bradfitz@golang.org>
>> wrote:
>>>
>>>
>>> On Oct 3, 2013 4:00 AM, "Russ Cox" <rsc@golang.org> wrote:
>>> >
>>> > On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <bradfitz@golang.org>
>>> > wrote:
>>> >>
>>> >> Where did this come from?
>>> >>
>>> >> Where was the discussion / bug? CL description has no links.
>>> >>
>>> >> Seems kinda late in the cycle for something so big.
>>> >
>>> > This is the reason JSONDecode was 10% slower than in Go 1.1.
>>>
>>> Did stack frames get bigger? At which CLs? Just curious.
>>
>> The biggest performance dip was due to CL 12829043, which made stack
>> frames smaller.
>>
>> 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/groups/opt_out.
>
>
>
>
> --
> Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
> 650-335-5765
>
> --
>
> ---
> 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/groups/opt_out.
Message from mtj@google.com
2013-10-09T00:37:58+00:00mtj1urn:md5:468217a9da11261c2c3df5bef316d23b
sorry. I don't see anything special either.
On Tue, Oct 8, 2013 at 5:31 PM, Dave Cheney <dave@cheney.net> wrote:
> Michael,
>
> What do you attribute this 3.45% improvement to ? I can't see any
> changes the last few days that actually change code, just docs and
> examples.
>
> On Wed, Oct 9, 2013 at 11:20 AM, Michael Jones <mtj@google.com> wrote:
> > Additional 3.45% faster today...8.2% faster over the last two weeks!
> >
> > # Gap(12, 2): 55696 solutions 818550 nodes
> > 11935776 updates 0.108 s 110.173 Mu/s
> > # Gap(12, 1): 108144 solutions 1351543 nodes
> > 19494378 updates 0.168 s 115.913 Mu/s
> > # Gap(12, 0): 227968 solutions 2137237 nodes
> > 31496482 updates 0.261 s 120.868 Mu/s
> > # Gap(13, 6): 17800 solutions 276931 nodes
> > 4032013 updates 0.037 s
> > # Gap(13, 4): 129220 solutions 2406091 nodes
> > 34510000 updates 0.302 s 114.125 Mu/s
> > # Gap(13, 2): 360876 solutions 5586798 nodes
> > 81469260 updates 0.710 s 114.785 Mu/s
> > # Gap(13, 0): 1520280 solutions 14940920 nodes
> > 219953588 updates 1.933 s 113.760 Mu/s
> > # Gap(15, 7): 329816 solutions 6433598 nodes
> > 94719176 updates 0.867 s 109.256 Mu/s
> > # Gap(15, 5): 3912272 solutions 82944237 nodes
> > 1180126632 updates 10.502 s 112.377 Mu/s
> > # Gap(15, 3): 10346528 solutions 197704780 nodes
> > 2866894951 updates 25.618 s 111.909 Mu/s
> > # Gap(15, 1): 39809640 solutions 550148348 nodes
> > 7965822480 updates 71.657 s 111.165 Mu/s
> > # Gap(16, 7): 5097864 solutions 101351300 nodes
> > 1410017217 updates 12.974 s 108.677 Mu/s
> > # Gap(16, 6): 17367424 solutions 375304505 nodes
> > 5250867254 updates 47.744 s 109.981 Mu/s
> > # Gap(16, 5): 30346968 solutions 685284939 nodes
> > 9843205022 updates 88.756 s 110.902 Mu/s
> >
> >
> > On Thu, Oct 3, 2013 at 10:28 AM, Russ Cox <rsc@golang.org> wrote:
> >>
> >> On Thu, Oct 3, 2013 at 1:04 PM, Brad Fitzpatrick <bradfitz@golang.org>
> >> wrote:
> >>>
> >>>
> >>> On Oct 3, 2013 4:00 AM, "Russ Cox" <rsc@golang.org> wrote:
> >>> >
> >>> > On Thu, Oct 3, 2013 at 12:54 AM, Brad Fitzpatrick <
> bradfitz@golang.org>
> >>> > wrote:
> >>> >>
> >>> >> Where did this come from?
> >>> >>
> >>> >> Where was the discussion / bug? CL description has no links.
> >>> >>
> >>> >> Seems kinda late in the cycle for something so big.
> >>> >
> >>> > This is the reason JSONDecode was 10% slower than in Go 1.1.
> >>>
> >>> Did stack frames get bigger? At which CLs? Just curious.
> >>
> >> The biggest performance dip was due to CL 12829043, which made stack
> >> frames smaller.
> >>
> >> 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/groups/opt_out.
> >
> >
> >
> >
> > --
> > Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
> > 650-335-5765
> >
> > --
> >
> > ---
> > 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/groups/opt_out.
>
--
Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
650-335-5765