[go-nuts] Re: godoc-static - Generate static documentation for your packages

[tapi...@gmail.com]

Cool.

BTW, there is another docs generator: https://github.com/go101/gold 
(written by me).

On Thursday, February 6, 2020 at 7:56:15 PM UTC-5 Trevor Slocum wrote:

> Repository: https://gitlab.com/tslocum/godoc-static
>
> Demo output: https://docs.rocketnine.space
>
> Inspired by the recent news of godoc.org shutting down I have created 
> godoc-static.  While we could all migrate to pkg.go.dev, we could also 
> host and update our documentation ourselves. 
>
> When invoked, "godoc -http=localhost:" is started, relevant package 
> documentation pages and source code is scraped and rewritten to fix 
> styling, expanding content, etc., then godoc is terminated. 
>
> Note that while things seem to work, I have only focused on shipping the 
> MVP so far.  Here be dragons.  For instance, to get this to work on my VPS 
> I had to set  GO111MODULE to off and clone relevant package sources to 
> GOPATH.
>

-- 
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/fe350dfa-296f-4430-a19b-d82afa2629f0n%40googlegroups.com.

[go-nuts] Re: add method to interface via reflect

[tapi...@gmail.com]

What should happen after the method is added?
Will those types implementing the interface still implement it?

On Thursday, September 10, 2020 at 6:44:29 PM UTC-4 va...@selfip.ru wrote:

> Hi! Does go support adding method to exiting interface via reflect?
> Mostly I need to add method to struct pointer.
>
> -- 
> Vasiliy Tolstov,
> e-mail: v.to...@selfip.ru
>

-- 
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/a6dbd320-800c-4423-8899-d1fa74f921bcn%40googlegroups.com.

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

[tapi...@gmail.com]

Is it good to introduce owner transfer based string<->[]byte conversions?
After the conversion, the being converted string/[]byte values mustn't be 
used any more.
Such as

tlsCertData, _ = ioutil.ReadFile("/etc/ssl/mycert") 
var tlsCert string = bultin.ByteSlice2String(tlsCertData)

// forbid using tlsCertData any more
_ = tlsCertData // error: tlsCertData can only used after a re-assignment.

On Friday, September 11, 2020 at 3:09:57 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Sep 11, 2020 at 9:45 AM Kevin Chadwick  wrote:
> >
> > I apologise if this has already been discussed. Google didn't turn up 
> anything
> > directly related.
> >
> > If you read a file using the following that returns a byte slice.
> >
> > tlsCertb, err := ioutil.ReadFile("/etc/ssl/mycert")
> > if err != nil {
> > log.Fatal(err)
> > }
> > tlsCert = string(tlsCertb)
> >
> > Is there a way to get a string without the cast.
> >
> > Otherwise couldn't the language automatically return a string rather 
> than a byte
> > slice in these cases if the receiving var is already a string?
> >
> > e.g.
> >
> > var string tlsCert
> > tlsCert, err = ioutil.ReadFile("/etc/ssl/mycert")
> > if err != nil {
> > log.Fatal(err)
> > }
>
> The way Go works, ioutil.ReadFile is compiled with the io/ioutil
> package. It can't change based on how it is called. So it is always
> going to return []byte.
>
> The only way to implement what you suggest would be to add an implicit
> conversion from []byte to string. But that seems problematic. In
> general Go avoids implicit conversions except to interface types. And
> a conversion to string does require a copy, so it doesn't seem like a
> great idea to do that implicitly.
>
> If this happens a lot in your code, it seems easy enough to use a tiny
> helper function.
>
> Ian
>

-- 
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/841399fc-0c3c-4ce3-90a6-8154a1ff4392n%40googlegroups.com.

Re: [go-nuts] Proposal: auto return String instead of []byte if requested

[tapi...@gmail.com]

There is a prerequisite to transfer ownership: it must be proved that
no other values share ownership of the byte slice returned by 
ioutil.ReadFile.

On Saturday, September 12, 2020 at 3:42:14 AM UTC-4 tapi...@gmail.com wrote:

> Is it good to introduce owner transfer based string<->[]byte conversions?
> After the conversion, the being converted string/[]byte values mustn't be 
> used any more.
> Such as
>
> tlsCertData, _ = ioutil.ReadFile("/etc/ssl/mycert") 
> var tlsCert string = bultin.ByteSlice2String(tlsCertData)
>
> // forbid using tlsCertData any more
> _ = tlsCertData // error: tlsCertData can only used after a re-assignment.
>
> On Friday, September 11, 2020 at 3:09:57 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Fri, Sep 11, 2020 at 9:45 AM Kevin Chadwick  wrote:
>> >
>> > I apologise if this has already been discussed. Google didn't turn up 
>> anything
>> > directly related.
>> >
>> > If you read a file using the following that returns a byte slice.
>> >
>> > tlsCertb, err := ioutil.ReadFile("/etc/ssl/mycert")
>> > if err != nil {
>> > log.Fatal(err)
>> > }
>> > tlsCert = string(tlsCertb)
>> >
>> > Is there a way to get a string without the cast.
>> >
>> > Otherwise couldn't the language automatically return a string rather 
>> than a byte
>> > slice in these cases if the receiving var is already a string?
>> >
>> > e.g.
>> >
>> > var string tlsCert
>> > tlsCert, err = ioutil.ReadFile("/etc/ssl/mycert")
>> > if err != nil {
>> > log.Fatal(err)
>> > }
>>
>> The way Go works, ioutil.ReadFile is compiled with the io/ioutil
>> package. It can't change based on how it is called. So it is always
>> going to return []byte.
>>
>> The only way to implement what you suggest would be to add an implicit
>> conversion from []byte to string. But that seems problematic. In
>> general Go avoids implicit conversions except to interface types. And
>> a conversion to string does require a copy, so it doesn't seem like a
>> great idea to do that implicitly.
>>
>> If this happens a lot in your code, it seems easy enough to use a tiny
>> helper function.
>>
>> Ian
>>
>

-- 
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/af63dbc8-188a-46f6-aa7c-e2c44d17cf37n%40googlegroups.com.

[go-nuts] Should the program print true or false?

[tapi...@gmail.com]

package main

import (
  "fmt"
  "reflect"
)

func main() {
  f()
}

func f() {
  type S []S
  var a, b S
  a = S{0: b}
  b = S{0: a}
  fmt.Println(reflect.DeepEqual(a, b))
}

Now it prints false. But it looks the docs indicates it should print true.

-- 
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/dbe73874-ec0f-413d-bed6-47f213bede91n%40googlegroups.com.

Re: [go-nuts] Should the program print true or false?

[tapi...@gmail.com]

Aha, you are totally wrong.
I made silly mistake here. ;D

On Thursday, September 17, 2020 at 12:05:31 PM UTC-4 
axel.wa...@googlemail.com wrote:

> I think you might've intended this, which does indeed print true:
>  type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner  
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com  
>> wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>>   "fmt"
>>>   "reflect"
>>> )
>>>
>>> func main() {
>>>   f()
>>> }
>>>
>>> func f() {
>>>   type S []S
>>>   var a, b S
>>>   a = S{0: b}
>>>   b = S{0: a}
>>>   fmt.Println(reflect.DeepEqual(a, b))
>>> }
>>>
>>> Now it prints false. But it looks the docs indicates it should print 
>>> true.
>>>
>>> -- 
>>> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/dbe73874-ec0f-413d-bed6-47f213bede91n%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/5dbbe944-1379-472e-b92a-4c77d3aadd4an%40googlegroups.com.

Re: [go-nuts] Should the program print true or false?

[tapi...@gmail.com]

Aha, you are totally right.
I made silly mistake here. ;D


On Thursday, September 17, 2020 at 12:05:31 PM UTC-4 
axel.wa...@googlemail.com wrote:

> I think you might've intended this, which does indeed print true:
>  type S []S
> var a, b S
> a, b = S{0: b}, S{0: a}
> fmt.Println(reflect.DeepEqual(a, b))
>
> On Thu, Sep 17, 2020 at 6:03 PM Axel Wagner  
> wrote:
>
>> I don't think the docs imply that. For one, a[0] is nil, and b[0] isn't.
>>
>> On Thu, Sep 17, 2020 at 5:58 PM tapi...@gmail.com  
>> wrote:
>>
>>>
>>> package main
>>>
>>> import (
>>>   "fmt"
>>>   "reflect"
>>> )
>>>
>>> func main() {
>>>   f()
>>> }
>>>
>>> func f() {
>>>   type S []S
>>>   var a, b S
>>>   a = S{0: b}
>>>   b = S{0: a}
>>>   fmt.Println(reflect.DeepEqual(a, b))
>>> }
>>>
>>> Now it prints false. But it looks the docs indicates it should print 
>>> true.
>>>
>>> -- 
>>> 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/dbe73874-ec0f-413d-bed6-47f213bede91n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/dbe73874-ec0f-413d-bed6-47f213bede91n%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/4b085282-3124-4c6e-9da4-ee4d10dbfae8n%40googlegroups.com.

[go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

[tapi...@gmail.com]

instead of sharing the same underlying types with some types?

-- 
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/da70dc55-7730-4131-ab41-f6a8fdfb397en%40googlegroups.com.

Re: [go-nuts] Cloud the current generic draft constraint a type parameter must be exactly some types

[tapi...@gmail.com]

If sum types are supported can they can be used as general parameter types,
then it is possible to declare overloaded functions/methods demoed in the 
end of this article 
<https://github.com/go101/go101/wiki/A-proposal-to-avoid-duplicating-underlying-bytes-when-using-strings-as-read-only-%5B%5Dbyte-arguments>.
 

This might be good for some scenarios.

On Friday, September 18, 2020 at 1:31:10 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Sep 18, 2020 at 10:07 AM tapi...@gmail.com  
> wrote:
> >
> > instead of sharing the same underlying types with some types?
>
> In the current design draft, the answer is yes, but only for
> non-predeclared defined types.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
>
> Ian
>

-- 
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/d7a14e4b-51e4-491d-a86b-ac1928c30642n%40googlegroups.com.

[go-nuts] Why is only "if", but not "for" and "switch", allowed to follow "else" keyword?

[tapi...@gmail.com]

IMO, the bar function is cleaner and more readable than the foo function.
How do you think?

func foo() {
if vs := f(); len(vs) == 0 {
} else {
for _, v := range vs {
}
}

if vs := f(); len(vs) == 0 {
} else {
switch {
case len(bs) == 0:
case len(bs) == 1:
default:
  }
}
}

// vs.

func bar() {
if vs := f(); len(vs) == 0 {
} else for _, v := range vs {
}

if vs := f(); len(vs) == 0 {
} else switch {
case len(vs) == 0:
case len(vs) == 1:
default:
}
}

-- 
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/6b6d44d7-2ce5-4cd0-9347-88b350715088n%40googlegroups.com.

Re: [go-nuts] Why is only "if", but not "for" and "switch", allowed to follow "else" keyword?

[tapi...@gmail.com]

On Tuesday, October 6, 2020 at 1:54:16 PM UTC-4 Ian Lance Taylor wrote:

> On Tue, Oct 6, 2020 at 10:28 AM tapi...@gmail.com  
> wrote: 
> > 
> > IMO, the bar function is cleaner and more readable than the foo 
> function. 
> > How do you think? 
> > 
> > func foo() { 
> > if vs := f(); len(vs) == 0 { 
> > } else { 
> > for _, v := range vs { 
> > } 
> > } 
> > 
> > if vs := f(); len(vs) == 0 { 
> > } else { 
> > switch { 
> > case len(bs) == 0: 
> > case len(bs) == 1: 
> > default: 
> > } 
> > } 
> > } 
> > 
> > // vs. 
> > 
> > func bar() { 
> > if vs := f(); len(vs) == 0 { 
> > } else for _, v := range vs { 
> > } 
> > 
> > if vs := f(); len(vs) == 0 { 
> > } else switch { 
> > case len(vs) == 0: 
> > case len(vs) == 1: 
> > default: 
> > } 
> > } 
>
> Well, why stop there? Why not 
>
> if vs := f(); len(vs) == 0 { 
> } else f2() 
>
> if vs := f(); len(vs) == 0 { 
> } else x = y 
>

These are different. "for" and "switch" are both code block start keywords, 
just the same as "if".
 

>
> There is a simple rule: 
> if   [else ] 
> In fact, for a while in the very early days of Go, that was the only 
> rule. But experience showed that people naturally want to write 
> if/else if/else, and having to add extra braces was frustrating, and 
> they tended to stack up. So the rule was extended to (roughly): 
> if   [else if   [else ]] 
>
> There's no obvious need to extend the rule in any other way. It's not 
> something that people are running into. 
>
> Ian 
>

-- 
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/7ab1cfb9-8fc8-43c7-88f9-6a06cca7a0d7n%40googlegroups.com.

[go-nuts] in "_ = debug && mylog.Infof("%s %d", str, n)", will the mylog.Infof call be always not executed if variable debug is false?

[tapi...@gmail.com]

.

-- 
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/7e959192-6844-4ac7-8757-6ceaaa81d87bn%40googlegroups.com.

[go-nuts] Re: in "_ = debug && mylog.Infof("%s %d", str, n)", will the mylog.Infof call be always not executed if variable debug is false?

[tapi...@gmail.com]

It looks the answer should be yes, as Go spec says:

   Logical operators apply to boolean 
<https://golang.org/ref/spec#Boolean_types> values and yield a result of 
the same type as the operands. The right operand is evaluated 
conditionally. 

Is my understanding right?



On Thursday, October 8, 2020 at 10:58:48 AM UTC-4 tapi...@gmail.com wrote:

>
> .

-- 
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/8d564e38-250c-4a31-a706-7be82f6ac61cn%40googlegroups.com.

[go-nuts] Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

For example, some local memory allocations could be detected no used 
elsewhere so that they can may be freed immediately when out of reach 
instead of waiting to be freed in the GC phase.

-- 
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/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.com.

Re: [go-nuts] Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

Aha, I forgot this fact. You are totally right.

It is a bad example. A better example: is it possible to detect that some 
values are always single-owner (and their out-of-reach time point are also 
detectable)?

On Sunday, November 15, 2020 at 8:23:58 PM UTC-5 xav...@gmail.com wrote:

> I may be misunderstanding what you're suggesting, but I believe Go already 
> tries to detect when a value can be placed on the stack. Then, it will be 
> freed automatically when it falls out of scope.
>
> On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com  
> wrote:
>
>>
>> For example, some local memory allocations could be detected no used 
>> elsewhere so that they can may be freed immediately when out of reach 
>> instead of waiting to be freed in the GC phase. 
>>
>> -- 
>> 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/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/5c38b239-fe56-44ce-aaf6-61636a682707n%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/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%40googlegroups.com.

[go-nuts] Let Go also support manual memory management, a good or bad idea?

[tapi...@gmail.com]

For example, by adding two new built-in functions: alloc and free, garbage 
collector will ignore the memory allocated by alloc. The memory allocated 
by alloc must be freed by calling the free function manually.

This would relieve the burden of GC for some Go programs (such as games).

-- 
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/17cc83a9-83c0-4878-abcb-30998299d1ecn%40googlegroups.com.

Re: [go-nuts] Let Go also support manual memory management, a good or bad idea?

[tapi...@gmail.com]

@kortschak
I think there are many benefits by using a pure Go implementation than a 
CGO one.
It would be even better to reuse/expose the internal tcmalloc.

@Ian
How about forbidding manual allocated memory references normal pointers?

On Sunday, November 15, 2020 at 9:23:54 PM UTC-5 Ian Lance Taylor wrote:

> On Sun, Nov 15, 2020 at 5:38 PM tapi...@gmail.com  
> wrote:
> >
> > For example, by adding two new built-in functions: alloc and free, 
> garbage collector will ignore the memory allocated by alloc. The memory 
> allocated by alloc must be freed by calling the free function manually.
> >
> > This would relieve the burden of GC for some Go programs (such as games).
>
> I think this is a misunderstanding of where GC time goes. If you can
> store a normal Go pointer in memory allocated using the new alloc
> function, then memory allocated by alloc must still be scanned by the
> GC.
>
> Ian
>

-- 
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/21159b26-4a56-455d-9665-b4f1eeaf8f33n%40googlegroups.com.

Re: [go-nuts] Re: Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

On Monday, November 16, 2020 at 5:19:59 AM UTC-5 Jan Mercl wrote:

> On Mon, Nov 16, 2020 at 11:14 AM 陶青云  wrote: 
>
> > FYI 
> > https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc/ 
>
> A CGo-free manual memory allocator might be a better fit sometimes: 
> https://godoc.org/modernc.org/memory


Thank both the information. I do prefer pure-Go implementations.
In fact, it would be even better if the internal tcmalloc could be reused 
and exposed as builtin functions.

(BTW, it looks these should be more suitable to discuss in the other 
thread: https://groups.google.com/g/golang-nuts/c/o0VAKfCyKS4
This thread is intended to discuss other auto ways of memory management.)

-- 
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/789d65ea-9afc-4dc3-819c-36fd3fcc26een%40googlegroups.com.

Re: [go-nuts] Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

On Sunday, November 15, 2020 at 10:24:05 PM UTC-5 ren...@ix.netcom.com 
wrote:

> It is the same. If it can escape the allocation frame you need GC. 
>

It could be viewed as advanced escape analyzing (by supporting run-time 
escape analyzing).
For example, a value might be used by many goroutines at run time,
but at any time point, it is only be used by one goroutine.
 

>
> On Nov 15, 2020, at 7:34 PM, tapi...@gmail.com  wrote:
>
> 
>
> Aha, I forgot this fact. You are totally right.
>
> It is a bad example. A better example: is it possible to detect that some 
> values are always single-owner (and their out-of-reach time point are also 
> detectable)?
>
> On Sunday, November 15, 2020 at 8:23:58 PM UTC-5 xav...@gmail.com wrote:
>
>> I may be misunderstanding what you're suggesting, but I believe Go 
>> already tries to detect when a value can be placed on the stack. Then, it 
>> will be freed automatically when it falls out of scope.
>>
>> On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com  
>> wrote:
>>
>>>
>>> For example, some local memory allocations could be detected no used 
>>> elsewhere so that they can may be freed immediately when out of reach 
>>> instead of waiting to be freed in the GC phase. 
>>>
>>> -- 
>>> 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/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/5c38b239-fe56-44ce-aaf6-61636a682707n%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/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%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/4b798d4e-269d-487c-a85a-835078c6625an%40googlegroups.com.

Re: [go-nuts] Is it possible that a hybrid memory management could be implemented?

[tapi...@gmail.com]

On Monday, November 16, 2020 at 9:17:50 AM UTC-5 ren...@ix.netcom.com wrote:

> Then you have reference counting or tracing GC. 
>
> Tracing GC a which Go has - has been proven superior to reference 
> counting. 
>

I feel there still room between the two to explore, though I have not a 
clear thought on this  yet. 

>
> On Nov 16, 2020, at 8:02 AM, tapi...@gmail.com  wrote:
>
> 
>
>
>
> On Sunday, November 15, 2020 at 10:24:05 PM UTC-5 ren...@ix.netcom.com 
> wrote:
>
>> It is the same. If it can escape the allocation frame you need GC. 
>>
>
> It could be viewed as advanced escape analyzing (by supporting run-time 
> escape analyzing).
> For example, a value might be used by many goroutines at run time,
> but at any time point, it is only be used by one goroutine.
>  
>
>>
>> On Nov 15, 2020, at 7:34 PM, tapi...@gmail.com  wrote:
>>
>> 
>>
>> Aha, I forgot this fact. You are totally right.
>>
>> It is a bad example. A better example: is it possible to detect that some 
>> values are always single-owner (and their out-of-reach time point are also 
>> detectable)?
>>
>> On Sunday, November 15, 2020 at 8:23:58 PM UTC-5 xav...@gmail.com wrote:
>>
>>> I may be misunderstanding what you're suggesting, but I believe Go 
>>> already tries to detect when a value can be placed on the stack. Then, it 
>>> will be freed automatically when it falls out of scope.
>>>
>>> On Sun, Nov 15, 2020 at 5:20 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>>
>>>> For example, some local memory allocations could be detected no used 
>>>> elsewhere so that they can may be freed immediately when out of reach 
>>>> instead of waiting to be freed in the GC phase. 
>>>>
>>>> -- 
>>>> 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/5c38b239-fe56-44ce-aaf6-61636a682707n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/5c38b239-fe56-44ce-aaf6-61636a682707n%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/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/7c7fcfde-14a3-4c6d-b53c-3c44f31d1568n%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/4b798d4e-269d-487c-a85a-835078c6625an%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/4b798d4e-269d-487c-a85a-835078c6625an%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/396c8d16-28a5-4a6c-ad20-3300435c02d5n%40googlegroups.com.

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

On Monday, January 4, 2021 at 5:23:06 PM UTC-5 ren...@ix.netcom.com wrote:

> Reading 
>
> sync.Map[string]linked.List string 
>
> I have no idea what that represents? 
>

If you can read

   sync.Map[string]chan string 

then you can read "sync.Map[string]linked.List string" too.

 

>
> What if you had a map of maps - which is a very common data structure - 
> possibly with completely different key and value types? Really any nested 
> data structures with multiple types would be impossible to read IMO. 
>

In

  map[k1]map[k2]map[k3]v3

and 

  map[k1, map[k2, map[k3, v3]]

which is more readable?
 

>
>
>
>
>
> > On Jan 4, 2021, at 2:39 PM, 'Anonymous AWK fan' via golang-nuts <
> golan...@googlegroups.com> wrote: 
> > 
> > I think something like sync.Map[string]linked.List string is more 
> readable than sync.Map[string, linked.List[string]]. 
> > 
> > I propose putting the last type parameter to a generic type after the 
> square brackets and omitting them when there is only one type parameter. 
> > 
> > -- 
> > 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/125582361.510700.1609792751744%40ichabod.co-bxl.
>  
>
>
>

-- 
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/8fcbc746-5f61-4b7c-9b7c-601e37bed94an%40googlegroups.com.

[go-nuts] Re: [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

On Tuesday, January 5, 2021 at 11:31:44 AM UTC-5 Brian Candler wrote:

> Are you trying to make user-defined generic maps look more like built-in 
> ones?
>
> map[T1]T2  is hard-coded syntax in go. But so is m[k] for accessing 
> elements - and you can't use that in user-defined types anyway.
>
> Therefore I don't think it helps much to be able to write mymap[T1]T2 
> instead of mymap[T1, T2], because you can't use the corresponding 
> accessors.  You would need something like:
>
> func (m *MyMap[KT, VT]) set(k KT, v VT) ...
> func (m *MyMap[KT, VT]) get(k KT) VT ...
>
> Also: to create one of these objects there is more built-in syntax you 
> can't use:
> v := make(mymap[T1]T2)   // won't work
>
> so you need to use a factory function. With your proposed syntax it would 
> be:
> v := makemymap[T1]T2()
>
> which IMO is worse than
> v := makemymap[T1, T2]()
>
> Example code: https://go2goplay.golang.org/p/2i3dgP2cKyz
>

You mixed up the current draft custom generic function syntax with OP's 
generic type syntax here.
It is no doubtful the result will be ugly. What about if the custom generic 
function syntax is consistent with built ones?
For example:

v := MakeMyMap(mymap[T1]T2) 
 

-- 
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/9a5805c7-3074-471f-8ef1-a95b68130026n%40googlegroups.com.

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

On Tuesday, January 5, 2021 at 8:43:44 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Tue, Jan 5, 2021 at 12:03 PM Anonymous AWK fan  
> wrote:
>
>> Why does there need to be a delimiter, there isn't one between chan and 
>> int in chan int, which I think is more readable than chan[int].
>>
>
> `chan` is a keyword, names of generic types and functions are identifiers.
> So, in a way, yes, there is a delimiter: `chan`.
>

Is it possible to change `chan` to a builtin identifier? (I'm uncertain on 
this.)
 

>
> I think most generic types would only have 1 type-parameter and the syntax 
>> should be like the built-in ones ([]T, *T, func(Params) Result, 
>> map[Key]Elem and chan T). Putting the extra ones in square brackets is the 
>> best thing I can think of. Also I think Graph[Node]Edge or Graph[Edge]Node 
>> is still readable.
>>
>
> Readability is not a binary choice, but a matter of degree. Everything is 
> *somewhat* readable. But implying an asymmetry that isn't there seems 
> confusing to me.
>
> I was only suggesting this for generic types.
>>
>
> Well, then that's another drawback. Using inconsistent syntax for generic 
> types and functions is confusing.
>

OP doesn't intend to use inconsistent syntax. I think it is just that OP 
hasn't got an idea on the function part yet.
 

>
> On Tue, Jan 5, 2021 at 12:43 PM Anonymous AWK fan  
> wrote:
>
>> Axel, please send your reply to golang-nuts too, you can ignore the rest 
>> of this, I already sent it to you but not golang-nuts because I didn't 
>> reply to all.
>>
>> > What is the "them" to be omitted if there is only one type parameter? 
>> It wouldn't make sense to omit the brackets (because there needs to be some 
>> delimiter between the name of the generic function/type and the type 
>> argument). But if there is only one type-parameter anyway, I don't know 
>> what else you would omit.
>>
>> Why does there need to be a delimiter, there isn't one between chan and 
>> int in chan int, which I think is more readable than chan[int].
>>
>> > Either way - you are using `sync.Map` to motivate this, with a clear 
>> analogue to `map`. But what about types that *don't* represent a map (like 
>> the Graph-example, where both type-parameters are on mostly equal footing)?
>>
>> I think most generic types would only have 1 type-parameter and the 
>> syntax should be like the built-in ones ([]T, *T, func(Params) Result, 
>> map[Key]Elem and chan T). Putting the extra ones in square brackets is the 
>> best thing I can think of. Also I think Graph[Node]Edge or Graph[Edge]Node 
>> is still readable.
>>
>> > And what about generic functions? I think
>> > Foo[int]string(bar, baz)
>> > isn't super readable, TBH.
>>
>> I was only suggesting this for generic types.
>>
>

-- 
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/cf8e703b-bb4e-4210-8b9d-42b94f4f8e95n%40googlegroups.com.

[go-nuts] Re: [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

On Tuesday, January 5, 2021 at 1:29:01 PM UTC-5 Brian Candler wrote:

> On Tuesday, 5 January 2021 at 18:17:14 UTC tapi...@gmail.com wrote:
>
>> What about if the custom generic function syntax is consistent with built 
>> ones?
>> For example:
>>
>> v := MakeMyMap(mymap[T1]T2) 
>>
>
> Would this be mandatory for all generics which take two or more types?  It 
> seems unbalanced to me.  Not everything is a hash-like container with a key 
> and value.
>
> Silly example:
>
> func blah[T1]T2 (x T1) T2 { ... }
>
> x := blah[int]string(123)
>

I didn't see anyone propose this syntax from the above comments.
 

>
> I think the current draft is clearer:
>
> func blah[T1, T2] (x T1) T2 { ... }
>
> x := blah[int, string](123)
>
>

-- 
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/236996ef-a872-4fcc-90ab-0c80722d953cn%40googlegroups.com.

[go-nuts] Re: [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

On Wednesday, January 6, 2021 at 9:40:15 AM UTC-5 Brian Candler wrote:

> On Wednesday, 6 January 2021 at 12:40:24 UTC tapi...@gmail.com wrote:
>
>> func blah[T1]T2 (x T1) T2 { ... }
>>>
>>> x := blah[int]string(123)
>>>
>>
>> I didn't see anyone propose this syntax from the above comments.
>>
>
> To quote the message which started the thread:
>
>
>
> *I think something like sync.Map[string]linked.List string is more 
> readable than sync.Map[string, linked.List[string]].*
> *I propose putting the last type parameter to a generic type after the 
> square brackets and omitting them when there is only one type parameter.*
>
> I accept it was talking about type parameters to types, not type 
> parameters to functions (although it would be weird if they were different).
>
> But even if you think only about types, it doesn't make much sense to make 
> the last type parameter distinct from the others. Another silly example:
>
> # current
> type Circle[T1,T2 any] struct {
> x,y,radius T1
> color T2
> }
>
> type myCircle Circle[float64,string]
>
> # proposed
> type Circle[T1 any]T2 any struct {
> x,y,radius T1
> color T2
> }
>
> type myCircle Circle[float64]string
>

I think OP's mistake "argument" as "parameter" in title.
OP didn't specify how to declare a generic type.

-- 
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/d5df1e82-c31e-41fa-a3e5-20acbf8d722fn%40googlegroups.com.

[go-nuts] Re: [generics] moving the last type parameter to a type outside the square brackets

[tapi...@gmail.com]

I think OP the "parameter" in title means "argument" actually.
OP didn't specify how to declare a generic type.


On Wednesday, January 6, 2021 at 9:40:15 AM UTC-5 Brian Candler wrote:

> On Wednesday, 6 January 2021 at 12:40:24 UTC tapi...@gmail.com wrote:
>
>> func blah[T1]T2 (x T1) T2 { ... }
>>>
>>> x := blah[int]string(123)
>>>
>>
>> I didn't see anyone propose this syntax from the above comments.
>>
>
> To quote the message which started the thread:
>
>
>
> *I think something like sync.Map[string]linked.List string is more 
> readable than sync.Map[string, linked.List[string]].*
> *I propose putting the last type parameter to a generic type after the 
> square brackets and omitting them when there is only one type parameter.*
>
> I accept it was talking about type parameters to types, not type 
> parameters to functions (although it would be weird if they were different).
>
> But even if you think only about types, it doesn't make much sense to make 
> the last type parameter distinct from the others. Another silly example:
>
> # current
> type Circle[T1,T2 any] struct {
> x,y,radius T1
> color T2
> }
>
> type myCircle Circle[float64,string]
>
> # proposed
> type Circle[T1 any]T2 any struct {
> x,y,radius T1
> color T2
> }
>
> type myCircle Circle[float64]string
>
>

-- 
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/01b2f97a-17d0-4a01-9bdf-df73e12dfe47n%40googlegroups.com.

[go-nuts] Re: compare of bytes or string?

[tapi...@gmail.com]

If both the memory addresses of the first bytes are equal, then the fast 
route will be selected by comparing their lengths.
Otherwise, byte by byte. 

On Wednesday, February 10, 2021 at 5:22:28 AM UTC-5 cuiw...@gmail.com wrote:

> i look into map key compare key about string,it will use runtime·memequal, 
> i thing the stra == strb will call memequal  two.
>
>
> On Wednesday, February 10, 2021 at 6:12:18 PM UTC+8 xie cui wrote:
>
>> compare two byte slice,will convert to compare between two string, and my 
>> question is how golang compare two string, i don't think that it just 
>> compare the len and then comapare bytes in string one byte by one byte, it 
>> should have some optimization?where is the code in compiler generate the 
>> compare codes?
>
>

-- 
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/190074fa-c1d6-41a5-a0fc-ef3e0d62a5c8n%40googlegroups.com.

[go-nuts] "go1.15 mod tidy" fails if the current project depends on a module containing a file using embed and guarded by "+build go1.16"

[tapi...@gmail.com]

Does this mean the "+build go1.N" directive is only intended to cooperate 
with Go toolchain 1.N+?  

-- 
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/a64cbbb4-9d59-4ddf-a6de-bae083f82c4an%40googlegroups.com.

[go-nuts] Re: "go1.15 mod tidy" fails if the current project depends on a module containing a file using embed and guarded by "+build go1.16"

[tapi...@gmail.com]

BTW, "go1.15 build" succeeds.

On Thursday, February 18, 2021 at 4:03:50 AM UTC-5 tapi...@gmail.com wrote:

> Does this mean the "+build go1.N" directive is only intended to cooperate 
> with Go toolchain 1.N+?  
>

-- 
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/3346c3dd-e0c2-4684-9c6c-6a8b1d948c68n%40googlegroups.com.

Re: [go-nuts] Re: "go1.15 mod tidy" fails if the current project depends on a module containing a file using embed and guarded by "+build go1.16"

[tapi...@gmail.com]

Thanks for the link.
So "go mod tidy" ignores build tags, and this is intended?

On Thursday, February 18, 2021 at 9:28:53 AM UTC-5 Ian Lance Taylor wrote:

> On Thu, Feb 18, 2021 at 1:06 AM tapi...@gmail.com  
> wrote:
> >
> > BTW, "go1.15 build" succeeds.
> >
> > On Thursday, February 18, 2021 at 4:03:50 AM UTC-5 tapi...@gmail.com 
> wrote:
> >>
> >> Does this mean the "+build go1.N" directive is only intended to 
> cooperate with Go toolchain 1.N+?
>
>
> See the discussion at https://golang.org/issue/43980.
>
> Ian
>

-- 
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/9a4eb260-d5de-4a7d-89e3-e26a9ff41455n%40googlegroups.com.

Re: [go-nuts] Re: "go1.15 mod tidy" fails if the current project depends on a module containing a file using embed and guarded by "+build go1.16"

[tapi...@gmail.com]

reasonable. Thanks both for explanations.

On Friday, February 19, 2021 at 7:20:36 AM UTC-5 Amnon wrote:

> go mod tidy has to ignore build tags.
>
> Because if it did not ignore build tags, it would delete dependencies 
> needed by other platforms.
>
> On Friday, 19 February 2021 at 02:23:45 UTC Ian Lance Taylor wrote:
>
>> On Thu, Feb 18, 2021 at 3:29 PM tapi...@gmail.com  
>> wrote:
>> >
>> > Thanks for the link.
>> > So "go mod tidy" ignores build tags, and this is intended?
>>
>> That is my understanding, yes.
>>
>> Ian
>>
>>
>> > On Thursday, February 18, 2021 at 9:28:53 AM UTC-5 Ian Lance Taylor 
>> wrote:
>> >>
>> >> On Thu, Feb 18, 2021 at 1:06 AM tapi...@gmail.com  
>> wrote:
>> >> >
>> >> > BTW, "go1.15 build" succeeds.
>> >> >
>> >> > On Thursday, February 18, 2021 at 4:03:50 AM UTC-5 tapi...@gmail.com 
>> wrote:
>> >> >>
>> >> >> Does this mean the "+build go1.N" directive is only intended to 
>> cooperate with Go toolchain 1.N+?
>> >>
>> >>
>> >> See the discussion at https://golang.org/issue/43980.
>> >>
>> >> Ian
>> >
>> > --
>> > 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/9a4eb260-d5de-4a7d-89e3-e26a9ff41455n%40googlegroups.com
>> .
>>
>

-- 
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/4493d0de-d8b4-4092-9da8-10f9ebb5dffcn%40googlegroups.com.

[go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

[tapi...@gmail.com]

https://play.golang.org/p/-GZajVGPWYv



-- 
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/79c31128-29a4-49ee-84cf-1df061dda842n%40googlegroups.com.

Re: [go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

[tapi...@gmail.com]

What I mean is 

fmt.Println(v3)

and

fmt.Println(v3.Elem())

print the same thing. Is it an intended design?

On Thursday, February 25, 2021 at 11:11:52 PM UTC-5 Kurtis Rader wrote:

> On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com  
> wrote:
>
>>
>> https://play.golang.org/p/-GZajVGPWYv
>>
>
> You need to clarify your question. I don't see any obvious problem with 
> the output of your program. The reflect.Value.Elem() call is defined to 
> return a reflect.Elem object. But that observation might be irrelevant 
> since you have not clearly stated the problem. 
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/b6eea02a-1197-4800-a6e1-73096c15170cn%40googlegroups.com.

Re: [go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

[tapi...@gmail.com]

It looks, the fmt package makes some special handling for reflect.Value:

package main

import "reflect"
import "fmt"

func main() {
var v1 = reflect.ValueOf(0)
var p1 = &v1
var v2 = 0
var p2 = &v2
var v3 interface{} = 0
var p3 = &v3
fmt.Println(p1)  // 
fmt.Println(p2)  // 0xcb6020
fmt.Println(p3)  // 0xc9e220
}

On Friday, February 26, 2021 at 1:42:32 AM UTC-5 tapi...@gmail.com wrote:

> What I mean is 
>
> fmt.Println(v3)
>
> and
>
> fmt.Println(v3.Elem())
>
> print the same thing. Is it an intended design?
>
> On Thursday, February 25, 2021 at 11:11:52 PM UTC-5 Kurtis Rader wrote:
>
>> On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com  
>> wrote:
>>
>>>
>>> https://play.golang.org/p/-GZajVGPWYv
>>>
>>
>> You need to clarify your question. I don't see any obvious problem with 
>> the output of your program. The reflect.Value.Elem() call is defined to 
>> return a reflect.Elem object. But that observation might be irrelevant 
>> since you have not clearly stated the problem. 
>>
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>

-- 
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/4d5a2649-535e-466c-ae9e-a1797a7e9225n%40googlegroups.com.

Re: [go-nuts] When using fmt.Print to print a reflect.Value v, v.Elem() is printed instead. Why?

[tapi...@gmail.com]

Thanks for the info.

The info does verify that reflect.Values are specially handled in fmt.Print,
and it also clearly sates String() method of the argument reflect.Values
are not called in fmt.Print:

The fmt package treats Values specially.  It does not call their String 
method
implicitly but instead prints the concrete values they hold.

It looks the docs is too simple, if not very accurate. It doesn't specify 
clearly
whether or not the "prints" operation in "but instead prints the concrete 
values they hold"
will call the String methods of the concrete values if the the concrete 
values
are also reflect.Values (a.k.a., indirect reflect.Values). The fact is it 
calls indeed.

IMHO, the design is some confusing.

On Friday, February 26, 2021 at 8:29:15 AM UTC-5 clba...@gmail.com wrote:

> Yes.  You have to understand how "fmt.Print," etc., handle types with 
> String() methods.  From the docs:
>
> package fmt - 
>
> 5. If an operand implements method String() string, that method will be 
> invoked to convert the object to a string, which will then be formatted as 
> required by the verb (if any).
>
> package reflect - 
>
> func (Value) Elem 
> <http://localhost:6060/src/reflect/value.go?s=25679:25706#L800>
> func (v Value <http://localhost:6060/pkg/reflect/#Value>) Elem() Value 
> <http://localhost:6060/pkg/reflect/#Value>
>
> Elem returns the value that the interface v contains or that the pointer v 
> points to. It panics if v's Kind is not Interface or Ptr. It returns the 
> zero Value if v is nil.
>
> func (Value) String 
> <http://localhost:6060/src/reflect/value.go?s=55738:55768#L1847>
>
> func (v Value <http://localhost:6060/pkg/reflect/#Value>) String() string 
> <http://localhost:6060/pkg/builtin/#string>
>
> String returns the string v's underlying value, as a string. String is a 
> special case because of Go's String method convention. Unlike the other 
> getters, it does not panic if v's Kind is not String. Instead, it returns a 
> string of the form "" where T is v's type. The fmt package treats 
> Values specially. It does not call their String method implicitly but 
> instead prints the concrete values they hold.
> On Thursday, February 25, 2021 at 11:42:32 PM UTC-7 tapi...@gmail.com 
> wrote:
>
>> What I mean is 
>>
>> fmt.Println(v3)
>>
>> and
>>
>> fmt.Println(v3.Elem())
>>
>> print the same thing. Is it an intended design?
>>
>> On Thursday, February 25, 2021 at 11:11:52 PM UTC-5 Kurtis Rader wrote:
>>
>>> On Thu, Feb 25, 2021 at 8:01 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>>
>>>> https://play.golang.org/p/-GZajVGPWYv
>>>>
>>>
>>> You need to clarify your question. I don't see any obvious problem with 
>>> the output of your program. The reflect.Value.Elem() call is defined to 
>>> return a reflect.Elem object. But that observation might be irrelevant 
>>> since you have not clearly stated the problem. 
>>>
>>> -- 
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>>

-- 
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/b98fec66-837e-4986-9657-8fb1252979e0n%40googlegroups.com.

[go-nuts] Are the two unsafe uses safe?

[tapi...@gmail.com]

1.

func String2ByteSlice(s string) []byte {
return (*[^uint(0) >> 1]byte)(unsafe.Pointer(&s))[:len(s):len(s)]
}

2.

func String2ByteSlice(s string) []byte {
return *(*[]byte)(unsafe.Pointer(&struct{string; int}{s, len(s)}))
}

-- 
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/e0bf8ea0-9793-42d4-937c-979cc94ac41bn%40googlegroups.com.

[go-nuts] Re: Are the two unsafe uses safe?

[tapi...@gmail.com]

Sorry, the first one will get a "type [9223372036854775807]byte larger than 
address space" error.
The following code will get the same error

var x *[^uint(0) >> 1]byte

Is this error essential?

On Saturday, February 27, 2021 at 11:00:26 PM UTC-5 tapi...@gmail.com wrote:

> 1.
>
> func String2ByteSlice(s string) []byte {
> return (*[^uint(0) >> 1]byte)(unsafe.Pointer(&s))[:len(s):len(s)]
> }
>
> 2.
>
> func String2ByteSlice(s string) []byte {
> return *(*[]byte)(unsafe.Pointer(&struct{string; int}{s, len(s)}))
> }
>

-- 
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/411f0d80-eb3c-4737-94cf-1f4dd73e1678n%40googlegroups.com.

Re: [go-nuts] Are the two unsafe uses safe?

[tapi...@gmail.com]

On Sunday, February 28, 2021 at 8:29:51 AM UTC-5 Ian Lance Taylor wrote:

> On Sat, Feb 27, 2021 at 8:00 PM tapi...@gmail.com  
> wrote: 
> > 
> > 1. 
> > 
> > func String2ByteSlice(s string) []byte { 
> > return (*[^uint(0) >> 1]byte)(unsafe.Pointer(&s))[:len(s):len(s)] 
> > } 
>
> This doesn't do what you probably want, as &s is not the address of 
> the bytes in the string. 

 
Aha, I forgot this point.


> > 2. 
> > 
> > func String2ByteSlice(s string) []byte { 
> > return *(*[]byte)(unsafe.Pointer(&struct{string; int}{s, len(s)})) 
> > } 
>
> This is more likely to work but it's not safe. 
>

Why? For slice field order is undefined?
 

>
> Ian 
>

-- 
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/4b958edc-882c-40cf-909b-c8ce38ed781fn%40googlegroups.com.

[go-nuts] Is it too rough to use a version to conrol Go features?

[tapi...@gmail.com]

Would be better to use compile flags to control each language features 
individually?

-- 
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/8571e10e-369c-4ce3-b55c-f20dc43445a3n%40googlegroups.com.

[go-nuts] Re: Is it too rough to use a version to conrol Go features?

[tapi...@gmail.com]

BTW, I think the embedding functionality introduced in Go 1.16 should not 
be viewed as a feature.
It should be viewed as an API change instead.
Now Go projects using embedding and setting go directive verison as v1.15 
in go.mod fail to compile with Go toolchain 1.16.
IMO, this is unnecessary, for the "//go:embed" directive always requires 
importing the "embed" package.

On Tuesday, March 2, 2021 at 6:14:23 AM UTC-5 tapi...@gmail.com wrote:

> Would be better to use compile flags to control each language features 
> individually?
>

-- 
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/c8e1bd96-78e2-434a-a0cc-4356382e49fcn%40googlegroups.com.

Re: [go-nuts] Re: Is it too rough to use a version to conrol Go features?

[tapi...@gmail.com]

What is the difference between "embed" and "io/fs"?
A Go project with version declared as 1.15 in go.mod and using "io/fs" 
compiles okay with Go toolchain 1.16.

On Tuesday, March 2, 2021 at 7:50:15 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> Okay, sorry for the multiple, quick mails, but:
> I would even say it *has* to be done the way it is. Because otherwise 
> compilation will *not* fail, if you declare a wrong go version to use. That 
> is, if you use `//go:embed`, declare your used version as go 1.15 and test 
> it yourself using go 1.16, your module is broken. Users of your module that 
> only have go 1.15 will break and get a crypting error message about `embed` 
> being missing, instead of a reasonable message that their go version is not 
> fresh enough.
> I don't understand why you'd want a broken module to compile.
>
> On Tue, Mar 2, 2021 at 1:46 PM Axel Wagner  
> wrote:
>
>> Sorry, I have to walk that back - my test code was wrong, you are 
>> correct, compilation fails.
>> The point still stands - they require 1.16, so they set that, not 1.15. 
>> Either way - compilation will fail, why does it matter if it fails because 
>> `embed` doesn't exist before 1.16, or whether it fails because `//go:embed` 
>> is not supported before 1.16?
>>
>> On Tue, Mar 2, 2021 at 1:42 PM Axel Wagner  
>> wrote:
>>
>>> There would be no advantage to that - all features are either available, 
>>> or not available, depending on which version you use. There is no "go 1.16 
>>> without `embed`". It also needs to be set in `go.mod`, because you might 
>>> compile modules written for different go versions into one binary - so 
>>> which language version to use is part of the module description.
>>> So, no. Putting a language version into `go.mod` seems to be exactly the 
>>> right way to do this.
>>>
>>> On Tue, Mar 2, 2021 at 12:21 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> BTW, I think the embedding functionality introduced in Go 1.16 should 
>>>> not be viewed as a feature.
>>>> It should be viewed as an API change instead.
>>>>
>>>
>>> I don't understand what you mean by this. There is no intrinsic 
>>> difference between the two. In this particular case, the `embed` package 
>>> adds an API to support a new feature "embedding static files in go 
>>> binaries".
>>>  
>>>
>>>> Now Go projects using embedding and setting go directive verison as 
>>>> v1.15 in go.mod fail to compile with Go toolchain 1.16.
>>>>
>>>
>>> They shouldn't do that. If they use `embed`, they require at least go 
>>> 1.16, so they set that.
>>> I can't reproduce your claim that setting `go 1.15` and using embed will 
>>> fail to compile with a Go 1.16 toolchain. It works fine for me.
>>>
>>> IMO, this is unnecessary, for the "//go:embed" directive always requires 
>>>> importing the "embed" package.
>>>>
>>>> On Tuesday, March 2, 2021 at 6:14:23 AM UTC-5 tapi...@gmail.com wrote:
>>>>
>>>>> Would be better to use compile flags to control each language features 
>>>>> individually?
>>>>>
>>>> -- 
>>>> 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/c8e1bd96-78e2-434a-a0cc-4356382e49fcn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/c8e1bd96-78e2-434a-a0cc-4356382e49fcn%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/3bc3bcfc-48d5-47c8-abb0-8fd3197765b8n%40googlegroups.com.

Re: [go-nuts] Re: Is it too rough to use a version to conrol Go features?

[tapi...@gmail.com]

> Maybe it shouldn't.

By my knowledge, the version specified in go.mod doesn't prevent APIs newer 
than the version to be used. This is design.

=

OK. It looks a Go project with version declared as 1.15 in go.mod and 
importing "embed" also compiles okay with Go toolchain 1.16
So the key distinction is whether there are "//go:embed" directives are 
used.
Here, I tested four setups (all with version declared as 1.15 in go.mod and 
compile with Go toolechain 1.16:
1. a source file importing "io/fs". It compiles okay.
2. a source file importing "embed" but not using "//go:embed". It also 
compiles okay.
3. a source file importing "embed" and using "//go:embed". It fails to 
compile with an error "go:embed requires go1.16 or later (-lang was set to 
go1.15; check go.mod)"
4. a source file importing using "//go:embed" and not importing 1.16 new 
packages. It fails to compile with an error "usage: //go:embed pattern...".

I don't know whether or not it is intended to let the latter two cases 
report different errors.





On Tuesday, March 2, 2021 at 8:25:53 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> Maybe it shouldn't.
>
> FWIW, there is one significant difference, which is that `//go:embed` 
> needs support from the go tool and compiler to work. That is, the files 
> need to be read and we need to emit initialization code for the variables 
> holding the embedded files. So, a go toolchain that is not aware of 
> embedding can't possibly compile the code (correctly).
>
> On Tue, Mar 2, 2021 at 2:19 PM tapi...@gmail.com  
> wrote:
>
>> What is the difference between "embed" and "io/fs"?
>> A Go project with version declared as 1.15 in go.mod and using "io/fs" 
>> compiles okay with Go toolchain 1.16.
>>
>> On Tuesday, March 2, 2021 at 7:50:15 AM UTC-5 axel.wa...@googlemail.com 
>> wrote:
>>
>>> Okay, sorry for the multiple, quick mails, but:
>>> I would even say it *has* to be done the way it is. Because otherwise 
>>> compilation will *not* fail, if you declare a wrong go version to use. That 
>>> is, if you use `//go:embed`, declare your used version as go 1.15 and test 
>>> it yourself using go 1.16, your module is broken. Users of your module that 
>>> only have go 1.15 will break and get a crypting error message about `embed` 
>>> being missing, instead of a reasonable message that their go version is not 
>>> fresh enough.
>>> I don't understand why you'd want a broken module to compile.
>>>
>>> On Tue, Mar 2, 2021 at 1:46 PM Axel Wagner  
>>> wrote:
>>>
>>>> Sorry, I have to walk that back - my test code was wrong, you are 
>>>> correct, compilation fails.
>>>> The point still stands - they require 1.16, so they set that, not 1.15. 
>>>> Either way - compilation will fail, why does it matter if it fails because 
>>>> `embed` doesn't exist before 1.16, or whether it fails because 
>>>> `//go:embed` 
>>>> is not supported before 1.16?
>>>>
>>>> On Tue, Mar 2, 2021 at 1:42 PM Axel Wagner  
>>>> wrote:
>>>>
>>>>> There would be no advantage to that - all features are either 
>>>>> available, or not available, depending on which version you use. There is 
>>>>> no "go 1.16 without `embed`". It also needs to be set in `go.mod`, 
>>>>> because 
>>>>> you might compile modules written for different go versions into one 
>>>>> binary 
>>>>> - so which language version to use is part of the module description.
>>>>> So, no. Putting a language version into `go.mod` seems to be exactly 
>>>>> the right way to do this.
>>>>>
>>>>> On Tue, Mar 2, 2021 at 12:21 PM tapi...@gmail.com  
>>>>> wrote:
>>>>>
>>>>>> BTW, I think the embedding functionality introduced in Go 1.16 should 
>>>>>> not be viewed as a feature.
>>>>>> It should be viewed as an API change instead.
>>>>>>
>>>>>
>>>>> I don't understand what you mean by this. There is no intrinsic 
>>>>> difference between the two. In this particular case, the `embed` package 
>>>>> adds an API to support a new feature "embedding static files in go 
>>>>> binaries".
>>>>>  
>>>>>
>>>>>> Now Go projects using embedding and setting go directive verison as 
>&

Re: [go-nuts] Re: Is it too rough to use a version to conrol Go features?

[tapi...@gmail.com]

sorry, the 4th setup reports "//go:embed only allowed in Go files that 
import "embed"".

On Tuesday, March 2, 2021 at 8:38:05 AM UTC-5 tapi...@gmail.com wrote:

> > Maybe it shouldn't.
>
> By my knowledge, the version specified in go.mod doesn't prevent APIs 
> newer than the version to be used. This is design.
>
> =
>
> OK. It looks a Go project with version declared as 1.15 in go.mod and 
> importing "embed" also compiles okay with Go toolchain 1.16
> So the key distinction is whether there are "//go:embed" directives are 
> used.
> Here, I tested four setups (all with version declared as 1.15 in go.mod 
> and compile with Go toolechain 1.16:
> 1. a source file importing "io/fs". It compiles okay.
> 2. a source file importing "embed" but not using "//go:embed". It also 
> compiles okay.
> 3. a source file importing "embed" and using "//go:embed". It fails to 
> compile with an error "go:embed requires go1.16 or later (-lang was set to 
> go1.15; check go.mod)"
> 4. a source file importing using "//go:embed" and not importing 1.16 new 
> packages. It fails to compile with an error "usage: //go:embed pattern...".
>
> I don't know whether or not it is intended to let the latter two cases 
> report different errors.
>
>
>
>
>
> On Tuesday, March 2, 2021 at 8:25:53 AM UTC-5 axel.wa...@googlemail.com 
> wrote:
>
>> Maybe it shouldn't.
>>
>> FWIW, there is one significant difference, which is that `//go:embed` 
>> needs support from the go tool and compiler to work. That is, the files 
>> need to be read and we need to emit initialization code for the variables 
>> holding the embedded files. So, a go toolchain that is not aware of 
>> embedding can't possibly compile the code (correctly).
>>
>> On Tue, Mar 2, 2021 at 2:19 PM tapi...@gmail.com  
>> wrote:
>>
>>> What is the difference between "embed" and "io/fs"?
>>> A Go project with version declared as 1.15 in go.mod and using "io/fs" 
>>> compiles okay with Go toolchain 1.16.
>>>
>>> On Tuesday, March 2, 2021 at 7:50:15 AM UTC-5 axel.wa...@googlemail.com 
>>> wrote:
>>>
>>>> Okay, sorry for the multiple, quick mails, but:
>>>> I would even say it *has* to be done the way it is. Because otherwise 
>>>> compilation will *not* fail, if you declare a wrong go version to use. 
>>>> That 
>>>> is, if you use `//go:embed`, declare your used version as go 1.15 and test 
>>>> it yourself using go 1.16, your module is broken. Users of your module 
>>>> that 
>>>> only have go 1.15 will break and get a crypting error message about 
>>>> `embed` 
>>>> being missing, instead of a reasonable message that their go version is 
>>>> not 
>>>> fresh enough.
>>>> I don't understand why you'd want a broken module to compile.
>>>>
>>>> On Tue, Mar 2, 2021 at 1:46 PM Axel Wagner  
>>>> wrote:
>>>>
>>>>> Sorry, I have to walk that back - my test code was wrong, you are 
>>>>> correct, compilation fails.
>>>>> The point still stands - they require 1.16, so they set that, not 
>>>>> 1.15. Either way - compilation will fail, why does it matter if it fails 
>>>>> because `embed` doesn't exist before 1.16, or whether it fails because 
>>>>> `//go:embed` is not supported before 1.16?
>>>>>
>>>>> On Tue, Mar 2, 2021 at 1:42 PM Axel Wagner  
>>>>> wrote:
>>>>>
>>>>>> There would be no advantage to that - all features are either 
>>>>>> available, or not available, depending on which version you use. There 
>>>>>> is 
>>>>>> no "go 1.16 without `embed`". It also needs to be set in `go.mod`, 
>>>>>> because 
>>>>>> you might compile modules written for different go versions into one 
>>>>>> binary 
>>>>>> - so which language version to use is part of the module description.
>>>>>> So, no. Putting a language version into `go.mod` seems to be exactly 
>>>>>> the right way to do this.
>>>>>>
>>>>>> On Tue, Mar 2, 2021 at 12:21 PM tapi...@gmail.com  
>>>>>> wrote:
>>>>>>
>>>>>>> BTW, I think the embedding functionality introduced in Go 1.16 
>>>

[go-nuts] "go build" records the GOROOT info of the machine the result binary is produced on?

[tapi...@gmail.com]

I have two machines, their GOROOTs are different.
I build a binary on one machine then transfer the binary to the other.
It runs well on the machine the binary is produced on, but fails on the 
other.

The code reporting the error is

  unsafePkg, err := build.Import("unsafe", "", build.FindOnly)
   if err != nil {
  log.Fatal(fmt.Errorf("build.Import: %w", err))
   }

The error is 

  build.Import: go/build: go list unsafe: exit status 2
  go: cannot find GOROOT directory: /home/myname/path/of/GOROOT


-- 
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/c02407eb-2fec-4195-8ef3-46a33e233c66n%40googlegroups.com.

Re: [go-nuts] "go build" records the GOROOT info of the machine the result binary is produced on?

[tapi...@gmail.com]

I see two problems here.

1. By the document, it looks it should check the result of `go env GOROOT` 
firstly, but it doesn't.

2. It exposes some personal privacy to make the last attempt work. By the 
document, it looks some personal privacy will be always record in the 
binary file, even if the last attempt is not adopted in the end.

On Tuesday, March 9, 2021 at 2:53:19 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> https://golang.org/pkg/runtime/#GOROOT
>
> GOROOT returns the root of the Go tree. It uses the GOROOT environment 
>> variable, if set at process start, or else the root used during the Go 
>> build.
>
>
> I don't understand how you expect a binary to find GOROOT otherwise, if 
> you don't set the environment variable.
>
> On Tue, Mar 9, 2021 at 6:38 AM tapi...@gmail.com  
> wrote:
>
>> I have two machines, their GOROOTs are different.
>> I build a binary on one machine then transfer the binary to the other.
>> It runs well on the machine the binary is produced on, but fails on the 
>> other.
>>
>> The code reporting the error is
>>
>>   unsafePkg, err := build.Import("unsafe", "", build.FindOnly)
>>if err != nil {
>>   log.Fatal(fmt.Errorf("build.Import: %w", err))
>>}
>>
>> The error is 
>>
>>   build.Import: go/build: go list unsafe: exit status 2
>>   go: cannot find GOROOT directory: /home/myname/path/of/GOROOT
>>
>>
>> -- 
>> 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/c02407eb-2fec-4195-8ef3-46a33e233c66n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/c02407eb-2fec-4195-8ef3-46a33e233c66n%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/d5011895-955d-4400-ab65-122d68dd93d2n%40googlegroups.com.

Re: [go-nuts] "go build" records the GOROOT info of the machine the result binary is produced on?

[tapi...@gmail.com]

On Tuesday, March 9, 2021 at 5:02:34 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Tue, Mar 9, 2021 at 10:09 AM tapi...@gmail.com  
> wrote:
>
>> 1. By the document, it looks it should check the result of `go env 
>> GOROOT` firstly, but it doesn't.
>>
>
> I don't think that's true. The documentation says, it looks in $GOROOT and 
> if that's not set, in the GOROOT of the go binary it was built on. `go env 
> GOROOT`, on the other hand, first reports $GOROOT, if set, and otherwise 
> reports the GOROOT *that particular go command resides in*. That is, `go 
> env GOROOT` does not report $GOROOT, it also has its own, distinct fallback 
> built in, which may differ from the one `foo` uses (if it was built with 
> another go installation).
>
> That, again, seems like the correct choice - after all, we can't assume 
> there actually *is* a go command, when we run `foo`. It is common to run a 
> go binary on a system without a go installation.
>

But isn't assuming GOROOT exists almost equivalent to assuming "go" command 
exists?
 

>
> 2. It exposes some personal privacy to make the last attempt work. By the 
>> document, it looks some personal privacy will be always record in the 
>> binary file, even if the last attempt is not adopted in the end.
>>
>
> That is true. I think the practicalities of being able to run go tools 
> without configuration or environment variables outweigh this, though. For 
> example, if a user installs go and (say) goimports from their distribution 
> repository, we want the goimports binary to be able to find stdlib 
> packages, even if the user does not have GOROOT set.
> Having the actual filesystem paths built in also simplifies debugging - it 
> means a debugger can find the files and show you source information. While 
> `go env GOROOT` might be able to replace the fallback for the former 
> use-case, it wouldn't be available to the debugger.
>
> Note that you can always remove any host-specific information by building 
> a go release in a generic path and use that to build go packages. That is 
> also what happens if you use a go release provided by your distribution. So 
> the downsides don't seem enormous, given that you can always circumvent 
> them with relatively little hassle.
>
>
>> On Tuesday, March 9, 2021 at 2:53:19 AM UTC-5 axel.wa...@googlemail.com 
>> wrote:
>>
>>> https://golang.org/pkg/runtime/#GOROOT
>>>
>>> GOROOT returns the root of the Go tree. It uses the GOROOT environment 
>>>> variable, if set at process start, or else the root used during the Go 
>>>> build.
>>>
>>>
>>> I don't understand how you expect a binary to find GOROOT otherwise, if 
>>> you don't set the environment variable.
>>>
>>> On Tue, Mar 9, 2021 at 6:38 AM tapi...@gmail.com  
>>> wrote:
>>>
>>>> I have two machines, their GOROOTs are different.
>>>> I build a binary on one machine then transfer the binary to the other.
>>>> It runs well on the machine the binary is produced on, but fails on the 
>>>> other.
>>>>
>>>> The code reporting the error is
>>>>
>>>>   unsafePkg, err := build.Import("unsafe", "", build.FindOnly)
>>>>if err != nil {
>>>>   log.Fatal(fmt.Errorf("build.Import: %w", err))
>>>>}
>>>>
>>>> The error is 
>>>>
>>>>   build.Import: go/build: go list unsafe: exit status 2
>>>>   go: cannot find GOROOT directory: /home/myname/path/of/GOROOT
>>>>
>>>>
>>>> -- 
>>>> 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/c02407eb-2fec-4195-8ef3-46a33e233c66n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/c02407eb-2fec-4195-8ef3-46a33e233c66n%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/d5011895-955d-4400-ab65-122d68dd93d2n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/d5011895-955d-4400-ab65-122d68dd93d2n%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/3baa8c24-5eb1-48bf-9fef-9c94ec765e29n%40googlegroups.com.

Re: [go-nuts] "go build" records the GOROOT info of the machine the result binary is produced on?

[tapi...@gmail.com]

On Tuesday, March 9, 2021 at 7:04:17 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> On Tue, Mar 9, 2021 at 12:39 PM tapi...@gmail.com  
> wrote:
>
>> But isn't assuming GOROOT exists almost equivalent to assuming "go" 
>> command exists?
>>
>
> Maybe. As I said, it might have been possible to try `go env GOROOT` 
> instead or in addition to looking at $GOROOT. It might even be possible to 
> change that default now. There would likely still need to be *some* 
> fallback (as exec'ing `go` might fail). I honestly don't know. I do know 
> that the documentation currently does not say `go/build` is looking at `go 
> env`, though, but that it directly inspects the environment.
>
> In any case, note that you can get whatever behavior you like by 
> explicitly setting Context.GOROOT 
> <https://golang.org/pkg/go/build/#Context.GOROOT>. Given that it's easy 
> to overwrite the default behavior and given that `go/build` should, in 
> practice, be considered to be superseded by `
> golang.org/x/tools/go/packages` <http://golang.org/x/tools/go/packages>, 
> I don't personally feel much need to discuss the particulars. Maybe someone 
> else has more of a stake in this.
>

`golang.org/x/tools/go/packages` <http://golang.org/x/tools/go/packages> 
parse "unsafe" in an unexpected way, which is why I turned to "build.Import" 
instead.

This workaround by setting Context.GOROOT 
<https://golang.org/pkg/go/build/#Context.GOROOT>. should work, I think. 
Thanks for the suggestion.
 

>
>  
>>
>>>
>>> 2. It exposes some personal privacy to make the last attempt work. By 
>>>> the document, it looks some personal privacy will be always record in the 
>>>> binary file, even if the last attempt is not adopted in the end.
>>>>
>>>
>>> That is true. I think the practicalities of being able to run go tools 
>>> without configuration or environment variables outweigh this, though. For 
>>> example, if a user installs go and (say) goimports from their distribution 
>>> repository, we want the goimports binary to be able to find stdlib 
>>> packages, even if the user does not have GOROOT set.
>>> Having the actual filesystem paths built in also simplifies debugging - 
>>> it means a debugger can find the files and show you source information. 
>>> While `go env GOROOT` might be able to replace the fallback for the former 
>>> use-case, it wouldn't be available to the debugger.
>>>
>>> Note that you can always remove any host-specific information by 
>>> building a go release in a generic path and use that to build go packages. 
>>> That is also what happens if you use a go release provided by your 
>>> distribution. So the downsides don't seem enormous, given that you can 
>>> always circumvent them with relatively little hassle.
>>>
>>>
>>>> On Tuesday, March 9, 2021 at 2:53:19 AM UTC-5 axel.wa...@googlemail.com 
>>>> wrote:
>>>>
>>>>> https://golang.org/pkg/runtime/#GOROOT
>>>>>
>>>>> GOROOT returns the root of the Go tree. It uses the GOROOT environment 
>>>>>> variable, if set at process start, or else the root used during the Go 
>>>>>> build.
>>>>>
>>>>>
>>>>> I don't understand how you expect a binary to find GOROOT otherwise, 
>>>>> if you don't set the environment variable.
>>>>>
>>>>> On Tue, Mar 9, 2021 at 6:38 AM tapi...@gmail.com  
>>>>> wrote:
>>>>>
>>>>>> I have two machines, their GOROOTs are different.
>>>>>> I build a binary on one machine then transfer the binary to the other.
>>>>>> It runs well on the machine the binary is produced on, but fails on 
>>>>>> the other.
>>>>>>
>>>>>> The code reporting the error is
>>>>>>
>>>>>>   unsafePkg, err := build.Import("unsafe", "", build.FindOnly)
>>>>>>if err != nil {
>>>>>>   log.Fatal(fmt.Errorf("build.Import: %w", err))
>>>>>>}
>>>>>>
>>>>>> The error is 
>>>>>>
>>>>>>   build.Import: go/build: go list unsafe: exit status 2
>>>>>>   go: cannot find GOROOT directory: /home/myname/path/of/GOROOT
>>>>>>
>>>>>>
>>>>>> -- 
>>>>&g

[go-nuts] finalizers questions again

[tapi...@gmail.com]

The tailscale article 
https://tailscale.com/blog/netaddr-new-ip-type-for-go/ mentions a finalizer 
trick. 

The SetFinalizer docs says the finalizer of an object is not guaranteed to 
be run. So the tailscale trick is valid, could I think that an object is 
not collected for sure if it has a finalizer and the finalizer has not run 
yet?




-- 
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/35f08f19-6e73-4511-82dd-63867160f9d8n%40googlegroups.com.

[go-nuts] Re: finalizers questions again

[tapi...@gmail.com]

(sorry, missed a "if")
 So if the tailscale trick is valid, could I think that an object is 
not collected for sure if it has a finalizer and the finalizer has not run 
yet?

On Thursday, March 11, 2021 at 9:42:49 AM UTC-5 tapi...@gmail.com wrote:

>
> The tailscale article 
> https://tailscale.com/blog/netaddr-new-ip-type-for-go/ mentions a 
> finalizer trick. 
>
> The SetFinalizer docs says the finalizer of an object is not guaranteed to 
> be run. So the tailscale trick is valid, could I think that an object is 
> not collected for sure if it has a finalizer and the finalizer has not run 
> yet?
>
>
>
>
>

-- 
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/8647fac5-5453-4598-870f-0048db3a454an%40googlegroups.com.

[go-nuts] About the efficency of modifying map elements.

[tapi...@gmail.com]

Now, to modify a map element, especially the element type is not a basic 
type, two hashes are needed to compute. This is often unnecessary and 
inefficient. For example:

package main

type T struct{
N int
// ... more fields
}

func main() {
var m = map[string]T{}
m["foo"] = T{N: 0}

// modify
t := m["foo"] // first hashing
t.N++
m["foo"] = t  // second hashing
}

Will it be good to add a new builtin function, modify(m Map[Key]Value, k 
Key, func(v *Value)), to modify map elements with only one hash? A use 
example:

package main

type T struct{
N int
// ... more fields
}

func main() {
var m = map[string]T{}
m["foo"] = T{N: 0}

// modify
modify(m. "foo", func(t *T) {
t.N++
})
}

-- 
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/ba7b2c95-829b-4da4-916a-d53a06ec3428n%40googlegroups.com.

Re: [go-nuts] About the efficency of modifying map elements.

[tapi...@gmail.com]

I found this performance difference by benchmarking the two:

func IntAdd(words [][]byte) map[string]int {
var m = make(map[string]int)
for _, w := range words {
m[string(w)] = m[string(w)] + 1

}
return m
}

func IntIncrement(words [][]byte) map[string]int {
var m = make(map[string]int)
for _, w := range words {
m[string(w)]++
}
return m
}

IntAdd is obviously slower than IntIncrement.

On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4 axel.wa...@googlemail.com 
wrote:

> Hi,
>
> have you verified this using a disassembler or benchmarks? Just asking 
> because this is, as far as I'm concerned, a job for the compiler, to 
> eliminate the overhead automatically - and I could well imagine that it's 
> already doing it. There definitely shouldn't be a new language construct 
> for this.
>
> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com  
> wrote:
>
>> Now, to modify a map element, especially the element type is not a basic 
>> type, two hashes are needed to compute. This is often unnecessary and 
>> inefficient. For example:
>>
>> package main
>>
>> type T struct{
>> N int
>> // ... more fields
>> }
>>
>> func main() {
>> var m = map[string]T{}
>> m["foo"] = T{N: 0}
>> 
>> // modify
>> t := m["foo"] // first hashing
>> t.N++
>> m["foo"] = t  // second hashing
>> }
>>
>> Will it be good to add a new builtin function, modify(m Map[Key]Value, k 
>> Key, func(v *Value)), to modify map elements with only one hash? A use 
>> example:
>>
>> package main
>>
>> type T struct{
>> N int
>> // ... more fields
>> }
>>
>> func main() {
>> var m = map[string]T{}
>> m["foo"] = T{N: 0}
>> 
>> // modify
>> modify(m. "foo", func(t *T) {
>> t.N++
>> })
>> }
>>
>> -- 
>> 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/ba7b2c95-829b-4da4-916a-d53a06ec3428n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/ba7b2c95-829b-4da4-916a-d53a06ec3428n%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/d763c1fd-6e57-41f1-90e1-98a369ddf3bcn%40googlegroups.com.

Re: [go-nuts] About the efficency of modifying map elements.

[tapi...@gmail.com]

For simple scenarios, compiler optimizations might be possible.
But for some complicate ones, it is hard for compiler to do optimizations.
For example, the element is modified by an function between the map
element getter and setter and the behavior of the function is hard to
determined at compile time, it might modify or not modify the key.


On Wednesday, March 17, 2021 at 4:51:09 PM UTC-4 axel.wa...@googlemail.com 
wrote:

> Yes, Jan's link also pretty clearly shows that this optimization isn't 
> currently happening :) Sorry for the noise.
> I still believe it should be an optimization in the compiler, not a 
> language-level feature.
>
> On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com  
> wrote:
>
>>
>> I found this performance difference by benchmarking the two:
>>
>> func IntAdd(words [][]byte) map[string]int {
>> var m = make(map[string]int)
>> for _, w := range words {
>> m[string(w)] = m[string(w)] + 1
>> 
>> }
>> return m
>> }
>>
>> func IntIncrement(words [][]byte) map[string]int {
>> var m = make(map[string]int)
>> for _, w := range words {
>> m[string(w)]++
>> }
>> return m
>> }
>>
>> IntAdd is obviously slower than IntIncrement.
>>
>> On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4 
>> axel.wa...@googlemail.com wrote:
>>
>>> Hi,
>>>
>>> have you verified this using a disassembler or benchmarks? Just asking 
>>> because this is, as far as I'm concerned, a job for the compiler, to 
>>> eliminate the overhead automatically - and I could well imagine that it's 
>>> already doing it. There definitely shouldn't be a new language construct 
>>> for this.
>>>
>>> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> Now, to modify a map element, especially the element type is not a 
>>>> basic type, two hashes are needed to compute. This is often unnecessary 
>>>> and 
>>>> inefficient. For example:
>>>>
>>>> package main
>>>>
>>>> type T struct{
>>>> N int
>>>> // ... more fields
>>>> }
>>>>
>>>> func main() {
>>>> var m = map[string]T{}
>>>> m["foo"] = T{N: 0}
>>>> 
>>>> // modify
>>>> t := m["foo"] // first hashing
>>>> t.N++
>>>> m["foo"] = t  // second hashing
>>>> }
>>>>
>>>> Will it be good to add a new builtin function, modify(m Map[Key]Value, 
>>>> k Key, func(v *Value)), to modify map elements with only one hash? A use 
>>>> example:
>>>>
>>>> package main
>>>>
>>>> type T struct{
>>>> N int
>>>> // ... more fields
>>>> }
>>>>
>>>> func main() {
>>>> var m = map[string]T{}
>>>> m["foo"] = T{N: 0}
>>>> 
>>>> // modify
>>>> modify(m. "foo", func(t *T) {
>>>> t.N++
>>>> })
>>>> }
>>>>
>>>> -- 
>>>> 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/ba7b2c95-829b-4da4-916a-d53a06ec3428n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/ba7b2c95-829b-4da4-916a-d53a06ec3428n%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/d763c1fd-6e57-41f1-90e1-98a369ddf3bcn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/d763c1fd-6e57-41f1-90e1-98a369ddf3bcn%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/52f00985-3e0b-4562-80d9-705ae8e5e507n%40googlegroups.com.

[go-nuts] Re: %v for []string{} and []string{""}

[tapi...@gmail.com]

Printing a nil slice also get the same output [].

I remembered Rob Pike ever said in an issue thread that this can't be 
changed now for compatibility reason.

On Monday, March 15, 2021 at 8:18:46 AM UTC-4 Brian Candler wrote:

> I was slightly surprised to discover that the Print() output for an empty 
> slice, and a 1-element slice containing the empty string, are the same:
>
> https://play.golang.org/p/btkzgk4LMT9
>
> It does follow logically from the rules 
> .  I guess I need to train 
> myself to use %q or %#v.
>

-- 
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/8531b38b-cffe-4d47-8dcf-9d4a45a6da3cn%40googlegroups.com.

Re: [go-nuts] About the efficency of modifying map elements.

[tapi...@gmail.com]

On Wednesday, March 17, 2021 at 5:19:55 PM UTC-4 axel.wa...@googlemail.com 
wrote:

> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com  
> wrote:
>
>> For simple scenarios, compiler optimizations might be possible.
>> But for some complicate ones, it is hard for compiler to do optimizations.
>> For example, the element is modified by an function between the map
>> element getter and setter and the behavior of the function is hard to
>> determined at compile time, it might modify or not modify the key.
>>
>
> Yes. I would strongly prefer to have these uncommon cases be slower to 
> complicating the language.
>
> FWIW, if anything, the signature would have to take a `func(T) T`, not a 
> `func(*T)` - values in a map are not addressable for a reason. If we would 
> use a pointer, it would allow the programmer to retain that pointer outside 
> of the function, which would not be safe.
>

Yes, "func(*T)" is problematic. But the "func(T) T" is inefficient for 
large types.
There are too many constraints in using the builtin map, though it really 
provides much convenience.
Hope custom maps will help in such situations.
 

>
> But this also implies that any case covered by that function can be 
> re-written as
>
> _tmp := k // temporary variable, in case k is modified
> v := m[_tmp]
> // do the same as the function would
> m[_tmp] = v
>
> which should easily recognizable by the compiler. That means we would only 
> need to optimize this simple case and anyone concerned about speed could 
> rewrite their code into this form to get the same result.
>
> So, I don't actually think doing it as an optimization is harder or less 
> powerful than adding this function. It should cover the same cases, without 
> complicating the language.
>
>
>
>>
>> On Wednesday, March 17, 2021 at 4:51:09 PM UTC-4 
>> axel.wa...@googlemail.com wrote:
>>
>>> Yes, Jan's link also pretty clearly shows that this optimization isn't 
>>> currently happening :) Sorry for the noise.
>>> I still believe it should be an optimization in the compiler, not a 
>>> language-level feature.
>>>
>>> On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>>
>>>> I found this performance difference by benchmarking the two:
>>>>
>>>> func IntAdd(words [][]byte) map[string]int {
>>>> var m = make(map[string]int)
>>>> for _, w := range words {
>>>> m[string(w)] = m[string(w)] + 1
>>>> 
>>>> }
>>>> return m
>>>> }
>>>>
>>>> func IntIncrement(words [][]byte) map[string]int {
>>>> var m = make(map[string]int)
>>>> for _, w := range words {
>>>> m[string(w)]++
>>>> }
>>>> return m
>>>> }
>>>>
>>>> IntAdd is obviously slower than IntIncrement.
>>>>
>>>> On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4 
>>>> axel.wa...@googlemail.com wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> have you verified this using a disassembler or benchmarks? Just asking 
>>>>> because this is, as far as I'm concerned, a job for the compiler, to 
>>>>> eliminate the overhead automatically - and I could well imagine that it's 
>>>>> already doing it. There definitely shouldn't be a new language construct 
>>>>> for this.
>>>>>
>>>>> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com  
>>>>> wrote:
>>>>>
>>>>>> Now, to modify a map element, especially the element type is not a 
>>>>>> basic type, two hashes are needed to compute. This is often unnecessary 
>>>>>> and 
>>>>>> inefficient. For example:
>>>>>>
>>>>>> package main
>>>>>>
>>>>>> type T struct{
>>>>>> N int
>>>>>> // ... more fields
>>>>>> }
>>>>>>
>>>>>> func main() {
>>>>>> var m = map[string]T{}
>>>>>> m["foo"] = T{N: 0}
>>>>>> 
>>>>>> // modify
>>>>>> t := m["foo"] // first hashing
>>>>>> t.N++
>>>>>> m["foo"] = t  // second hashing
>>>>>>

Re: [go-nuts] About the efficency of modifying map elements.

[tapi...@gmail.com]

On Wednesday, March 17, 2021 at 5:23:57 PM UTC-4 matthew...@nytimes.com 
wrote:

> Isn't this really just another form of issue 3117 
> <https://github.com/golang/go/issues/3117>?
>

Some of, but really different.
 

>
>
> On Wed, Mar 17, 2021 at 3:19 PM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com  
>> wrote:
>>
>>> For simple scenarios, compiler optimizations might be possible.
>>> But for some complicate ones, it is hard for compiler to do 
>>> optimizations.
>>> For example, the element is modified by an function between the map
>>> element getter and setter and the behavior of the function is hard to
>>> determined at compile time, it might modify or not modify the key.
>>>
>>
>> Yes. I would strongly prefer to have these uncommon cases be slower to 
>> complicating the language.
>>
>> FWIW, if anything, the signature would have to take a `func(T) T`, not a 
>> `func(*T)` - values in a map are not addressable for a reason. If we would 
>> use a pointer, it would allow the programmer to retain that pointer outside 
>> of the function, which would not be safe.
>>
>> But this also implies that any case covered by that function can be 
>> re-written as
>>
>> _tmp := k // temporary variable, in case k is modified
>> v := m[_tmp]
>> // do the same as the function would
>> m[_tmp] = v
>>
>> which should easily recognizable by the compiler. That means we would 
>> only need to optimize this simple case and anyone concerned about speed 
>> could rewrite their code into this form to get the same result.
>>
>> So, I don't actually think doing it as an optimization is harder or less 
>> powerful than adding this function. It should cover the same cases, without 
>> complicating the language.
>>
>>
>>
>>>
>>> On Wednesday, March 17, 2021 at 4:51:09 PM UTC-4 
>>> axel.wa...@googlemail.com wrote:
>>>
>>>> Yes, Jan's link also pretty clearly shows that this optimization isn't 
>>>> currently happening :) Sorry for the noise.
>>>> I still believe it should be an optimization in the compiler, not a 
>>>> language-level feature.
>>>>
>>>> On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com  
>>>> wrote:
>>>>
>>>>>
>>>>> I found this performance difference by benchmarking the two:
>>>>>
>>>>> func IntAdd(words [][]byte) map[string]int {
>>>>> var m = make(map[string]int)
>>>>> for _, w := range words {
>>>>> m[string(w)] = m[string(w)] + 1
>>>>> 
>>>>> }
>>>>> return m
>>>>> }
>>>>>
>>>>> func IntIncrement(words [][]byte) map[string]int {
>>>>> var m = make(map[string]int)
>>>>> for _, w := range words {
>>>>> m[string(w)]++
>>>>> }
>>>>> return m
>>>>> }
>>>>>
>>>>> IntAdd is obviously slower than IntIncrement.
>>>>>
>>>>> On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4 
>>>>> axel.wa...@googlemail.com wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> have you verified this using a disassembler or benchmarks? Just 
>>>>>> asking because this is, as far as I'm concerned, a job for the compiler, 
>>>>>> to 
>>>>>> eliminate the overhead automatically - and I could well imagine that 
>>>>>> it's 
>>>>>> already doing it. There definitely shouldn't be a new language construct 
>>>>>> for this.
>>>>>>
>>>>>> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com  
>>>>>> wrote:
>>>>>>
>>>>>>> Now, to modify a map element, especially the element type is not a 
>>>>>>> basic type, two hashes are needed to compute. This is often unnecessary 
>>>>>>> and 
>>>>>>> inefficient. For example:
>>>>>>>
>>>>>>> package main
>>>>>>>
>>>>>>> type T struct{
>>>>>>> N int
>>>>>>> // ... more fields
>>>>>>> }
&g

[go-nuts] What is the easiest way to find out the source hosting url of a thrid-party dependency module/package?

[tapi...@gmail.com]

It looks such info is not recorded in GOPATH/pkg/mod.

-- 
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/f114fd4d-2510-401b-96a3-cee77ae26028n%40googlegroups.com.

Re: [go-nuts] What is the easiest way to find out the source hosting url of a thrid-party dependency module/package?

[tapi...@gmail.com]

Ah. I forgot this way. Thanks for the tip!

On Thursday, April 8, 2021 at 11:25:55 AM UTC-4 Jan Mercl wrote:

> On Thu, Apr 8, 2021 at 5:18 PM tapi...@gmail.com  
> wrote:
>
> > It looks such info is not recorded in GOPATH/pkg/mod.
>
> Do you mean the import path to repository URL mapping?
>
> jnml@e5-1650:~/tmp$ wget modernc.org/sqlite && grep go- sqlite
> --2021-04-08 17:23:49--  http://modernc.org/sqlite
> Resolving modernc.org (modernc.org)... 216.239.32.21, 216.239.38.21, 
> 216.239.36.21, ...
> Connecting to modernc.org (modernc.org)|216.239.32.21|:80... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: https://modernc.org/sqlite [following]
> --2021-04-08 17:23:49--  https://modernc.org/sqlite
> Connecting to modernc.org (modernc.org)|216.239.32.21|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 577 [text/html]
> Saving to: 'sqlite'
>
> sqlite   
>  
> 100%[=>]
>  
> 577  --.-KB/sin 0s  
>
> 2021-04-08 17:23:49 (10.8 MB/s) - 'sqlite' saved [577/577]
>
> https://gitlab.com/cznic/sqlite";>
> https://gitlab.com/cznic/sqlite/blob/master{/dir} 
> https://gitlab.com/cznic/sqlite/blob/master{/dir}/{file}#L{line}";>
> jnml@e5-1650:~/tmp$
>
>

-- 
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/50235b22-6034-4474-a5f7-e0093defe28en%40googlegroups.com.

Re: [go-nuts] Give us const arrays please :)

[tapi...@gmail.com]

More immutable value proposals: 
https://github.com/go101/go101/wiki/Go-immutable-value-proposal-list

On Sunday, April 11, 2021 at 8:47:31 PM UTC-4 Kurtis Rader wrote:

> This has been formally requested several times. For example:
>
> https://github.com/golang/go/issues/20443
> https://github.com/golang/go/issues/22876
>
> I'm also willing to bet you are basing your request on experience with a 
> language such as C. Adopting ideas from other languages is fine but 
> blindly, and simplistically, shoehorning a feature from another language 
> almost never has a satisfying result.
>
> On Sun, Apr 11, 2021 at 4:33 PM 'Vladimir Efanov' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Hi Go-Masters
>>
>> It will be very useful to get constant arrays in Golang.
>> Programmers asked about it for years .
>>
>> For now we all should write not exported array definitions 
>> and exported functions to get read access to it.
>>
>> *What we need*
>> const *M*yArray = [n]T = {...} or initMyArrayFunc()
>>
>> *What we have*
>> // ---
>> var ws = [256]bool{' ': true, '\t': true, '\n\: true, '\r\: true}
>> // IsWhitespace checks 
>> func IsWhitespace(c byte) bool {
>> return whitespace[c]
>> }
>> // ---
>> var letter = [256]bool{
>> 'A': true, 'B': true, 'C': true, 'D': true, 'E': true, 'F': true, 
>> ...
>> }
>> //  IsLetterASCII checks a start of an ASCII identifier
>> func  IsLetterASCII(c byte) bool {
>> return letter[c] // 'A'-'Z', 'a'-'z', '_'
>> }
>>  and so on ...
>>
>>
>>
>> -- 
>> 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/01f4a524-9463-4770-8f9d-a17962cd5ba7n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/cd8265e6-c87b-417d-90ef-5c5a9eecc958n%40googlegroups.com.

[go-nuts] go build ./... will produce a binary of one and only one main package is found

[tapi...@gmail.com]

I often use "go build ./..." command to check if there are compilation 
errors. Before ./... included 2+ main packages but now only one. Then the 
behavior changes, I accidentally commit and push a 10M binary to the remote 
repository.

Is this a intended design? 

-- 
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/1a513203-0c80-40f7-b30b-ed4c4c022d1en%40googlegroups.com.

[go-nuts] Re: go build ./... will produce a binary of one and only one main package is found

[tapi...@gmail.com]

Sorry, "of" should "if" in title.

On Monday, April 19, 2021 at 9:40:00 AM UTC-4 tapi...@gmail.com wrote:

> I often use "go build ./..." command to check if there are compilation 
> errors. Before ./... included 2+ main packages but now only one. Then the 
> behavior changes, I accidentally commit and push a 10M binary to the remote 
> repository.
>
> Is this a intended design? 
>

-- 
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/35c2791a-b9b2-4a29-a87c-0fafe0aa420bn%40googlegroups.com.

[go-nuts] Re: go build ./... will produce a binary of one and only one main package is found

[tapi...@gmail.com]

Thanks for the information.

Personally, I think the behavior is hard to predict. The binary should be 
only produced when a single path is specified.

On Monday, April 19, 2021 at 10:59:33 AM UTC-4 Brian Candler wrote:

> In short, yes this is as intended, although somewhat obscure.  The 
> documentation is here 
> :
>
> *"When compiling a single main package, build writes the resulting 
> executable to an output file named after the first source file ('go build 
> ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go 
> build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when 
> writing a Windows executable.*
>
> *When compiling multiple packages or a single non-main package, build 
> compiles the packages but discards the resulting object, serving only as a 
> check that the packages can be built.*
>
> *The -o flag forces build to write the resulting executable or object to 
> the named output file or directory, instead of the default behavior 
> described in the last two paragraphs."*
> For me I had the problem the other way 
> : 
> "go build ./..." was happily building the binary when there was only one 
> main package, but stopped working when I added a second.  The solution for 
> me was "go build -o . ./..."
>
> Sorry but I don't know how to make go build with a single main package 
> discard the output.  I'd be inclined to make use of .gitignore
>
>

-- 
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/c9d04c77-006f-468e-9972-4ad4ad94c9ben%40googlegroups.com.

[go-nuts] Is there a bug in the command "go list -deps -json ./..."?

[tapi...@gmail.com]

I checked out the kubernetes project at tag v1.20.4.
Then run "go list -deps -json ./... > json,txt" in the project root.
In the produced json.txt file, I notice that the module path for
two packages look not right. The path of a package should be
prefixed with its module path. But the two don't. Bug?

The first:

{
"Dir": 
"/home/lx/mount/sda2/opensource/it-infrastructure/kubernetes/vendor/github.com/Azure/go-autorest/autorest/azure",
"ImportPath": "github.com/Azure/go-autorest/autorest/azure",
"Name": "azure",
"Doc": "Package azure provides Azure-specific implementations used with 
AutoRest.",
"Module": {
"Path": "github.com/Azure/go-autorest/autorest/adal",
"Replace": {
"Path": "github.com/Azure/go-autorest/autorest/adal",
"Version": "v0.9.5"
}
},
...

The second:

{
"Dir": 
"/home/lx/mount/sda2/opensource/it-infrastructure/kubernetes/vendor/cloud.google.com/go/compute/metadata",
"ImportPath": "cloud.google.com/go/compute/metadata",
"Name": "metadata",
"Doc": "Package metadata provides access to Google Compute Engine (GCE) 
metadata and API service accounts.",
"Module": {
"Path": "cloud.google.com/go/bigquery",
"Replace": {
"Path": "cloud.google.com/go/bigquery",
"Version": "v1.4.0"
},
"Indirect": true
},
...

-- 
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/afd7670b-87cf-4ede-9467-648f5d5cbc77n%40googlegroups.com.

[go-nuts] Re: Is there a bug in the command "go list -deps -json ./..."?

[tapi...@gmail.com]

I mean, should package "github.com/Azure/go-autorest/autorest/azure" be in 
module "github.com/Azure/go-autorest/autorest/adal"?
And, should package "cloud.google.com/go/compute/metadata"" be in module "
cloud.google.com/go/bigquery"?

On Monday, April 19, 2021 at 12:05:38 PM UTC-4 Brian Candler wrote:

> Can you explain exactly which values you think are wrong, and what values 
> they should have? I can't see any problem with those.
>
> Examples I checked:
>
> github.com/Azure/go-autorest/autorest/azure
> ^module (there is a go.mod 
> here )
> ^^^  package within that 
> module - no go.mod
>
> github.com/Azure/go-autorest/autorest/adal
> ^^   module (there is a 
> go.mod here 
> )
>

-- 
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/f7956c7a-0318-4c00-90f8-ea0b93fdf21cn%40googlegroups.com.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[tapi...@gmail.com]

older threads:
* https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o/m/JMJ0fGqhCgAJ
* https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/gCjjBviJBwAJ

On Thursday, April 29, 2021 at 4:51:43 AM UTC-4 oyvin...@teigfam.net wrote:

> I know from some years ago that go did not have any priority or ordered 
> select construct [1].
>
> The idea is that select always is a nondeterministic choice operator, if 
> this is still so. Implemented with a random, I assume.
>
> Programming user defined "fair" algorithms or patterns is then not 
> possible, I believe.
>
> Is this still so in Go? No prioritised or ordered select in go?
>
> But is there still a way to code this by f.ex. combining several selects? 
> I saw a different take at this at [2], where the select is replaced a 
> single chan containing a chan bundle, thus becoming "deterministic".
>
> [1] Blog note Nondeterminism 
>  
> (disclaimer: 
> no ads, no gifts, only fun and expenses)
>
> [2] “A pattern for overcoming non-determinism of Golang select statement 
> 
>  (3May2019) 
> by Pedram Hajesmaeeli
>

-- 
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/23c24de3-723b-442e-b011-fa21ce135d19n%40googlegroups.com.

[go-nuts] A little surprising result in clone slices with different ways to clone slices

[tapi...@gmail.com]

func MakeCopy(s []int) []int {10%
r := make([]int, len(s))
copy(r, s)
return r
}

func MakeAppend(s []int) []int {
return append(make([]int, 0, len(s)), s...)
}

func MakeAppend2(s []int) []int {
r := make([]int, 0, len(s))
return append(r, s...)
}

It looks MakeCopy is always (about 10%) faster than MakeAppend ones.

The MakeAppend ways are faster than the following append ways for small 
slices,
but slower than them for large slices, which is also some surprising.

func Append(s []int) []int {
return append([]int(nil), s...)
}

func Append2(s []int) []int {
return append(s[:0:0], s...)
}

-- 
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/78527e34-05ba-43c9-ab80-a3ce7edc64fbn%40googlegroups.com.

[go-nuts] Boxing bytes is faster than boxing integers within [0. 255]. Why?

[tapi...@gmail.com]

Different optimizations are applied for them?

The benchmark:

package main

import "testing"

func BoxByte(b byte) interface{} {
return b
}

func BoxInt64(i int64) interface{} {
return i
}

var b0, b1, b2 byte = 0, 128, 255
var d, e, f interface{}
func Benchmark_BoxByte(b *testing.B) {
for i := 0; i < b.N; i++ {
d = BoxByte(b0)
e = BoxByte(b1)
f = BoxByte(b2)
}
}

var i0s, i1s, i2s int64 = 0, 128, 255
var m, n, o interface{}
func Benchmark_BoxInt64_Small(b *testing.B) {
for i := 0; i < b.N; i++ {
m = BoxInt64(i0s)
n = BoxInt64(i1s)
o = BoxInt64(i2s)
}
}

var i0b, i1b, i2b int64 = 256, 1024, 65536
var x, y, z interface{}
func Benchmark_BoxInt64_Large(b *testing.B) {
for i := 0; i < b.N; i++ {
x = BoxInt64(i0b)
y = BoxInt64(i1b)
z = BoxInt64(i2b)
}
}

The result:

$ go test -bench=. 
goos: linux
goarch: amd64
pkg: a.b/c/ttt
cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
Benchmark_BoxByte-4  429777054 2.681 ns/op
Benchmark_BoxInt64_Small-4   125588462 9.527 ns/op
Benchmark_BoxInt64_Large-4   1801902863.75 ns/op


-- 
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/4e140fff-3c8b-4b91-b5c7-3806c58a2d59n%40googlegroups.com.

Re: [go-nuts] Boxing bytes is faster than boxing integers within [0. 255]. Why?

[tapi...@gmail.com]

Yes, I'm aware of this optimization.
But it looks another optimization is applied for boxing bytes.

On Monday, May 10, 2021 at 10:38:39 AM UTC-4 Jan Mercl wrote:

> On Mon, May 10, 2021 at 4:30 PM tapi...@gmail.com  
> wrote:
>
>
> https://github.com/golang/go/commit/9828c43288a53d3df75b1f73edad0d037a91dff8
>

-- 
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/1b5feb93-a1b9-4bd7-871a-d4851c15f031n%40googlegroups.com.

Re: [go-nuts] Boxing bytes is faster than boxing integers within [0. 255]. Why?

[tapi...@gmail.com]

I'm not familiar with the compile code, but I guess it should be helpful.
It looks boxing bytes are handled at compile time but boxing small integers 
are handled at run time.

Thanks for the info. 

On Monday, May 10, 2021 at 11:40:07 AM UTC-4 axel.wa...@googlemail.com 
wrote:

> Does this help?
>
>
> https://github.com/golang/go/blob/25aff96f4b49842a44253b72472062a6d775231c/src/cmd/compile/internal/gc/walk.go#L841
>
> On Mon, May 10, 2021 at 4:46 PM tapi...@gmail.com  
> wrote:
>
>> Yes, I'm aware of this optimization.
>> But it looks another optimization is applied for boxing bytes.
>>
>> On Monday, May 10, 2021 at 10:38:39 AM UTC-4 Jan Mercl wrote:
>>
>>> On Mon, May 10, 2021 at 4:30 PM tapi...@gmail.com  
>>> wrote: 
>>>
>>>
>>> https://github.com/golang/go/commit/9828c43288a53d3df75b1f73edad0d037a91dff8
>>>  
>>>
>> -- 
>> 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/1b5feb93-a1b9-4bd7-871a-d4851c15f031n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/1b5feb93-a1b9-4bd7-871a-d4851c15f031n%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/68b72d41-2a20-4c1a-8ae9-5c5c6ea0c3f2n%40googlegroups.com.

[go-nuts] Strange benchmark results

[tapi...@gmail.com]

package main

import "testing"

const N = 1615119
// It is strange that if N is large enough,
// the one line implementations are fast as the others.
// And if N is odd number, the InsertOneline_Disassemble
// implementation is about 10% faster than the others.

func init() {
println(" N =", N)
}

func InsertOneline(s []int, k int, vs ...int) []int {
return append(s[:k], append(vs, s[k:]...)...)
}

func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
z := append(vs, s[k:]...)
return append(s[:k], z...)
}

func InsertVerbose(s []int, k int, vs ...int) []int {
if n := len(s) + len(vs); n <= cap(s) {
s2 := s[:n]
copy(s2[k+len(vs):], s[k:])
copy(s2[k:], vs)
return s2
}
s2 := make([]int, len(s) + len(vs))
copy(s2, s[:k])
copy(s2[k:], vs)
copy(s2[k+len(vs):], s[k:])
return s2
}


func InsertVerbose_b(s []int, k int, vs ...int) []int {
if n := len(s) + len(vs); n <= cap(s) {
s2 := s[:n]
copy(s2[k+len(vs):], s[k:])
copy(s2[k:], vs)
return s2
}
s2 := make([]int, 0, len(s) + len(vs))
s2 = append(s2, s[:k]...)
s2 = append(s2, vs...)
s2 = append(s2, s[k:]...)
return s2
}

func InsertVerbose_c(s []int, k int, vs ...int) []int {
if n := len(s) + len(vs); n <= cap(s) {
s2 := s[:n]
copy(s2[k+len(vs):], s[k:])
copy(s2[k:], vs)
return s2
}
s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
s2 = append(s2, s[:k]...)
s2 = append(s2, vs...)
s2 = append(s2, s[k:]...)
return s2
}

var s1 []int
func Benchmark_InsertOneline(b *testing.B) {
var x = make([]int, N)
var y = make([]int, N/2)
var k = N/5
b.ResetTimer()
for i := 0; i < b.N; i++ {
s1 = InsertOneline(x, k, y...)
}
}

var s1b []int
func Benchmark_InsertOneline_Disassemble(b *testing.B) {
var x = make([]int, N)
var y = make([]int, N/2)
var k = N/2
b.ResetTimer()
for i := 0; i < b.N; i++ {
s1b = InsertOneline_Disassemble(x, k, y...)
}
}

var s2 []int
func Benchmark_InsertVerbose(b *testing.B) {
var x = make([]int, N)
var y = make([]int, N/2)
var k = N/2
b.ResetTimer()
for i := 0; i < b.N; i++ {
s2 = InsertVerbose(x, k, y...)
}
}

var s3 []int
func Benchmark_InsertVerbose_b(b *testing.B) {
var x = make([]int, N)
var y = make([]int, N/2)
var k = N/2
b.ResetTimer()
for i := 0; i < b.N; i++ {
s3 = InsertVerbose_b(x, k, y...)
}
}

var s4 []int
func Benchmark_InsertVerbose_c(b *testing.B) {
var x = make([]int, N)
var y = make([]int, N/2)
var k = N/2
b.ResetTimer()
for i := 0; i < b.N; i++ {
s4 = InsertVerbose_c(x, k, y...)
}
}


The result:

$ go test -bench=. -benchtime=3s
 N = 1615119
goos: linux
goarch: amd64
pkg: a.y/bench/sliceinsert
cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
Benchmark_InsertOneline-4693   4741509 ns/op
Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
Benchmark_InsertVerbose-4764   4627334 ns/op
Benchmark_InsertVerbose_b-4  769   4958537 ns/op
Benchmark_InsertVerbose_c-4  661   4855514 ns/op

-- 
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/a6c251ac-02dd-40f6-895d-aa55e11a55c6n%40googlegroups.com.

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

Sorry, there is a temp tweak, the N/5 should be N/2.
The second conclusion should be:

// And if N is odd number, the InsertOneline
// implementations are about 10% faster than the others.

On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

-- 
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/41c4d250-dccf-4560-8d60-7e255fadea06n%40googlegroups.com.

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

Your benchmark exactly reproduced both of my observations.
On Saturday, May 15, 2021 at 9:15:21 AM UTC-4 Brian Candler wrote:

> With go version go1.16.3 darwin/amd64 (macOS 10.14.6), and after changing 
> N/5 to N/2, I can't reproduce either.
>
> $ go test . -bench=. -benchtime=3s
>  N = 1615119
> goos: darwin
> goarch: amd64
> pkg: bm
> cpu: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
> Benchmark_InsertOneline-4 8674130473 ns/op
> Benchmark_InsertOneline_Disassemble-4 8484161459 ns/op
> Benchmark_InsertVerbose-4 6964988955 ns/op
> Benchmark_InsertVerbose_b-4   7124882270 ns/op
> Benchmark_InsertVerbose_c-4   7024876656 ns/op
> PASS
> ok  bm 23.058s
>
> InsertOneline_Disassemble-4 is about 0.75% slower than InsertOneline-4, 
> and both are significantly faster than the others.
>
> On Friday, 14 May 2021 at 23:49:16 UTC+1 peterGo wrote:
>
>> My results:
>>
>> https://play.golang.org/p/o2cGAcpNMkX
>>
>> I can't reproduce your results.
>>
>> Peter
>>
>
>> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>>
>
>>> package main
>>>
>>> import "testing"
>>>
>>> const N = 1615119
>>> // It is strange that if N is large enough,
>>> // the one line implementations are fast as the others.
>>> // And if N is odd number, the InsertOneline_Disassemble
>>> // implementation is about 10% faster than the others.
>>>
>>> func init() {
>>> println(" N =", N)
>>> }
>>>
>>> func InsertOneline(s []int, k int, vs ...int) []int {
>>> return append(s[:k], append(vs, s[k:]...)...)
>>> }
>>>
>>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>>> z := append(vs, s[k:]...)
>>> return append(s[:k], z...)
>>> }
>>>
>>> func InsertVerbose(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, len(s) + len(vs))
>>> copy(s2, s[:k])
>>> copy(s2[k:], vs)
>>> copy(s2[k+len(vs):], s[k:])
>>> return s2
>>> }
>>>
>>>
>>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := make([]int, 0, len(s) + len(vs))
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>>> if n := len(s) + len(vs); n <= cap(s) {
>>> s2 := s[:n]
>>> copy(s2[k+len(vs):], s[k:])
>>> copy(s2[k:], vs)
>>> return s2
>>> }
>>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>>> s2 = append(s2, s[:k]...)
>>> s2 = append(s2, vs...)
>>> s2 = append(s2, s[k:]...)
>>> return s2
>>> }
>>>
>>> var s1 []int
>>> func Benchmark_InsertOneline(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/5
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1 = InsertOneline(x, k, y...)
>>> }
>>> }
>>>
>>> var s1b []int
>>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s1b = InsertOneline_Disassemble(x, k, y...)
>>> }
>>> }
>>>
>>> var s2 []int
>>> func Benchmark_InsertVerbose(b *testing.B) {
>>> var x = make([]int, N)
>>> var y = make([]int, N/2)
>>> var k = N/2
>>> b.ResetTimer()
>>> for i := 0; i < b.N; i++ {
>>> s2 = InsertVerbose(x, k, y...)
>>> }
>>> }
>>>
>>> var s3 []int
>&

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

> you don't provide the Go version,

My Go version is Go 1.16.3. (BTW, "go test" really should print Go version 
in the first line).

> you don't provide memory allocation statistics,

There are no surprises in memory allocation statistics so I didn't mention 
them.

> you only provide results for a single data point.

There are no surprises for small Ns. So I I didn't provide the results for 
them.

> I am unable reproduce your result.

At least, you exactly reproduced my first observation: if N is large 
enough, the one line implementations are fast as the others.

And you partially reproduced my second observation: the InsertOneline 
implementations 
run faster for odd Ns than even Ns for large Ns.


On Saturday, May 15, 2021 at 11:49:38 AM UTC-4 peterGo wrote:

> For your sliceinsert microbenchmarks, you don't provide the Go version, 
> you don't provide memory allocation statistics, and you only provide 
> results for a single data point.
>
> My results for several values of N:
>
> https://play.golang.org/p/WuKmIy_jY20
>
> There are significant differences in CPU performance for different values 
> of N, ranging from 1:1 to 2:1 for append versus precise implementations.
>
> I am unable reproduce your result.
>
> Peter
>
> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> package main
>>
>> import "testing"
>>
>> const N = 1615119
>> // It is strange that if N is large enough,
>> // the one line implementations are fast as the others.
>> // And if N is odd number, the InsertOneline_Disassemble
>> // implementation is about 10% faster than the others.
>>
>> func init() {
>> println(" N =", N)
>> }
>>
>> func InsertOneline(s []int, k int, vs ...int) []int {
>> return append(s[:k], append(vs, s[k:]...)...)
>> }
>>
>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>> z := append(vs, s[k:]...)
>> return append(s[:k], z...)
>> }
>>
>> func InsertVerbose(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, len(s) + len(vs))
>> copy(s2, s[:k])
>> copy(s2[k:], vs)
>> copy(s2[k+len(vs):], s[k:])
>> return s2
>> }
>>
>>
>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, 0, len(s) + len(vs))
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> var s1 []int
>> func Benchmark_InsertOneline(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/5
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1 = InsertOneline(x, k, y...)
>> }
>> }
>>
>> var s1b []int
>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1b = InsertOneline_Disassemble(x, k, y...)
>> }
>> }
>>
>> var s2 []int
>> func Benchmark_InsertVerbose(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s2 = InsertVerbose(x, k, y...)
>> }
>> }
>>
>> var s3 []int
>> func Benchmark_InsertVerbose_b(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s3 = InsertVerbose_b(x, k, y.

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

On Sunday, May 16, 2021 at 4:46:44 AM UTC-4 Brian Candler wrote:

> On Sunday, 16 May 2021 at 08:07:17 UTC+1 tapi...@gmail.com wrote:
>
>> > you don't provide memory allocation statistics,
>>
>> There are no surprises in memory allocation statistics so I didn't 
>> mention them.
>>
>>
> I think it is relevant, because your different functions return slices of 
> different capacity (i.e. different amounts of memory allocated):
> https://play.golang.org/p/3IQzd6J1ADa
>
> The only functions which allocate exactly the right size of slice are 
> InsertVerbose and InsertVerbose_b.  The others rely on append(), and when 
> that exceeds the size of the current slice and has to allocate a new one, 
> it allocates a bit extra space for growing room.
>
> Therefore, you could be measuring boundary conditions around the size that 
> append() decides to round your slice up to, combined with amount of garbage 
> collection overhead for large values of N.
>
> Aside: larger values like N = 1615119 end up with SIGKILL in the 
> playground - presumably using too much memory - but run locally:
>
>  N = 1615119
> InsertOneline: cap=2524160
> InsertOneline_Disassemble: cap=2524160
> InsertVerbose: cap=2422678
> InsertVerbose_b: cap=2422678
> InsertVerbose_c: cap=2422784
>

I'm aware of this. So I expect that the append implementations (especially 
the one-line ones) should be slower than InsertVerbose and InsertVerbose_b.
This is just a small reason why the one-line implementations should be 
slower. The main reason is they both allocate twice.

The expectation is promised from small Ns, but the benchmarks show it is 
broken for large Ns.
 

-- 
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/29b99aae-2041-48a9-824c-f58fcd05ae02n%40googlegroups.com.

[go-nuts] When will the stack of a goroutine shrink?

[tapi...@gmail.com]

>From the outputs of the following program,
it looks the stack of a goroutine doesn't shrink immediately.
Will it shrink at some point eventually?


package main

func f(i int) byte {
type T int // avoid f being inline
var a [1<<20]byte // make stack grow
return a[i]
}

func main(){
var x int
println(&x) // 0xc34770
f(100)
println(&x) // 0xc0002fff70

// It looks the stack hasn't shrunk here.

f(100)
println(&x) // 0xc0002fff70
}

-- 
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/40caa90b-84b3-45e1-bdc6-0f0a33bf06d5n%40googlegroups.com.

[go-nuts] On tip, arguments of panic escape to heap

[tapi...@gmail.com]

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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/936dcc57-c507-402e-9811-4216c5d0f694n%40googlegroups.com.

Re: [go-nuts] When will the stack of a goroutine shrink?

[tapi...@gmail.com]

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 some point eventually?
> >
> >
> > package main
> >
> > func f(i int) byte {
> > type T int // avoid f being inline
> > var a [1<<20]byte // make stack grow
> > return a[i]
> > }
> >
> > func main(){
> > var x int
> > println(&x) // 0xc34770
> > f(100)
> > println(&x) // 0xc0002fff70
> >
> > // It looks the stack hasn't shrunk here.
> >
> > f(100)
> > println(&x) // 0xc0002fff70
> > }
>
> Stack shrinking occurs during garbage collection, and only if the
> goroutine isn't doing anything and isn't sitting in a system call or a
> cgo call.
>
> Ian
>

-- 
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/cbf3fb87-13ed-44e8-96db-e7e8c608f96bn%40googlegroups.com.

Re: [go-nuts] On tip, arguments of panic escape to heap

[tapi...@gmail.com]

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.com  
> wrote:
>
>> 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 golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/936dcc57-c507-402e-9811-4216c5d0f694n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/936dcc57-c507-402e-9811-4216c5d0f694n%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/2c07b172-6c29-4a7e-8c35-0f84cfa6f8e2n%40googlegroups.com.

[go-nuts] Is the escape analysis reports accurate?

[tapi...@gmail.com]

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])
}

-- 
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/0ef15402-2e71-4522-bf67-26f766da55e5n%40googlegroups.com.

[go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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

}

func g() []T {
var ts = make([]T, N) // make([]T, N) escapes to heap
return ts
}

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])
> }
>

-- 
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/0f563565-42a0-40db-b513-50e9d0dd6fb3n%40googlegroups.com.

Re: [go-nuts] Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 Sunday, May 23, 2021 at 5:03:02 AM UTC-4 axel.wa...@googlemail.com wrote:

> 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 always escapes. I assume the 
> heuristic marks it as escaping because `n` is a non-local variable, so it 
> doesn't prove that `n` is effectively constant. It might even just mark 
> every `make` with a `var` argument as escaping.
>
> 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"?
>>
>> 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])
>> }
>>
>> -- 
>> 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/0ef15402-2e71-4522-bf67-26f766da55e5n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0ef15402-2e71-4522-bf67-26f766da55e5n%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/a44f78ab-2c10-475d-aeeb-1eef8cb8e412n%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 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 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/7a616c14-eeba-420a-ad51-b229fbd70f27n%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 return 
> does not escape. But if you only analyse `g` as-is, you must assume that 
> the return has to escape, as you don't know what the caller would do with 
> is.
>

I also think so. It looks the message "make([]T, N) escapes to heap" in g 
means "make([]T, N)" will escape to heap if g is not inlined.
 

>  
>
>>
>> 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])
>>     
>> }
>>
>> func g() []T {
>> var ts = make([]T, N) // make([]T, N) escapes to heap
>> return ts
>> }
>>
>> 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])
>>> }
>>>
>> -- 
>>
> 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/0f563565-42a0-40db-b513-50e9d0dd6fb3n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/0f563565-42a0-40db-b513-50e9d0dd6fb3n%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/30ba487b-a227-4ba8-a67f-a0c2590143f1n%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 explain that. 
>
> I noted before that the code is different. Yes, the different code 
> shares the same single line. That means nothing. Different code, 
> different outcome. It would be unexpected iff the outcome would be 
> different for the same, not different code. 
>
> Hint: When a slice is created in a function _and_ is returned as a 
> result of that function, it's backing array must escape - in the first 
> approximation at least. 
>

I just try to confirm whether or not g will allocated on heap. I think It 
will not if g is inlined. But it will otherwise.

-- 
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/1919c9bc-c7c6-4b57-9fe4-087dbad3d47fn%40googlegroups.com.

[go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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.
 

-- 
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/96efbf2d-b7cf-4325-847d-8e062906dc7dn%40googlegroups.com.

[go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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+unsubscr...@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.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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  
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b78084a6-518a--ab04-f0fd4c095a9an%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 be 
> perfect, but the only "unreasonable" imperfection would be, if it would put 
> things on the stack which don't belong there. Any "the heuristic is not 
> good enough to prove that it doesn't have to go on the heap" is, absent 
> evidence of the opposite, a reasonable imperfection.
>
> That being said, maybe someone can give a good reason as to why large 
> values shouldn't always live on the stack. To me, that seems pretty natural 
> - we 
>

I don't argue whether or not large values shouldn't always live on the 
stack is a good idea. I think the current implementation is some 
unreasonable for its inconsistency. If large values shoudn't live on stack, 
then make all large values not live one stack. The current implementation 
put some large values on stack, but others not, whereas all these large 
values could be safely put on stack.
 

> generally want the stack to be relatively small (because we might need to 
> have a lot of them) and we don't want it to grow in large steps (because 
> then we might have to repeatedly grow/shrink them, when a function is 
> called in a loop). And to me, slices and arrays seem naturally different - 
> one is just a chunk of memory, the other is such a chunk of memory and a 
> header containing a pointer to it. I agree that it's *probably* possible to 
> either also have large arrays escape or also have large slices live on the 
> stack - depending on what's more efficient. But I'm not enough of an expert 
> to answer that.
>

Whether or not there is a header is also not the absolute criterion used in 
the current implementation. This is another inconsistency.
Some values with header are allocated on stack, but some others are on 
heap, whereas all of them are safely to be put on stack.

The criterions used in the current implementation are large values with 
headers are put on heap.
I don't try to make criticisms here. I just seek a reasonable explanation 
for this implementation.
 

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

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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

Yes. I don't expect there must be an answer. I just show some weird things. 
Maybe the info is helpful for someone. ;D
 

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

[go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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 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 example,
>
> https://play.golang.org/p/3Cst23vNkKI
>
> $ go version
> go version devel go1.17-cca23a7373 Sat May 22 00:51:17 2021 + 
> linux/amd64
> $ go run -gcflags='-m -m' tl.2.go
> ./tl.2.go:18:6: can inline g with cost 8 as: func() []T { var ts []T; ts = 
> make([]T, N); return ts }
> ./tl.2.go:9:6: can inline main with cost 28 as: func() { var r []T; r = 
> make([]T, N); println(r[i]); var r1 []T; r1 = g(); println(r1[i]) }
> ./tl.2.go:13:15: inlining call to g func() []T { var ts []T; ts = 
> make([]T, N); return ts }
> ./tl.2.go:10:17: make([]T, N) does not escape
> ./tl.2.go:13:15: make([]T, N) does not escape
> ./tl.2.go:19:18: make([]T, N) escapes to heap:
> ./tl.2.go:19:18:   flow: ts = &{storage for make([]T, N)}:
> ./tl.2.go:19:18: from make([]T, N) (spill) at ./tl.2.go:19:18
> ./tl.2.go:19:18: from ts = make([]T, N) (assign) at ./tl.2.go:19:9
> ./tl.2.go:19:18:   flow: ~r0 = ts:
> ./tl.2.go:19:18: from return ts (return) at ./tl.2.go:20:5
> ./tl.2.go:19:18: make([]T, N) escapes to heap
>
>
> On Sunday, May 23, 2021 at 5:01:38 AM UTC-4 tapi...@gmail.com wrote:
>
>> 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])
>> 
>> }
>>
>> func g() []T {
>> var ts = make([]T, N) // make([]T, N) escapes to heap
>> return ts
>> }
>>
>> 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])
>>> }
>>>
>>

-- 
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/34565fef-a650-4790-8ad2-93fa527e9281n%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

After some profiling investigations, it looks the following code has not 
been optimized yet:

s2 := make([]int, len(s) + len(vs))
copy(s2, s[:k])
copy(s2[k:], vs)
copy(s2[k+len(vs):], s[k:])

Much unnecessary time is consumed on memclrNoHeapPointers.

The one-line implementation does move more memory, but this disadvantage is 
compensated by its advantage of spending less time on memclrNoHeapPointers 
when N is large.

On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> const N = 1615119
> // It is strange that if N is large enough,
> // the one line implementations are fast as the others.
> // And if N is odd number, the InsertOneline_Disassemble
> // implementation is about 10% faster than the others.
>
> func init() {
> println(" N =", N)
> }
>
> func InsertOneline(s []int, k int, vs ...int) []int {
> return append(s[:k], append(vs, s[k:]...)...)
> }
>
> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
> z := append(vs, s[k:]...)
> return append(s[:k], z...)
> }
>
> func InsertVerbose(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, len(s) + len(vs))
> copy(s2, s[:k])
> copy(s2[k:], vs)
> copy(s2[k+len(vs):], s[k:])
> return s2
> }
>
>
> func InsertVerbose_b(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := make([]int, 0, len(s) + len(vs))
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> func InsertVerbose_c(s []int, k int, vs ...int) []int {
> if n := len(s) + len(vs); n <= cap(s) {
> s2 := s[:n]
> copy(s2[k+len(vs):], s[k:])
> copy(s2[k:], vs)
> return s2
> }
> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
> s2 = append(s2, s[:k]...)
> s2 = append(s2, vs...)
> s2 = append(s2, s[k:]...)
> return s2
> }
>
> var s1 []int
> func Benchmark_InsertOneline(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/5
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1 = InsertOneline(x, k, y...)
> }
> }
>
> var s1b []int
> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s1b = InsertOneline_Disassemble(x, k, y...)
> }
> }
>
> var s2 []int
> func Benchmark_InsertVerbose(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s2 = InsertVerbose(x, k, y...)
> }
> }
>
> var s3 []int
> func Benchmark_InsertVerbose_b(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s3 = InsertVerbose_b(x, k, y...)
> }
> }
>
> var s4 []int
> func Benchmark_InsertVerbose_c(b *testing.B) {
> var x = make([]int, N)
> var y = make([]int, N/2)
> var k = N/2
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> s4 = InsertVerbose_c(x, k, y...)
> }
> }
>
>
> The result:
>
> $ go test -bench=. -benchtime=3s
>  N = 1615119
> goos: linux
> goarch: amd64
> pkg: a.y/bench/sliceinsert
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> Benchmark_InsertOneline-4693   4741509 ns/op
> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
> Benchmark_InsertVerbose-4764   4627334 ns/op
> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>

-- 
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/0aadf46a-e432-417c-8839-cfdfe24d8375n%40googlegroups.com.

[go-nuts] Re: Strange benchmark results

[tapi...@gmail.com]

The profiling results constantly show that more time are spent on 
memclrNoHeapPointers if N is a big even integer (1615118) than a big odd 
integer (1615119).


On Thursday, May 13, 2021 at 5:07:49 AM UTC-4 tapi...@gmail.com wrote:

> Sorry, there is a temp tweak, the N/5 should be N/2.
> The second conclusion should be:
>
> // And if N is odd number, the InsertOneline
> // implementations are about 10% faster than the others.
>
> On Thursday, May 13, 2021 at 4:52:32 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> package main
>>
>> import "testing"
>>
>> const N = 1615119
>> // It is strange that if N is large enough,
>> // the one line implementations are fast as the others.
>> // And if N is odd number, the InsertOneline_Disassemble
>> // implementation is about 10% faster than the others.
>>
>> func init() {
>> println(" N =", N)
>> }
>>
>> func InsertOneline(s []int, k int, vs ...int) []int {
>> return append(s[:k], append(vs, s[k:]...)...)
>> }
>>
>> func InsertOneline_Disassemble(s []int, k int, vs ...int) []int {
>> z := append(vs, s[k:]...)
>> return append(s[:k], z...)
>> }
>>
>> func InsertVerbose(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, len(s) + len(vs))
>> copy(s2, s[:k])
>> copy(s2[k:], vs)
>> copy(s2[k+len(vs):], s[k:])
>> return s2
>> }
>>
>>
>> func InsertVerbose_b(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := make([]int, 0, len(s) + len(vs))
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> func InsertVerbose_c(s []int, k int, vs ...int) []int {
>> if n := len(s) + len(vs); n <= cap(s) {
>> s2 := s[:n]
>> copy(s2[k+len(vs):], s[k:])
>> copy(s2[k:], vs)
>> return s2
>> }
>> s2 := append([]int(nil), make([]int, len(s) + len(vs))...)[:0]
>> s2 = append(s2, s[:k]...)
>> s2 = append(s2, vs...)
>> s2 = append(s2, s[k:]...)
>> return s2
>> }
>>
>> var s1 []int
>> func Benchmark_InsertOneline(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/5
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1 = InsertOneline(x, k, y...)
>> }
>> }
>>
>> var s1b []int
>> func Benchmark_InsertOneline_Disassemble(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s1b = InsertOneline_Disassemble(x, k, y...)
>> }
>> }
>>
>> var s2 []int
>> func Benchmark_InsertVerbose(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s2 = InsertVerbose(x, k, y...)
>> }
>> }
>>
>> var s3 []int
>> func Benchmark_InsertVerbose_b(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s3 = InsertVerbose_b(x, k, y...)
>> }
>> }
>>
>> var s4 []int
>> func Benchmark_InsertVerbose_c(b *testing.B) {
>> var x = make([]int, N)
>> var y = make([]int, N/2)
>> var k = N/2
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> s4 = InsertVerbose_c(x, k, y...)
>> }
>> }
>>
>>
>> The result:
>>
>> $ go test -bench=. -benchtime=3s
>>  N = 1615119
>> goos: linux
>> goarch: amd64
>> pkg: a.y/bench/sliceinsert
>> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
>> Benchmark_InsertOneline-4693   4741509 ns/op
>> Benchmark_InsertOneline_Disassemble-4871   4194142 ns/op
>> Benchmark_InsertVerbose-4764   4627334 ns/op
>> Benchmark_InsertVerbose_b-4  769   4958537 ns/op
>> Benchmark_InsertVerbose_c-4  661   4855514 ns/op
>>
>

-- 
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/4abb4cce-55d5-4ec5-b1ce-8c65c647beaen%40googlegroups.com.

Re: [go-nuts] Re: Is the escape analysis reports accurate?

[tapi...@gmail.com]

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

Re: [go-nuts] parameter name a of fmt package

[tapi...@gmail.com]

On Tuesday, May 25, 2021 at 6:14:24 AM UTC-4 Delta Echo wrote:

> > It's a parameter name. ...interface{} is the type of that argument,
> variadic in this case indicated by the ellipsis.
>
> You misunderstood my question.
>
> My question was what does `a` refers to?
>
> Like,
> fd - file descriptor
> ptr - pointer
>

I think it means "any" , any values.

-- 
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/a48010e3-ab3d-4da2-b24e-546d713b971bn%40googlegroups.com.

[go-nuts] Value copy costs are not very predictable.

[tapi...@gmail.com]

The benchmark code: https://play.golang.org/p/bC1zO14eNeh

The result:

$ go test -bench=. 
goos: linux
goarch: amd64
pkg: example.com/valuecopy
cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Benchmark_CopyBool-410 0.8885 ns/op
Benchmark_CopyByte-410 0.8872 ns/op
Benchmark_CopyInt16-4   10 0.8785 ns/op
Benchmark_CopyInt32-4   10 0.8854 ns/op
Benchmark_CopyInt64-4   10 0.8831 ns/op
Benchmark_CopyPointer-4 911733464 1.330 ns/op
Benchmark_CopyString-4  901249356 1.325 ns/op
Benchmark_CopySlice-4   664187247 1.765 ns/op
Benchmark_CopyArray_2_elements-410 0.8874 ns/op
Benchmark_CopyArray_3_elements-410 1.096 ns/op
Benchmark_CopyArray_4_elements-410 1.105 ns/op
Benchmark_CopyArray_5_elements-4534542524 2.202 ns/op
Benchmark_CopyArray_6_elements-4727849554 1.606 ns/op
Benchmark_CopyArray_7_elements-494692 2.649 ns/op
Benchmark_CopyArray_8_elements-4584854867 1.993 ns/op
Benchmark_CopyArray_9_elements-4389639859 3.083 ns/op
Benchmark_CopyArray_10_elements-4   267380602 4.418 ns/op
Benchmark_CopyArray_11_elements-4   242644033 4.867 ns/op
Benchmark_CopyArray_12_elements-4   268304104 4.498 ns/op
Benchmark_CopyArray_13_elements-4   8216527214.46 ns/op
Benchmark_CopyStruct_2_fields-4 10 0.5029 ns/op
Benchmark_CopyStruct_3_fields-4 671136589 1.769 ns/op
Benchmark_CopyStruct_4_fields-4 10 0.8785 ns/op
Benchmark_CopyStruct_5_fields-4 530876049 2.202 ns/op
Benchmark_CopyStruct_6_fields-4 723380257 1.581 ns/op
Benchmark_CopyStruct_7_fields-4 444619906 2.636 ns/op
Benchmark_CopyStruct_8_fields-4 588605260 1.968 ns/op
Benchmark_CopyStruct_9_fields-4 387253551 3.073 ns/op
Benchmark_CopyStruct_10_fields-4267450452 4.396 ns/op
Benchmark_CopyStruct_11_fields-4246289522 4.855 ns/op
Benchmark_CopyStruct_12_fields-4266212528 4.426 ns/op
Benchmark_CopyStruct_13_fields-4207298701 5.739 ns/op

>From the benchmark result, it looks 
* the cost of copying a [13]int value is much larger than copying a [12]int 
value.
* the cost of copying a struct{a, b, c int} value is about double of 
copying a struct{a, b, c, d int} value. 


-- 
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/79c86855-567c-4bb4-9c0f-d9cc0f133643n%40googlegroups.com.

Re: [go-nuts] Value copy costs are not very predictable.

[tapi...@gmail.com]

On Sunday, May 30, 2021 at 12:28:55 AM UTC-4 Kurtis Rader wrote:

> On Sat, May 29, 2021 at 8:50 PM tapi...@gmail.com  
> wrote:
>
>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>>
> ...
>>
> From the benchmark result, it looks 
>> * the cost of copying a [13]int value is much larger than copying a 
>> [12]int value.
>> * the cost of copying a struct{a, b, c int} value is about double of 
>> copying a struct{a, b, c, d int} value.
>>
>
> The size, and internal layout, of structs has a huge effect on these types 
> of benchmarks due to the interaction with the L1 and L2 caches and the CPU 
> architecture policies for  the management of those caches. Thus this type 
> of benchmark needs to document the CPU architecture being used and also the 
> results on other architectures. It would not be at all surprising if 
> changing the implementation to improve the results on your system resulted 
> in slower behavior on other systems.
>

I agree.

Could someone post the benchmark results on different architectures other 
than Intel(R) Core(TM) i5-3210 to make comparisons? 
 

>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/6d32d796-513f-40b6-b5d2-a1e54f4d1d25n%40googlegroups.com.

Re: [go-nuts] Value copy costs are not very predictable.

[tapi...@gmail.com]

gcflags=-S shows the code of copy 3-field and 4-field structs:

// struct{a, b, c int}
0x0034 00052 (valuecopy.go:223)MOVQ$0, "".struct3_0(SB)
0x003f 00063 (valuecopy.go:223)XORPSX0, X0
0x0042 00066 (valuecopy.go:223)MOVUPSX0, "".struct3_0+8(SB)

// struct{a, b, c, d int}
0x0034 00052 (valuecopy.go:233)XORPSX0, X0
0x0037 00055 (valuecopy.go:233)MOVUPSX0, "".struct4_0(SB)
0x003e 00062 (valuecopy.go:233)MOVUPSX0, "".struct4_0+16(SB)

I don't understand the instructions.

On Sunday, May 30, 2021 at 7:04:15 AM UTC-4 Jan Mercl wrote:

> Within the benchmark loops of the linked code a sufficiently smart 
> compiler can optimize the source values away completely and/or collapse all 
> writes to the destination values to a single write.
>
> Have you looked at the actual code the CPU executes?
>
>>
>>

-- 
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/1fa0bcb6-6fc5-4031-8708-cf9e49299d8fn%40googlegroups.com.

[go-nuts] Re: Value copy costs are not very predictable.

[tapi...@gmail.com]

It is some strange that if any of the bool/byte/int16/int64 benchmarks is 
removed in this test file https://play.golang.org/p/w29J9VhtzYH,
then the benchmark result is like:

Benchmark_CopyStruct_3_fields-4   10 0.7780 ns/op
Benchmark_CopyStruct_4_fields-4   10 0.7513 ns/op

Otherwise, it is like:

Benchmark_CopyStruct_3_fields-4   10 1.501 ns/op
Benchmark_CopyStruct_4_fields-4   10 0.7755 ns/op

In other words, it looks there is mutual interference between benchmarks.

On Saturday, May 29, 2021 at 11:49:47 PM UTC-4 tapi...@gmail.com wrote:

> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>
> The result:
>
> $ go test -bench=. 
> goos: linux
> goarch: amd64
> pkg: example.com/valuecopy
> cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
> Benchmark_CopyBool-410 0.8885 ns/op
> Benchmark_CopyByte-410 0.8872 ns/op
> Benchmark_CopyInt16-4   10 0.8785 ns/op
> Benchmark_CopyInt32-4   10 0.8854 ns/op
> Benchmark_CopyInt64-4   10 0.8831 ns/op
> Benchmark_CopyPointer-4 911733464 1.330 ns/op
> Benchmark_CopyString-4  901249356 1.325 ns/op
> Benchmark_CopySlice-4   664187247 1.765 ns/op
> Benchmark_CopyArray_2_elements-410 0.8874 ns/op
> Benchmark_CopyArray_3_elements-410 1.096 ns/op
> Benchmark_CopyArray_4_elements-410 1.105 ns/op
> Benchmark_CopyArray_5_elements-4534542524 2.202 ns/op
> Benchmark_CopyArray_6_elements-4727849554 1.606 ns/op
> Benchmark_CopyArray_7_elements-494692 2.649 ns/op
> Benchmark_CopyArray_8_elements-4584854867 1.993 ns/op
> Benchmark_CopyArray_9_elements-4389639859 3.083 ns/op
> Benchmark_CopyArray_10_elements-4   267380602 4.418 ns/op
> Benchmark_CopyArray_11_elements-4   242644033 4.867 ns/op
> Benchmark_CopyArray_12_elements-4   268304104 4.498 ns/op
> Benchmark_CopyArray_13_elements-4   8216527214.46 ns/op
> Benchmark_CopyStruct_2_fields-4 10 0.5029 ns/op
> Benchmark_CopyStruct_3_fields-4 671136589 1.769 ns/op
> Benchmark_CopyStruct_4_fields-4 10 0.8785 ns/op
> Benchmark_CopyStruct_5_fields-4 530876049 2.202 ns/op
> Benchmark_CopyStruct_6_fields-4 723380257 1.581 ns/op
> Benchmark_CopyStruct_7_fields-4 444619906 2.636 ns/op
> Benchmark_CopyStruct_8_fields-4 588605260 1.968 ns/op
> Benchmark_CopyStruct_9_fields-4 387253551 3.073 ns/op
> Benchmark_CopyStruct_10_fields-4267450452 4.396 ns/op
> Benchmark_CopyStruct_11_fields-4246289522 4.855 ns/op
> Benchmark_CopyStruct_12_fields-4266212528 4.426 ns/op
> Benchmark_CopyStruct_13_fields-4207298701 5.739 ns/op
>
> From the benchmark result, it looks 
> * the cost of copying a [13]int value is much larger than copying a 
> [12]int value.
> * the cost of copying a struct{a, b, c int} value is about double of 
> copying a struct{a, b, c, d int} value. 
>
>
>

-- 
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/f53a8f05-37a6-4c86-87c1-de9e83f381fdn%40googlegroups.com.

Re: [go-nuts] Re: Value copy costs are not very predictable.

[tapi...@gmail.com]

On Sunday, May 30, 2021 at 12:54:02 PM UTC-4 axel.wa...@googlemail.com 
wrote:

> That is very normal for micro-benchmarks on a ns scale.
>

The results are so constantly that I think it is more related to CPU cache 
and the specified directives.
 

>
> On Sun, May 30, 2021 at 6:07 PM tapi...@gmail.com  
> wrote:
>
>> It is some strange that if any of the bool/byte/int16/int64 benchmarks is 
>> removed in this test file https://play.golang.org/p/w29J9VhtzYH,
>> then the benchmark result is like:
>>
>> Benchmark_CopyStruct_3_fields-4   10 0.7780 ns/op
>> Benchmark_CopyStruct_4_fields-4   10 0.7513 ns/op
>>
>> Otherwise, it is like:
>>
>> Benchmark_CopyStruct_3_fields-4   10 1.501 ns/op
>> Benchmark_CopyStruct_4_fields-4   10 0.7755 ns/op
>>
>> In other words, it looks there is mutual interference between benchmarks.
>>
>> On Saturday, May 29, 2021 at 11:49:47 PM UTC-4 tapi...@gmail.com wrote:
>>
>>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>>>
>>> The result:
>>>
>>> $ go test -bench=. 
>>> goos: linux
>>> goarch: amd64
>>> pkg: example.com/valuecopy
>>> cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
>>> Benchmark_CopyBool-410 0.8885 
>>> ns/op
>>> Benchmark_CopyByte-410 0.8872 
>>> ns/op
>>> Benchmark_CopyInt16-4   10 0.8785 
>>> ns/op
>>> Benchmark_CopyInt32-4   10 0.8854 
>>> ns/op
>>> Benchmark_CopyInt64-4   10 0.8831 
>>> ns/op
>>> Benchmark_CopyPointer-4 911733464 1.330 ns/op
>>> Benchmark_CopyString-4  901249356 1.325 ns/op
>>> Benchmark_CopySlice-4   664187247 1.765 ns/op
>>> Benchmark_CopyArray_2_elements-410 0.8874 
>>> ns/op
>>> Benchmark_CopyArray_3_elements-410 1.096 
>>> ns/op
>>> Benchmark_CopyArray_4_elements-410 1.105 
>>> ns/op
>>> Benchmark_CopyArray_5_elements-4534542524 2.202 ns/op
>>> Benchmark_CopyArray_6_elements-4727849554 1.606 ns/op
>>> Benchmark_CopyArray_7_elements-494692 2.649 ns/op
>>> Benchmark_CopyArray_8_elements-4584854867 1.993 ns/op
>>> Benchmark_CopyArray_9_elements-4389639859 3.083 ns/op
>>> Benchmark_CopyArray_10_elements-4   267380602 4.418 ns/op
>>> Benchmark_CopyArray_11_elements-4   242644033 4.867 ns/op
>>> Benchmark_CopyArray_12_elements-4   268304104 4.498 ns/op
>>> Benchmark_CopyArray_13_elements-4   8216527214.46 ns/op
>>> Benchmark_CopyStruct_2_fields-4 10 0.5029 
>>> ns/op
>>> Benchmark_CopyStruct_3_fields-4 671136589 1.769 ns/op
>>> Benchmark_CopyStruct_4_fields-4 10 0.8785 
>>> ns/op
>>> Benchmark_CopyStruct_5_fields-4 530876049 2.202 ns/op
>>> Benchmark_CopyStruct_6_fields-4 723380257 1.581 ns/op
>>> Benchmark_CopyStruct_7_fields-4 444619906 2.636 ns/op
>>> Benchmark_CopyStruct_8_fields-4 588605260 1.968 ns/op
>>> Benchmark_CopyStruct_9_fields-4 387253551 3.073 ns/op
>>> Benchmark_CopyStruct_10_fields-4267450452 4.396 ns/op
>>> Benchmark_CopyStruct_11_fields-4246289522 4.855 ns/op
>>> Benchmark_CopyStruct_12_fields-4266212528 4.426 ns/op
>>> Benchmark_CopyStruct_13_fields-4207298701 5.739 ns/op
>>>
>>> From the benchmark result, it looks 
>>> * the cost of copying a [13]int value is much larger than copying a 
>>> [12]int value.
>>> * the cost of copying a struct{a, b, c int} value is about double of 
>>> copying a struct{a, b, c, d int} value. 
>>>
>>>
>>> -- 
>> 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/f53a8f05-37a6-4c86-87c1-de9e83f381fdn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f53a8f05-37a6-4c86-87c1-de9e83f381fdn%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/6caafbc0-66f3-4b77-ac92-6174b17ebf30n%40googlegroups.com.

Re: [go-nuts] Re: Value copy costs are not very predictable.

[tapi...@gmail.com]

On Monday, May 31, 2021 at 10:07:35 AM UTC-4 axel.wa...@googlemail.com 
wrote:

> On Mon, May 31, 2021 at 3:30 PM tapi...@gmail.com  
> wrote:
>
>> On Sunday, May 30, 2021 at 12:54:02 PM UTC-4 axel.wa...@googlemail.com 
>> wrote:
>>
>>> That is very normal for micro-benchmarks on a ns scale.
>>>
>> The results are so constantly that I think it is more related to CPU 
>> cache and the specified directives.
>>
>
> Yes that's what I meant. Given that the signal is so small (on a ns 
> scale), noise introduced by alignment and code caches and other 
> micro-architectural details becomes so large (relatively), that it's normal 
> to notice an effect in reordering or removing unrelated code.
>
> That's why they are not a good basis to base decisions on. You can't know 
> if what you're seeing is a real effect or just noise.
>

I tend to think the result is reliable, though I agree they are not a good 
basis to base decisions on,
for the performance might be different between different CPU architectures.
And it is still interesting to see the concrete CPU instructions generated 
for different situations.
For example, if the source values are moved out of the benchmark functions 
as package-level variables,
the generated instructions will become to

0x0034 00052 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQ
"".struct3_1(SB), DX
0x003b 00059 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQ
"".struct3_1+8(SB), BX
0x0042 00066 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQ
"".struct3_1+16(SB), SI
0x0049 00073 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQDX, 
"".struct3_0(SB)
0x0050 00080 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQBX, 
"".struct3_0+8(SB)
0x0057 00087 (/home/d630/Desktop/aa/t/x_test.go:11)MOVQSI, 
"".struct3_0+16(SB)

and 

0x0034 00052 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQ
"".struct4_1(SB), DX
0x003b 00059 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQ
"".struct4_1+8(SB), BX
0x0042 00066 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQ
"".struct4_1+16(SB), SI
0x0049 00073 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQ
"".struct4_1+24(SB), DI
0x0050 00080 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQDX, 
"".struct4_0(SB)
0x0057 00087 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQBX, 
"".struct4_0+8(SB)
0x005e 00094 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQSI, 
"".struct4_0+16(SB)
0x0065 00101 (/home/d630/Desktop/aa/t/x_test.go:21)MOVQDI, 
"".struct4_0+24(SB)

And the benchmark result is more predictable:

Benchmark_CopyStruct_3_fields-4   988590592 1.441 ns/op
Benchmark_CopyStruct_4_fields-4   597097029 2.590 ns/op
 

>  
>
>>  
>>
>>>
>>> On Sun, May 30, 2021 at 6:07 PM tapi...@gmail.com  
>>> wrote:
>>>
>>>> It is some strange that if any of the bool/byte/int16/int64 benchmarks 
>>>> is removed in this test file https://play.golang.org/p/w29J9VhtzYH,
>>>> then the benchmark result is like:
>>>>
>>>> Benchmark_CopyStruct_3_fields-4   10 0.7780 
>>>> ns/op
>>>> Benchmark_CopyStruct_4_fields-4   10 0.7513 
>>>> ns/op
>>>>
>>>> Otherwise, it is like:
>>>>
>>>> Benchmark_CopyStruct_3_fields-4   10 1.501 ns/op
>>>> Benchmark_CopyStruct_4_fields-4   10 0.7755 
>>>> ns/op
>>>>
>>>> In other words, it looks there is mutual interference between 
>>>> benchmarks.
>>>>
>>>> On Saturday, May 29, 2021 at 11:49:47 PM UTC-4 tapi...@gmail.com wrote:
>>>>
>>>>> The benchmark code: https://play.golang.org/p/bC1zO14eNeh
>>>>>
>>>>> The result:
>>>>>
>>>>> $ go test -bench=. 
>>>>> goos: linux
>>>>> goarch: amd64
>>>>> pkg: example.com/valuecopy
>>>>> cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
>>>>> Benchmark_CopyBool-410 0.8885 
>>>>> ns/op
>>>>> Benchmark_CopyByte-410 0.8872 
>>>>> ns/op
>>>>> Benchmark_CopyInt16-4   10 0.8785 
>>>>> ns/op
>>>>> Benchmark_CopyInt32-4   10 0.8854 
>>>>> ns/op
>>>>> Be