Issue 14317043: code review 14317043: runtime: change default stack segment size to 8 kB (Closed)
Descriptionruntime: 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
Patch Set 1 #Patch Set 2 : diff -r 6703ffd112ea https://code.google.com/p/go/ #Patch Set 3 : diff -r c4d996668981 https://code.google.com/p/go/ #Patch Set 4 : diff -r 7aaac307aa0e https://code.google.com/p/go/ #MessagesTotal messages: 17
Hello golang-dev@googlegroups.com, I'd like you to review this change to https://code.google.com/p/go/
Sign in to reply to this message.
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.... > 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/143... > > 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@googlegrou... > . > For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o... > . >
Sign in to reply to this message.
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.
Sign in to reply to this message.
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.... > 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/143... > > 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@googlegrou... > . > For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/o... > . >
Sign in to reply to this message.
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.
Sign in to reply to this message.
*** 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
Sign in to reply to this message.
Message was sent while issue was closed.
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.
Sign in to reply to this message.
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
Sign in to reply to this message.
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
Sign in to reply to this message.
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.
Sign in to reply to this message.
> > 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
Sign in to reply to this message.
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
Sign in to reply to this message.
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
Sign in to reply to this message.
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
Sign in to reply to this message.
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
Sign in to reply to this message.
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.
Sign in to reply to this message.
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
Sign in to reply to this message.
|
