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

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. > >

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

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

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

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

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,

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 >

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

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

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

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 >>

[go-nuts] Re: Stack growing is inefficient

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 > > > get run?" - is

[go-nuts] Re: Stack growing is inefficient

So I think what you're asking is, "under what scenario does the code in L1066-1069 get run?" - is that right? On Wednesday, 30 June 2021 at 14:21:21 UTC+1 tapi...@gmail.com wrote: >

[go-nuts] Re: Stack growing is inefficient

Sorry, I post the wrong anchor. It is line 1068: https://github.com/golang/go/blob/d19a53338fa6272b4fe9c39d66812a79e1464cd2/src/runtime/stack.go#L1068 On Wednesday, June 30, 2021 at 5:08:30 AM UTC-4 Brian Candler wrote: > On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: >

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 >>

[go-nuts] Re: Stack growing is inefficient

On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wrote: > > It looks this line > https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never > gets executed. > > Can you quote the line you're referring to? Line numbers can shift up and down as commits are made to

[go-nuts] Re: Stack growing is inefficient

It looks all stacks start from 2048 bytes, even if gc has estimated the start function of a goroutine will use much larger stack. Why not initialize the stack with a large size as needed? For example: package main const N = 300 * 1024 * 1024 var v byte = 123 func f(c chan struct{}) { var