I will if I get enough time and become more familiar with the code. Meanwhile, I think it is a not a bad idea to post my investigations here. If some people with relevant experiences could make some explanations without spending their much time, that is the best. I thank them for clearing my confusions and saving me much time.
On Sunday, May 23, 2021 at 8:16:22 PM UTC-4 axel.wa...@googlemail.com wrote: > If you think they should, I urge you again to seek data to support that. > Check if, for a reasonable corpus of Go programs (you could start with the > stdlib and compiler) setting both to either values slows them down, speeds > them up, or leaves them the same. You'll know if it's a good idea then. > > On Sun, May 23, 2021 at 7:05 PM tapi...@gmail.com <tapi...@gmail.com> > wrote: > >> Thanks for the code link. It looks, new(LargeSizeArray) escapes for this >> line: >> >> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2016 >> >> And slices with large capacity escape for this line: >> >> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2036 >> >> ir.MaxStackVarSize = int64(10 * 1024 * 1024) >> ir.MaxImplicitStackVarSize = 16 * 1024 >> >> Maybe the two values should be equal. >> >> On Sunday, May 23, 2021 at 8:58:12 AM UTC-4 axel.wa...@googlemail.com >> wrote: >> >>> I don't try to make criticisms here. I just seek a reasonable >>>> explanation for this implementation. >>>> >>> >>> As I said, maybe there is one someone else can provide. But I doubt it. >>> I would assume the explanation is "it's a heuristic, written by humans, the >>> implementation of which evolved over a decade - so of course there will be >>> inconsistencies". >>> >>> I also don't think it's productive to demand an explanation - if the >>> current implementation has a flaw (and FTR, I agree that it would make >>> sense to treat `var x = [1<<13]int` and `var x = make([]int, 1<<13)` the >>> same in regards to escape analysis) the solution isn't to explain how it >>> came to be, but to fix it. Which is to say, to file an issue to that effect. >>> That is, after all, how the current implementation came to be in the >>> first place - we started with "everything goes on the heap" and then, >>> little by little, people found cases where it's easy to show that a >>> variable can live on the stack and implemented that analysis. >>> >>> If you just want to understand why the compiler comes to these >>> conclusions (for reasons other than because you think they're flawed) the >>> code is open source >>> <https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go>. >>> >>> I think that would be a reasonable start. >>> >>> Again, to be clear: Maybe someone who knows more about that code is able >>> and willing to provide a better explanation for why it is this way or even >>> a reason why it should be this way. In the meantime, there are other >>> avenues you can explore. >>> >>> >>>> >>>> >>>>> >>>>> As I said, maybe someone else can. Or maybe you should just try and >>>>> collect data and file an issue, if you want this to change. >>>>> >>>>> On Sun, May 23, 2021 at 12:57 PM tapi...@gmail.com <tapi...@gmail.com> >>>>> wrote: >>>>> >>>>>> I do agree escape analysis is hard and gc is clever enough to handle >>>>>> many cases. >>>>>> But at this specified case, I think it is really unreasonable, unless >>>>>> someone could provide a reasonable explanation. >>>>>> >>>>>> On Sunday, May 23, 2021 at 6:16:04 AM UTC-4 axel.wa...@googlemail.com >>>>>> wrote: >>>>>> >>>>>>> I think you should be careful using terms like "not reasonable". >>>>>>> >>>>>>> If you don't believe the existing heuristic to be good, my >>>>>>> recommendation would be to collect some data on that, showing that for >>>>>>> a >>>>>>> useful corpus of Go programs, the heuristics lead to more adverse >>>>>>> effects >>>>>>> (e.g. slower programs) than an alternative you would suggest. But it's >>>>>>> not >>>>>>> productive to just black-box poke at escape analysis using toy examples >>>>>>> and >>>>>>> derive broad judgments about the existing heuristics from that. >>>>>>> >>>>>>> On Sun, May 23, 2021 at 11:57 AM tapi...@gmail.com < >>>>>>> tapi...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, May 23, 2021 at 5:42:41 AM UTC-4 tapi...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Sunday, May 23, 2021 at 4:51:30 AM UTC-4 tapi...@gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> In the following code, "make([]T, n)" is reported as escaped. >>>>>>>>>> But does it really always escape at run time? >>>>>>>>>> Does the report just mean "make([]T, n) possibly escapes to heap"? >>>>>>>>>> >>>>>>>>>> package main >>>>>>>>>> >>>>>>>>>> type T int >>>>>>>>>> >>>>>>>>>> const K = 1<<13 >>>>>>>>>> const N = 1<<12 >>>>>>>>>> var n = N >>>>>>>>>> var i = n-1 >>>>>>>>>> >>>>>>>>>> func main() { >>>>>>>>>> var r = make([]T, N) // make([]T, N) does not escape >>>>>>>>>> println(r[i]) >>>>>>>>>> >>>>>>>>>> var r2 = make([]T, n) // make([]T, n) escapes to heap >>>>>>>>>> println(r2[i]) >>>>>>>>>> >>>>>>>>>> var r3 = make([]T, K) // make([]T, K) escapes to heap >>>>>>>>>> println(r3[i]) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>> >>>>>>>>> Another question is, why should "make([]T, K)" escape to heap? >>>>>>>>> Using the capacity as the criterion is not reasonable. >>>>>>>>> After all arrays with even larger sizes will not allocated on heap. >>>>>>>>> >>>>>>>> >>>>>>>> It looks, capacity is not only criterion. Whether or not there is a >>>>>>>> pointer referencing the allocated elements is another factor. >>>>>>>> In the following program, if K is changed to "1<<12", then no >>>>>>>> escapes. >>>>>>>> >>>>>>>> But, this is still not reasonable. >>>>>>>> >>>>>>>> package main >>>>>>>> >>>>>>>> const K = 1<<13 >>>>>>>> var i = K-1 >>>>>>>> >>>>>>>> func main() { >>>>>>>> var x = new([K]int) // new([8192]int) escapes to heap >>>>>>>> println(x[i]) >>>>>>>> >>>>>>>> var y [K]int // not escape >>>>>>>> println(y[i]) >>>>>>>> >>>>>>>> var z = [K]int{} // not escape >>>>>>>> println(z[i]) >>>>>>>> >>>>>>>> var w = &[K]int{} // &[8192]int{} escapes to heap >>>>>>>> println(w[i]) >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "golang-nuts" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/golang-nuts/571020ba-89c4-4de6-8eba-17d46b20ce42n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/571020ba-89c4-4de6-8eba-17d46b20ce42n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "golang-nuts" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to golang-nuts...@googlegroups.com. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/b78084a6-518a-4444-ab04-f0fd4c095a9an%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/b78084a6-518a-4444-ab04-f0fd4c095a9an%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/f522b85c-9116-4f18-8aac-c3a41dcacf32n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/f522b85c-9116-4f18-8aac-c3a41dcacf32n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/945468fd-0ba9-4102-bf71-e645466d08e1n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/945468fd-0ba9-4102-bf71-e645466d08e1n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6b58e4f3-a10e-4521-96e2-daa38a7bf319n%40googlegroups.com.
