The following is a tip to get an array pointer but avoid the array escaping.
package main
const N = 1<<13
var i = N-1
func main() {
var x = &[N]int{} // escapes to heap
println(x[i])
var t [N]int // not escape
var y = &t
println(y[i])
}
On Monday, May 24, 2021 at 4:25:18 AM UTC-4 tapi...@gmail.com wrote:
> 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/3bc77028-0f24-4f5b-975c-f781bfc23f93n%40googlegroups.com.
