See https://play.golang.org/p/5x9JrD55WKc
The interfaces aer and ber look equivalent.
Both contain a function which returns nothing called m1
and a function which returns another an instance of the interface m2.
If we comment out m2, then the code will compile.
But otherwise we get an error:
./p
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
On Sun, May 23, 2021 at 10:51 AM 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"?
>
>
The safe bet in the system is to mark every possible (
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/cca23a73
The Go optimizing gc compiler and runtime are working as intended. The
results are not strange. Nothing is broken.
Peter
On Sunday, May 16, 2021 at 3:07:17 AM UTC-4 tapi...@gmail.com wrote:
> > you don't provide the Go version,
>
> My Go version is Go 1.16.3. (BTW, "go test" really should prin
I know this is an optimization. I'm just seeking why the criterion to apply
the optimization is made as the current implementation.
On Sunday, May 23, 2021 at 10:10:59 AM UTC-4 peterGo wrote:
> Here, and elsewhere (Strange benchmark results), if you not sure what is
> going on then you say that
Here, and elsewhere (Strange benchmark results), if you not sure what is
going on then you say that it must be weird, strange, an error, inaccurate,
and so on. The problem appears to be that you are not taking into account
that the Go gc and gccgo compilers are optimizing compilers.
For your ex
Here, and elsewhere (Strange benchmark results), if you not sure what is
going on then you say that it must be weird, strange, an error, inaccurate,
and so on. The problem appears to be that you are not taking into account
that the Go gc and gccgo compilers are optimizing compilers.
For your ex
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 i
>
> 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 deca
On Sunday, May 23, 2021 at 8:08:30 AM UTC-4 axel.wa...@googlemail.com wrote:
> That's not generally how it works, FWIW. Especially as far as escape
> analysis is concerned, the default is to escape and the compiler only marks
> it as non-escaping if it can prove so. So, the heuristic might not
That's not generally how it works, FWIW. Especially as far as escape
analysis is concerned, the default is to escape and the compiler only marks
it as non-escaping if it can prove so. So, the heuristic might not be
perfect, but the only "unreasonable" imperfection would be, if it would put
things o
Hi,
Today I have built GCC 11.1.0 for use to bootstrap Go using gccgo.
I installed GCC to non-standard path, that is inside my home directory
(~/.ct-ng/tools/gcc-11.1.10) (sorry for typo when building GCC, I
meant gcc-11.1.0).
`gcc -v` gave:
COLLECT_GCC=/home/bagas/.ct-ng/tools/gcc-11.1.10/bin
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 shoul
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
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,
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 =
On Sunday, May 23, 2021 at 5:22:23 AM UTC-4 Jan Mercl wrote:
> On Sun, May 23, 2021 at 11:11 AM tapi...@gmail.com
> wrote:
> >
> > It says both "make([]T, N) does not escape" and "make([]T, N) escapes to
> heap" for the slice allocated by g.
>
> What's conflicting about? You still did not
On Sunday, May 23, 2021 at 5:04:37 AM UTC-4 axel.wa...@googlemail.com wrote:
> On Sun, May 23, 2021 at 11:02 AM tapi...@gmail.com
> wrote:
>
>> And how to interpret the conflicting messages for the following program?
>>
>
> In one case, `g` is inlined, which is sufficient to prove that its ret
On Sun, May 23, 2021 at 11:11 AM tapi...@gmail.com wrote:
>
> It says both "make([]T, N) does not escape" and "make([]T, N) escapes to
> heap" for the slice allocated by g.
What's conflicting about? You still did not explain that.
I noted before that the code is different. Yes, the different co
On Sun, May 23, 2021 at 11:09 AM tapi...@gmail.com
wrote:
> It also escapes if `n` is a local variable.
>
> From the code, it looks, if the capacity of the maked slice is larger than
> 1<<12, then the slice is allocated on heap.
>
Seems possible.
Is there a possibility that, in the "make" imple
It says both "make([]T, N) does not escape" and "make([]T, N) escapes to
heap" for the slice allocated by g.
On Sunday, May 23, 2021 at 5:05:53 AM UTC-4 Jan Mercl wrote:
> On Sun, May 23, 2021 at 11:01 AM tapi...@gmail.com
> wrote:
>
> > And how to interpret the conflicting messages for the fo
It also escapes if `n` is a local variable.
>From the code, it looks, if the capacity of the maked slice is larger than
1<<12, then the slice is allocated on heap.
Is there a possibility that, in the "make" implementation, different
routines are chosen by different capacity arguments?
On Sunda
On Sun, May 23, 2021 at 11:01 AM tapi...@gmail.com wrote:
> And how to interpret the conflicting messages for the following program?
Please share what conflict and where do you see it.
I see only different escape/does not escape status for different code
but nothing conflicting.
--
You receiv
On Sun, May 23, 2021 at 11:02 AM tapi...@gmail.com
wrote:
> And how to interpret the conflicting messages for the following program?
>
In one case, `g` is inlined, which is sufficient to prove that its return
does not escape. But if you only analyse `g` as-is, you must assume that
the return has
Hi,
there is no such thing as "possibly escaping". The compiler needs to decide
whether to emit the code to reserve stack space for a variable or whether
to emit the code to allocate heap-space. That's a binary choice, it will
always do one or the other.
So, yes, `make([]T, n)` in this example al
And how to interpret the conflicting messages for the following program?
package main
type T int
const N = 1<<12
var i = N - 1
func main() {
var r = make([]T, N) // make([]T, N) does not escape
println(r[i])
var r1 = g() // make([]T, N) does not escape
println(r1[i])
}
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) //
got it.
On Sunday, May 23, 2021 at 3:50:10 AM UTC-4 cuong.m...@gmail.com wrote:
> Hi,
>
> It's normal, go1.16 and before is just incorrect for not reporting that
> escaping. See: https://go-review.googlesource.com/c/go/+/284412
>
> Cheers,
> Cuong
>
> On Sun, May 23, 2021 at 2:43 PM tapi...@gmail
Thanks for the explanation.
On Friday, May 21, 2021 at 4:16:45 PM UTC-4 Ian Lance Taylor wrote:
> On Fri, May 21, 2021 at 7:46 AM tapi...@gmail.com
> wrote:
> >
> > From the outputs of the following program,
> > it looks the stack of a goroutine doesn't shrink immediately.
> > Will it shrink at
Hi,
It's normal, go1.16 and before is just incorrect for not reporting that
escaping. See: https://go-review.googlesource.com/c/go/+/284412
Cheers,
Cuong
On Sun, May 23, 2021 at 2:43 PM tapi...@gmail.com
wrote:
> Go 1.16 doesn't make this.
> Is it nornal?
>
> package main
>
> func main(){
>
Go 1.16 doesn't make this.
Is it nornal?
package main
func main(){
panic("abc") // "abc" escapes to heap
}
--
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 g
32 matches
Mail list logo
