Re: [go-nuts] Go on Windows 10 ARM

On Fri, 2 July 2021, 12:36 am Federico Damián Schonborn, < fdschonb...@gmail.com> wrote: > Support for Windows ARM64 is being added in Go 1.17 (currently in beta), > see: https://tip.golang.org/doc/go1.17#windows > Thanks. > El jue, 1 de jul. de 2021 a la(s) 02:15, Amit Saha

Re: [go-nuts] Go on Windows 10 ARM

Support for Windows ARM64 is being added in Go 1.17 (currently in beta), see: https://tip.golang.org/doc/go1.17#windows El jue, 1 de jul. de 2021 a la(s) 02:15, Amit Saha (amitsaha...@gmail.com) escribió: > On Thu, Jul 1, 2021 at 12:52 PM Kurtis Rader wrote: > > > > On Wed, Jun 30, 2021 at 7:14

Re: [go-nuts] how to purge invalid tags from GOPROXY?

On Thu Jul 1, 2021 at 17:47 CET, Jay Conrod wrote: > As Dan mentioned, the version containing the retractions must be the > highest version, so you'd need to tag v1.4.3 or higher. If that version > retracts itself, it won't appear in the version list either. right. indeed, after having tagged

Re: [go-nuts] how to purge invalid tags from GOPROXY?

As Dan mentioned, the version containing the retractions must be the highest version, so you'd need to tag v1.4.3 or higher. If that version retracts itself, it won't appear in the version list either. On Thu, Jul 1, 2021 at 1:58 AM Sebastien Binet wrote: > Hi Jay, > > On Thu Jul 1, 2021 at

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] how to purge invalid tags from GOPROXY?

Hi Jay, On Thu Jul 1, 2021 at 00:45 CET, Jay Conrod wrote: > Hi Sebastien, once a version is in proxy.golang.org, it usually can't be > removed. This is important to ensure that builds continue working when a > repository disappears upstream. > > You may want to publish a new version with a

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