Re: [go-nuts] Re: Stack growing is inefficient

On Thursday, July 1, 2021 at 10:46:50 AM UTC-4 ren...@ix.netcom.com wrote: > If you are doing “anything” which such large objects - doesn’t that dwarf > the time to increase the stack? > Yes, the unreachable code in the 2nd goroutine dwarts the stack grow time much. > > On Jul 1, 2021, at

Re: [go-nuts] Re: Stack growing is inefficient

The PR: https://go-review.googlesource.com/c/go/+/332229 On Thursday, July 1, 2021 at 11:21:45 AM UTC-4 axel.wa...@googlemail.com wrote: > +Austin Clements, who introduced the check in its current form > > . > > On T

Re: [go-nuts] Re: Stack growing is inefficient

+Austin Clements, who introduced the check in its current form . On Thu, Jul 1, 2021 at 3:23 PM tapi...@gmail.com wrote: > Firstly, the current gc runtime implementation allows declare 10M arrays > on stack. > > https

Re: [go-nuts] Re: Stack growing is inefficient

On Thu, Jul 1, 2021 at 2:35 PM tapi...@gmail.com wrote: > It is not rare a function will use 10M+ stack. > FWIW, it being rare is one side of the equation. The other side is how large the overhead is - and ISTM that overhead is ~2x. That's not nothing, but it's also not extreme, for something th

Re: [go-nuts] Re: Stack growing is inefficient

If you are doing “anything” which such large objects - doesn’t that dwarf the time to increase the stack? > On Jul 1, 2021, at 9:28 AM, tapi...@gmail.com wrote: > >  > I tried to find a way to initialize the size of the stack of a new created > goroutine in advance to avoid several stack copi

Re: [go-nuts] Re: Stack growing is inefficient

I tried to find a way to initialize the size of the stack of a new created goroutine in advance to avoid several stack copies. Before this fix, the efficiencies of the two new goroutines are almost the same. After the fix, the second goroutine uses much less time than the first one. package main

Re: [go-nuts] Re: Stack growing is inefficient

Firstly, the current gc runtime implementation allows declare 10M arrays on stack. https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025 So I anticipate that some user code will make use of this threshold. Secondly, when I

Re: [go-nuts] Re: Stack growing is inefficient

On Thu, Jul 1, 2021 at 2:34 PM tapi...@gmail.com wrote: > It is not rare a function will use 10M+ stack. What's the source of this claim? If it's not rare, it should be easy to find an example in the stdlib, I guess. Do you know of one? Note that stacks of such size, if common in the wild, woul

Re: [go-nuts] Re: Stack growing is inefficient

It is not rare a function will use 10M+ stack. On Thursday, July 1, 2021 at 4:13:40 AM UTC-4 Volker Dobler wrote: > Note that the compiler should generate efficient code for > common, typical, real-world code. Optimising the compiler > to generate the most efficient code for pathological code > c

Re: [go-nuts] Re: Stack growing is inefficient

On Thu, Jul 1, 2021, 10:14 Volker Dobler wrote: > The quadratic stack growth > seems decent to me. > Nit: Depending on what we are talking about the growth is either exponential (it's doubled on every growth operation, so the size grows exponentially) or linear (the cost to grow the stack to a g

Re: [go-nuts] Re: Stack growing is inefficient

Note that the compiler should generate efficient code for common, typical, real-world code. Optimising the compiler to generate the most efficient code for pathological code can be a waste of time, both for the compiler writers and for the users waiting longer for their "normal" code to be compiled

Re: [go-nuts] Re: Stack growing is inefficient

Okay, *now* I get what you are trying to say. I agree that it seems inefficient to call it more than once, which is why the code tries to optimize for that. I don't know why that optimization doesn't trigger in your case - you might want to try and investigate that. There might be a good reason why

Re: [go-nuts] Re: Stack growing is inefficient

On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com wrote: > On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com > wrote: > >> >> >> On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: >> >>> So I think what you're asking is, "under what scenario does the

Re: [go-nuts] Re: Stack growing is inefficient

On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com wrote: > > > On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: > >> So I think what you're asking is, "under what scenario does the code in >> L1066-1069 >>

Re: [go-nuts] Re: Stack growing is inefficient

and/or link to a specific commit (press y in the github UI to get redirected to the specific commit you are looking at). On Wed, Jun 30, 2021 at 11:08 AM Brian Candler wrote: > On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: > >> >> It looks this line >> https://github.com/