[go-nuts] Re: what is empty block mean in ssa.Block?

2020-08-25 Thread xie cui 
so what's dead value means? in my mind, dead value can be ignore, why we 
need to append it to b.Values?

On Tuesday, August 25, 2020 at 7:39:55 AM UTC+8 keith@gmail.com wrote:

> Empty here means has-only-dead-values. All the values still in s0 and s1 
> are known to be dead.
>
> On Monday, August 24, 2020 at 8:24:06 AM UTC-7, xie cui wrote:
>>
>>
>> https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/fuse.go#L130
>> it mention empty block here. in my knowledge, empty block would be 
>> len(b.Values) == 0, but it's not. so what 's empty block means 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/e592df28-1532-4cd0-b0fc-b346bf2d39f4n%40googlegroups.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

2020-08-25 Thread Robert Engels 
The tcp protocol allows the connection to wait for hours. Go routines stuck in 
wait do not burn CPU. Are the clients local or remote (over internet)?

> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar  
> wrote:
> 
> 
> Robert,
> 
> We will do the profiling next time we hit the issue again & see what is 
> happening.
> This was the first time we saw the issue & don't want to get rid of http2 
> advantages without making sure it's the actual culprit.
> 
> Do you think in the meanwhile we should do what the discussion below suggests 
> anyways ?
> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
> 
> 
>> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels  wrote:
>> I think it is too hard to tell with the limited information. It could be 
>> exhausted connections or it could be thrashing (the claim of high cpu)
>> 
>> I think you want to run profiling capture prior to hitting the stick state - 
>> you should be able to detect what is happening. 
>> 
>> If the referenced issue is related I would assume you should be able to 
>> connect by forcing http/1. 
>> 
>> You can also try disabling http/2 and see if your issue goes away. 
>> 
>>> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar  
>>> wrote:
>>> 
>>> Hi Robert,
>>> 
>>> Sorry I missed your earlier response.
>>> 
>>> From what we saw our UI was blocked and since everything was unresponsive
>>> we had to recover the system by sending sig abort. 
>>> 
 On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar 
  wrote:
 Looking at the no. of go routines we have does this apply to this issue ?
 https://github.com/golang/go/issues/27044
 
> On Mon, Aug 24, 2020 at 12:54 PM Robert Engels  
> wrote:
> Go routines in a waiting state should not be consuming CPU. Are you 
> certain they are not in constant transition from waiting to processing - 
> this could show up as high CPU usage while everything looks blocks. 
> 
> I would use pprof - github.com/robaho/goanalyzer might be of assistance 
> here to see the actual work being done. 
> 
>>> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar 
>>>  wrote:
>>> 
>> 
>> Hi Ian,
>> 
>> Thanks for replying. 
>> 
>> We have a go server running which handles user requests & collects data 
>> from various sources like gcp's cloud sql and big query.
>> We are using shopify's sarama library to do kafka operations.
>> 
>> There are seeing lots of go routines in waiting state for several 
>> minutes. 
>> Over the period of time around 587 goroutines have been spun up.
>> 
>> We see that two go routines are stuck on gcp big query and we are using 
>> wait groups there.
>> However, it's not clear why that would cause all other go routines to 
>> get hung & make cpu go high.
>> 
>> goroutine 3332131 [semacquire, 79 minutes]:
>> sync.runtime_Semacquire(0xc001c4fcf8)
>> /usr/local/go/src/runtime/sema.go:56 +0x42
>> sync.(*WaitGroup).Wait(0xc001c4fcf0)
>> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
>>  0xc002912c00, 0x330e1b0, 0xf, 0xc002912cf0, 0x3)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
>>  0xc002912db8, 0xc001870e68, 0x746121, 0xc0010fcaf8, 0x17)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
>>  0xc002356810, 0x24, 0x32f7b78, 0x5)
>> /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
>> created by 
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
>> /builds/fusionio/fusion/controller/stats/prefetcher.go:100 +0xd8
>> 
>> 
>> goroutine 3332149 [semacquire, 79 minutes]:
>> sync.runtime_Semacquire(0xc0015ede48)
>> /usr/local/go/src/runtime/sema.go:56 +0x42
>> sync.(*WaitGroup).Wait(0xc0015ede40)
>> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
>>  0xc00249dc00, 0x330e1b0, 0xf, 0xc00249dcf0, 0x3)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
>>  0xc00249ddb8, 0xc003200668, 0xc00407a520, 0xc003200590, 0x46ee97)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
>>  0xc002356ba0, 0x24, 0x32f7b78, 0x5)
>> /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
>

Re: [go-nuts] Go routines stuck in runtime_pollwait

2020-08-25 Thread Siddhesh Divekar 
Clients are over the internet.

On Tue, Aug 25, 2020 at 3:25 AM Robert Engels  wrote:

> The tcp protocol allows the connection to wait for hours. Go routines
> stuck in wait do not burn CPU. Are the clients local or remote (over
> internet)?
>
> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar 
> wrote:
>
> 
> Robert,
>
> We will do the profiling next time we hit the issue again & see what is
> happening.
> This was the first time we saw the issue & don't want to get rid of http2
> advantages without making sure it's the actual culprit.
>
> Do you think in the meanwhile we should do what the discussion below
> suggests anyways ?
>
> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
>
>
> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels 
> wrote:
>
>> I think it is too hard to tell with the limited information. It could be
>> exhausted connections or it could be thrashing (the claim of high cpu)
>>
>> I think you want to run profiling capture prior to hitting the stick
>> state - you should be able to detect what is happening.
>>
>> If the referenced issue is related I would assume you should be able to
>> connect by forcing http/1.
>>
>> You can also try disabling http/2 and see if your issue goes away.
>>
>> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar 
>> wrote:
>>
>> Hi Robert,
>>
>> Sorry I missed your earlier response.
>>
>> From what we saw our UI was blocked and since everything was unresponsive
>> we had to recover the system by sending sig abort.
>>
>> On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar <
>> siddhesh.dive...@gmail.com> wrote:
>>
>>> Looking at the no. of go routines we have does this apply to this issue ?
>>> https://github.com/golang/go/issues/27044
>>>
>>> On Mon, Aug 24, 2020 at 12:54 PM Robert Engels 
>>> wrote:
>>>
 Go routines in a waiting state should not be consuming CPU. Are you
 certain they are not in constant transition from waiting to processing -
 this could show up as high CPU usage while everything looks blocks.

 I would use pprof - github.com/robaho/goanalyzer might be of
 assistance here to see the actual work being done.

 On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar <
 siddhesh.dive...@gmail.com> wrote:

 
 Hi Ian,

 Thanks for replying.

 We have a go server running which handles user requests & collects data
 from various sources like gcp's cloud sql and big query.
 We are using shopify's sarama library to do kafka operations.

 There are seeing lots of go routines in waiting state for several
 minutes.
 Over the period of time around 587 goroutines have been spun up.

 We see that two go routines are stuck on gcp big query and we are using
 wait groups there.
 However, it's not clear why that would cause all other go routines to
 get hung & make cpu go high.

 goroutine 3332131 [semacquire, 79 minutes]:
 sync.runtime_Semacquire(0xc001c4fcf8)
 /usr/local/go/src/runtime/sema.go:56 +0x42
 sync.(*WaitGroup).Wait(0xc001c4fcf0)
 /usr/local/go/src/sync/waitgroup.go:130 +0x64

 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
 0xc002912c00, 0x330e1b0, 0xf, 0xc002912cf0, 0x3)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7

 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
 0xc002912db8, 0xc001870e68, 0x746121, 0xc0010fcaf8, 0x17)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d

 git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
 0xc002356810, 0x24, 0x32f7b78, 0x5)
 /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
 created by
 git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
 /builds/fusionio/fusion/controller/stats/prefetcher.go:100 +0xd8


 goroutine 3332149 [semacquire, 79 minutes]:
 sync.runtime_Semacquire(0xc0015ede48)
 /usr/local/go/src/runtime/sema.go:56 +0x42
 sync.(*WaitGroup).Wait(0xc0015ede40)
 /usr/local/go/src/sync/waitgroup.go:130 +0x64

 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
 0xc00249dc00, 0x330e1b0, 0xf, 0xc00249dcf0, 0x3)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7

 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
 0xc00249ddb8, 0xc003200668, 0xc00407a520, 0xc003200590, 0x46ee97)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d

 git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
 0xc002356ba0, 0x24, 0x32f7b78, 0x5)
 /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
 cre

Re: [go-nuts] Re: what is empty block mean in ssa.Block?

2020-08-25 Thread Keith Randall 
On Tue, Aug 25, 2020 at 3:10 AM xie cui  wrote:

> so what's dead value means? in my mind, dead value can be ignore, why we
> need to append it to b.Values?
>
>
Dead means no longer used. Their values are ignored.
We put them in b.Values so that they get cleaned up properly. See the
deadcode pass for what proper cleanup looks like.


> On Tuesday, August 25, 2020 at 7:39:55 AM UTC+8 keith@gmail.com wrote:
>
>> Empty here means has-only-dead-values. All the values still in s0 and s1
>> are known to be dead.
>>
>> On Monday, August 24, 2020 at 8:24:06 AM UTC-7, xie cui wrote:
>>>
>>>
>>> https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/fuse.go#L130
>>> it mention empty block here. in my knowledge, empty block would be
>>> len(b.Values) == 0, but it's not. so what 's empty block means here.
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/_Ic7n4d9qRo/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e592df28-1532-4cd0-b0fc-b346bf2d39f4n%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/CA%2BZMcOMeuON5v3SJRhaYrb8qQ1Kg%3D5KVuBRNCHZoAPF04fLciw%40mail.gmail.com.

[go-nuts] Re: abbreviation naming convention

2020-08-25 Thread Jamel Toms 
Is there a rationale for this? At face-value it seems purely arbitrary and 
personal preference. 

It would be nice if it just stated that in the comments as opposed 
positioning itself as if there's something inherently better about this 
naming convention.

On Wednesday, July 8, 2015 at 4:32:36 PM UTC-4 Tim K wrote:

> You are correct, that is the recommendation:
>
> See "Initialisms" section here:
> https://code.google.com/p/go-wiki/wiki/CodeReviewComments
>
> And slide 6 here:
> http://talks.golang.org/2014/names.slide#6
>
>
>
> On Wednesday, July 8, 2015 at 1:01:13 PM UTC-7, jonathan...@gmail.com 
> wrote:
>>
>> I could have sworn I read that go convention is for uppercase 
>> abbreviations as found in the stdlib like ServeHTTP and not ServeHttp but I 
>> can not find a doc anywhere. Was I imagining this?
>>
>

-- 
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/ba980968-5445-44ef-924d-87f801e00cacn%40googlegroups.com.

Re: [go-nuts] Re: abbreviation naming convention

2020-08-25 Thread Kurtis Rader 
The rationale for uppercase abbreviations in Go symbol name derives from
the english convention for writing acronyms using all uppercase letters.
For example: NASA, ASCII, LOL, etc. That provides a visual clue the "word"
is an acronym.

On Tue, Aug 25, 2020 at 10:07 AM Jamel Toms  wrote:

> Is there a rationale for this? At face-value it seems purely arbitrary and
> personal preference.
>
> It would be nice if it just stated that in the comments as opposed
> positioning itself as if there's something inherently better about this
> naming convention.
>
> On Wednesday, July 8, 2015 at 4:32:36 PM UTC-4 Tim K wrote:
>
>> You are correct, that is the recommendation:
>>
>> See "Initialisms" section here:
>> https://code.google.com/p/go-wiki/wiki/CodeReviewComments
>>
>> And slide 6 here:
>> http://talks.golang.org/2014/names.slide#6
>>
>>
>>
>> On Wednesday, July 8, 2015 at 1:01:13 PM UTC-7, jonathan...@gmail.com
>> wrote:
>>>
>>> I could have sworn I read that go convention is for uppercase
>>> abbreviations as found in the stdlib like ServeHTTP and not ServeHttp but I
>>> can not find a doc anywhere. Was I imagining this?
>>>
>> --
> 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/ba980968-5445-44ef-924d-87f801e00cacn%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/CABx2%3DD_JpV_EXOc-TQ3LJmdvrAwWOyckAQB6hW9wxSvwc-8NkQ%40mail.gmail.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

2020-08-25 Thread Robert Engels 
Are you transferring a lot of data? Are the servers non-cloud hosted? 

You could be encountering “tcp stalls”. 

> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar  
> wrote:
> 
> 
> Clients are over the internet.
> 
>> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels  wrote:
>> The tcp protocol allows the connection to wait for hours. Go routines stuck 
>> in wait do not burn CPU. Are the clients local or remote (over internet)?
>> 
 On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar 
  wrote:
 
>>> 
>>> Robert,
>>> 
>>> We will do the profiling next time we hit the issue again & see what is 
>>> happening.
>>> This was the first time we saw the issue & don't want to get rid of http2 
>>> advantages without making sure it's the actual culprit.
>>> 
>>> Do you think in the meanwhile we should do what the discussion below 
>>> suggests anyways ?
>>> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
>>> 
>>> 
 On Mon, Aug 24, 2020 at 5:37 PM Robert Engels  
 wrote:
 I think it is too hard to tell with the limited information. It could be 
 exhausted connections or it could be thrashing (the claim of high cpu)
 
 I think you want to run profiling capture prior to hitting the stick state 
 - you should be able to detect what is happening. 
 
 If the referenced issue is related I would assume you should be able to 
 connect by forcing http/1. 
 
 You can also try disabling http/2 and see if your issue goes away. 
 
> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar 
>  wrote:
> 
> Hi Robert,
> 
> Sorry I missed your earlier response.
> 
> From what we saw our UI was blocked and since everything was unresponsive
> we had to recover the system by sending sig abort. 
> 
>> On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar 
>>  wrote:
>> Looking at the no. of go routines we have does this apply to this issue ?
>> https://github.com/golang/go/issues/27044
>> 
>>> On Mon, Aug 24, 2020 at 12:54 PM Robert Engels  
>>> wrote:
>>> Go routines in a waiting state should not be consuming CPU. Are you 
>>> certain they are not in constant transition from waiting to processing 
>>> - this could show up as high CPU usage while everything looks blocks. 
>>> 
>>> I would use pprof - github.com/robaho/goanalyzer might be of assistance 
>>> here to see the actual work being done. 
>>> 
> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar 
>  wrote:
> 
 
 Hi Ian,
 
 Thanks for replying. 
 
 We have a go server running which handles user requests & collects 
 data from various sources like gcp's cloud sql and big query.
 We are using shopify's sarama library to do kafka operations.
 
 There are seeing lots of go routines in waiting state for several 
 minutes. 
 Over the period of time around 587 goroutines have been spun up.
 
 We see that two go routines are stuck on gcp big query and we are 
 using wait groups there.
 However, it's not clear why that would cause all other go routines to 
 get hung & make cpu go high.
 
 goroutine 3332131 [semacquire, 79 minutes]:
 sync.runtime_Semacquire(0xc001c4fcf8)
 /usr/local/go/src/runtime/sema.go:56 +0x42
 sync.(*WaitGroup).Wait(0xc001c4fcf0)
 /usr/local/go/src/sync/waitgroup.go:130 +0x64
 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
  0xc002912c00, 0x330e1b0, 0xf, 0xc002912cf0, 0x3)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7
 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
  0xc002912db8, 0xc001870e68, 0x746121, 0xc0010fcaf8, 0x17)
 /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d
 git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
  0xc002356810, 0x24, 0x32f7b78, 0x5)
 /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
 created by 
 git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
 /builds/fusionio/fusion/controller/stats/prefetcher.go:100 
 +0xd8
 
 
 goroutine 3332149 [semacquire, 79 minutes]:
 sync.runtime_Semacquire(0xc0015ede48)
 /usr/local/go/src/runtime/sema.go:56 +0x42
 sync.(*WaitGroup).Wait(0xc0015ede40)
 /usr/local/go/src/sync/waitgroup.go:130 +0x64
 git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
  0xc00249dc00, 0x330e1b0, 0xf, 0xc00249dcf0, 0x3)
 /builds/fusionio/fusion/controller/stats/ins

Re: [go-nuts] Go routines stuck in runtime_pollwait

2020-08-25 Thread Siddhesh Divekar 
Both servers and data sources are in the cloud.
I would not say a lot of data, it's precomputed data which shouldn't take
that long.


On Tue, Aug 25, 2020 at 11:25 AM Robert Engels 
wrote:

> Are you transferring a lot of data? Are the servers non-cloud hosted?
>
> You could be encountering “tcp stalls”.
>
> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar 
> wrote:
>
> 
> Clients are over the internet.
>
> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels 
> wrote:
>
>> The tcp protocol allows the connection to wait for hours. Go routines
>> stuck in wait do not burn CPU. Are the clients local or remote (over
>> internet)?
>>
>> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar <
>> siddhesh.dive...@gmail.com> wrote:
>>
>> 
>> Robert,
>>
>> We will do the profiling next time we hit the issue again & see what is
>> happening.
>> This was the first time we saw the issue & don't want to get rid of http2
>> advantages without making sure it's the actual culprit.
>>
>> Do you think in the meanwhile we should do what the discussion below
>> suggests anyways ?
>>
>> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
>>
>>
>> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels 
>> wrote:
>>
>>> I think it is too hard to tell with the limited information. It could be
>>> exhausted connections or it could be thrashing (the claim of high cpu)
>>>
>>> I think you want to run profiling capture prior to hitting the stick
>>> state - you should be able to detect what is happening.
>>>
>>> If the referenced issue is related I would assume you should be able to
>>> connect by forcing http/1.
>>>
>>> You can also try disabling http/2 and see if your issue goes away.
>>>
>>> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
>>> Hi Robert,
>>>
>>> Sorry I missed your earlier response.
>>>
>>> From what we saw our UI was blocked and since everything was unresponsive
>>> we had to recover the system by sending sig abort.
>>>
>>> On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
 Looking at the no. of go routines we have does this apply to this issue
 ?
 https://github.com/golang/go/issues/27044

 On Mon, Aug 24, 2020 at 12:54 PM Robert Engels 
 wrote:

> Go routines in a waiting state should not be consuming CPU. Are you
> certain they are not in constant transition from waiting to processing -
> this could show up as high CPU usage while everything looks blocks.
>
> I would use pprof - github.com/robaho/goanalyzer might be of
> assistance here to see the actual work being done.
>
> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
> 
> Hi Ian,
>
> Thanks for replying.
>
> We have a go server running which handles user requests & collects
> data from various sources like gcp's cloud sql and big query.
> We are using shopify's sarama library to do kafka operations.
>
> There are seeing lots of go routines in waiting state for several
> minutes.
> Over the period of time around 587 goroutines have been spun up.
>
> We see that two go routines are stuck on gcp big query and we are
> using wait groups there.
> However, it's not clear why that would cause all other go routines to
> get hung & make cpu go high.
>
> goroutine 3332131 [semacquire, 79 minutes]:
> sync.runtime_Semacquire(0xc001c4fcf8)
> /usr/local/go/src/runtime/sema.go:56 +0x42
> sync.(*WaitGroup).Wait(0xc001c4fcf0)
> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>
> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
> 0xc002912c00, 0x330e1b0, 0xf, 0xc002912cf0, 0x3)
> /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7
>
> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
> 0xc002912db8, 0xc001870e68, 0x746121, 0xc0010fcaf8, 0x17)
> /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d
>
> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
> 0xc002356810, 0x24, 0x32f7b78, 0x5)
> /builds/fusionio/fusion/controller/stats/prefetcher.go:77 +0xf2
> created by
> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
> /builds/fusionio/fusion/controller/stats/prefetcher.go:100
> +0xd8
>
>
> goroutine 3332149 [semacquire, 79 minutes]:
> sync.runtime_Semacquire(0xc0015ede48)
> /usr/local/go/src/runtime/sema.go:56 +0x42
> sync.(*WaitGroup).Wait(0xc0015ede40)
> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>
> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
> 0xc00249dc00, 0x330e1b0, 0xf, 0xc00249dcf0,

[go-nuts] Re: Generics and parentheses

2020-08-25 Thread Kaveh Shahbazian 
After playing in generics playground with a dozen of cases that came to my 
mind, IMHO brackets seem to be more clear than parentheses for declaring 
type parameters. Also using the type keyword before the type parameter 
reduces the cognitive load drastically.

type StateFn[type T] func(T) StateFn[T] // Good

vs:

type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous one

It's hard to say if there are any practical alternatives to brackets - 
according to the proposal. But angle brackets are not that ugly by 
themselves.

(I'm not sure if this approach is actually possible)

The hash/number signs appear in the language specifications just once:

type StateFn<#T> func(T) StateFn<#T>

And the %T syntax is used to print types:

type StateFn<%T> func(T) StateFn<%T>

Then, that problematic example would become:

a, b = w<#x,y>(z)

or:

a, b = w<%x,y>(z)

On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:

> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from

Re: [go-nuts] Re: Generics and parentheses

2020-08-25 Thread Ian Lance Taylor 
Thanks for the note.  Please see the discussion at
https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ .

Ian

On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian
 wrote:
>
> After playing in generics playground with a dozen of cases that came to my 
> mind, IMHO brackets seem to be more clear than parentheses for declaring type 
> parameters. Also using the type keyword before the type parameter reduces the 
> cognitive load drastically.
>
> type StateFn[type T] func(T) StateFn[T] // Good
>
> vs:
>
> type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous one
>
> It's hard to say if there are any practical alternatives to brackets - 
> according to the proposal. But angle brackets are not that ugly by themselves.
>
> (I'm not sure if this approach is actually possible)
>
> The hash/number signs appear in the language specifications just once:
>
> type StateFn<#T> func(T) StateFn<#T>
>
> And the %T syntax is used to print types:
>
> type StateFn<%T> func(T) StateFn<%T>
>
> Then, that problematic example would become:
>
> a, b = w<#x,y>(z)
>
> or:
>
> a, b = w<%x,y>(z)
>
> On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:
>>
>> We have received a variety of feedback on the generics draft design (blog). 
>> Thanks to everyone who took the time to read it, play with generics code in 
>> the playground, file issues, and send us their thoughts.
>>
>>
>> Not unexpectedly, many people raised concerns about the syntax, specifically 
>> the choice of parentheses for type parameter declarations and generic type 
>> and function instantiations.
>>
>>
>> A typical computer keyboard provides four easily accessible pairs of 
>> single-character symmetrical "brackets": parentheses ( and ), square 
>> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
>> curly braces to delineate code blocks, composite literals, and some 
>> composite types, making it virtually impossible to use them for generics 
>> without severe syntactic problems. Angle brackets require unbounded parser 
>> look-ahead or type information in certain situations (see the end of this 
>> e-mail for an example). This leaves us with parentheses and square brackets. 
>> Unadorned square brackets cause ambiguities in type declarations of arrays 
>> and slices, and to a lesser extent when parsing index expressions. Thus, 
>> early on in the design, we settled on parentheses as they seemed to provide 
>> a Go-like feel and appeared to have the fewest problems.
>>
>>
>> As it turned out, to make parentheses work well and for 
>> backward-compatibility, we had to introduce the type keyword in type 
>> parameter lists. Eventually, we found additional parsing ambiguities in 
>> parameter lists, composite literals, and embedded types which required more 
>> parentheses to resolve them. Still, we decided to proceed with parentheses 
>> in order to focus on the bigger design issues.
>>
>>
>> The time has come to revisit this early decision. If square brackets alone 
>> are used to declare type parameters, the array declaration
>>
>>
>> type A [N]E
>>
>>
>> cannot be distinguished from the generic type declaration
>>
>>
>> type A[N] E
>>
>>
>> But if we are comfortable with the extra type keyword, the ambiguity 
>> disappears:
>>
>>
>> type A[type N] E
>>
>>
>> (When we originally dismissed square brackets, the type keyword was not yet 
>> on the table.)
>>
>>
>> Furthermore, the ambiguities that arise with parentheses appear not to arise 
>> with square brackets. Here are some examples where extra parentheses are not 
>> needed with square brackets:
>>
>>
>> using () using []
>>
>> func f((T(int))  func f(T[int])
>>
>> struct{ (T(int)) }   struct{ T[int] }
>>
>> interface{ (T(int)) }interface{ T[int] }
>>
>> [](T(int)){} []T[int]{}
>>
>>
>> To test this better understanding, and to get a feel for this alternative 
>> notation, we will begin to make changes to our prototype implementation such 
>> that it accepts either parentheses or square brackets (only one or the 
>> other) in a generic Go package. Those changes will first appear as commits 
>> to the dev.go2go branch, and eventually in the playground.
>>
>>
>> If square brackets don't lead to unforeseen issues, we have another fully 
>> explored notation to choose from, which will allow us to make a more 
>> informed decision.
>>
>>
>> - gri, iant
>>
>>
>> PS: For ambiguities with angle brackets consider the assignment
>>
>>
>> a, b = w < x, y > (z)
>>
>>
>> Without type information, it is impossible to decide whether the right-hand 
>> side of the assignment is a pair of expressions
>>
>>
>> (w < x), (y > (z))
>>
>>
>> or whether it is a generic function invocation that returns two result values
>>
>>
>> (w)(z)
>>
>>
>> In Go, type information is not available at compile time. For instance, in 
>> this case, any of the identifiers may be declared in another file that has 
>> not even been parsed yet.
>>
>>

Re: [go-nuts] Re: abbreviation naming convention

2020-08-25 Thread Jamel Toms 
That makes sense, I never considered following that rule in code very
important. I still think it's a personal preference, but at least I
understand the rationale. It follows the spirit of Go lang with minimizing
ambiguity.

On Tue, Aug 25, 2020 at 1:27 PM Kurtis Rader  wrote:

> The rationale for uppercase abbreviations in Go symbol name derives from
> the english convention for writing acronyms using all uppercase letters.
> For example: NASA, ASCII, LOL, etc. That provides a visual clue the "word"
> is an acronym.
>
> On Tue, Aug 25, 2020 at 10:07 AM Jamel Toms  wrote:
>
>> Is there a rationale for this? At face-value it seems purely arbitrary
>> and personal preference.
>>
>> It would be nice if it just stated that in the comments as opposed
>> positioning itself as if there's something inherently better about this
>> naming convention.
>>
>> On Wednesday, July 8, 2015 at 4:32:36 PM UTC-4 Tim K wrote:
>>
>>> You are correct, that is the recommendation:
>>>
>>> See "Initialisms" section here:
>>> https://code.google.com/p/go-wiki/wiki/CodeReviewComments
>>>
>>> And slide 6 here:
>>> http://talks.golang.org/2014/names.slide#6
>>>
>>>
>>>
>>> On Wednesday, July 8, 2015 at 1:01:13 PM UTC-7, jonathan...@gmail.com
>>> wrote:

 I could have sworn I read that go convention is for uppercase
 abbreviations as found in the stdlib like ServeHTTP and not ServeHttp but I
 can not find a doc anywhere. Was I imagining this?

>>> --
>> 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/ba980968-5445-44ef-924d-87f801e00cacn%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>


-- 

Jamel Toms
jamelt...@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/CAFvUr2EJ8yh9xcWUgYtZNE8ekPqcz_7zjqzZ4AW2SBnTiN34Ew%40mail.gmail.com.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-25 Thread Kaveh Shahbazian 
I am excited about sum-types as much as generics themselves. Also, it's 
nice that any is a keyword restricted to be used inside the type parameter 
declaration as a type constraint.

Very nice!

---

P.S.
Of-course now the proposal seems to go with brackets. Nevertheless, I wrote 
this 
comment 
 on 
the possibility of using angle brackets for the type parameter declaration. 
Maybe that way there are more symbols in the language. But they will be 
less overloaded with (completely) different semantics - assuming it's a 
practical approach.

On Tuesday, August 25, 2020 at 12:35:33 AM UTC+2 Ian Lance Taylor wrote:

> On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor  wrote:
> >
> > Our intent here is that "any" will be available for all code. Yes, we
> > wouldn't do it if it weren't for its use as a type constraint. But if
> > we are going to do it for type constraints, there seems to be little
> > benefit to restricting it to only work as a type constraint.
> >
> > This is not, of course, a new idea, even in the absence of generics.
> > For example, https://golang.org/issue/33232. (My comment there was
> > that we would use interface{} less if we had generics, but of course
> > when we require type constraints then we actually wind up using it
> > somewhat more.)
>
> I've seen objections that a language change for generics should not
> implicitly pull in a change to non-generic code. That seems fair. It
> may be the right thing to do, but it should be justified separately.
> So we're going to start with "any" only being accepted as a type
> constraint, and we can discuss making the name available for all uses
> separately, probably on issue 33232. Clearly adding "any" as a name
> accepted in type constraints is a step toward defining "any" for all
> code, but doing so isn't a requirement for generics.
>
> 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/952eec35-ddab-400b-b860-24e8289da17bn%40googlegroups.com.

[go-nuts] Wasm test code, how to use syscall/js to create a document when invoked in node.js

2020-08-25 Thread John 
I am using the following to run wasm tests:

GOOS=js GOARCH=wasm go test -exec "node $(go env GOROOT)/misc/wasm/wasm_exec

Because I'm in a node environment, the Global().Get("document") is empty.

I need to be able to populate that with the correct document object so I 
can test DOM manipulation.  However, I am not sure how to do this.  The 
document needs to be some specific object type and not a string 
representing the page,  which I could achieve with .Set(string).

In javascript, I believe you can do:
document.implementation.createHTMLDocument()

Anyone know if this is possible to do from syscall/js and if so how to do 
this?

Thanks!

-- 
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/89fae903-8933-49b2-8418-4d711bae7c0dn%40googlegroups.com.

[go-nuts] instruction gen in amd64, it iseems not the best choice?

2020-08-25 Thread xie cui 
function:
func test3(a int) int {
  return a * 3 + 4
}

go version go1.13.5 darwin/amd64
generate instructions:
  LEAQ(AX)(AX*2), AX
  LEAQ4(AX), AX

As far as i known，there a better choice
 LEAQ4(AX*3), AX

Can it be optimized?

-- 
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/5b1a4e3b-047b-4ffa-a255-208b0ff23579n%40googlegroups.com.

[go-nuts] Re: instruction gen in amd64, it iseems not the best choice?

2020-08-25 Thread peterGo 
Go has optimizing compilers and linkers which are constantly being improved.

The following example of your program reduces the call to test3 to

MOVQ $0x82, 0(SP)

where 0x82 = 130 = 42 * 3 + 4

$ cat xiecui.go
package main

func test3(a int) int {
return a*3 + 4
}

func main() {
a := 42
t := test3(a)
println(t)
}

$ go version
go version devel +758ac371ab Tue Aug 25 21:15:43 2020 + linux/amd64

$ go build xiecui.go

$ ./xiecui
130

$ go tool compile -S xiecui.go > xiecui.compile

"".test3 STEXT nosplit size=19 args=0x10 locals=0x0 funcid=0x0
0x 0 (xiecui.go:3)TEXT"".test3(SB), 
NOSPLIT|ABIInternal, $0-16
0x 0 (xiecui.go:3)FUNCDATA$0, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (xiecui.go:3)FUNCDATA$1, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x 0 (xiecui.go:4)MOVQ"".a+8(SP), AX
0x0005 5 (xiecui.go:4)LEAQ(AX)(AX*2), AX
0x0009 9 (xiecui.go:4)LEAQ4(AX), AX
0x000d 00013 (xiecui.go:4)MOVQAX, "".~r1+16(SP)
0x0012 00018 (xiecui.go:4)RET
"".main STEXT size=77 args=0x0 locals=0x10 funcid=0x0
0x 0 (xiecui.go:7)TEXT"".main(SB), ABIInternal, $16-0
0x 0 (xiecui.go:7)MOVQ(TLS), CX
0x0009 9 (xiecui.go:7)CMPQSP, 16(CX)
0x000d 00013 (xiecui.go:7)PCDATA$0, $-2
0x000d 00013 (xiecui.go:7)JLS70
0x000f 00015 (xiecui.go:7)PCDATA$0, $-1
0x000f 00015 (xiecui.go:7)SUBQ$16, SP
0x0013 00019 (xiecui.go:7)MOVQBP, 8(SP)
0x0018 00024 (xiecui.go:7)LEAQ8(SP), BP
0x001d 00029 (xiecui.go:7)FUNCDATA$0, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x001d 00029 (xiecui.go:7)FUNCDATA$1, 
gclocals·33cdeebe80329f1fdbee7f5874cb(SB)
0x001d 00029 (xiecui.go:10)PCDATA$1, $0
0x001d 00029 (xiecui.go:10)NOP
0x0020 00032 (xiecui.go:10)CALLruntime.printlock(SB)
0x0025 00037 (xiecui.go:10)MOVQ$130, (SP)
0x002d 00045 (xiecui.go:10)CALLruntime.printint(SB)
0x0032 00050 (xiecui.go:10)CALLruntime.printnl(SB)
0x0037 00055 (xiecui.go:10)CALLruntime.printunlock(SB)
0x003c 00060 (xiecui.go:11)MOVQ8(SP), BP
0x0041 00065 (xiecui.go:11)ADDQ$16, SP
0x0045 00069 (xiecui.go:11)RET
0x0046 00070 (xiecui.go:11)NOP
0x0046 00070 (xiecui.go:7)PCDATA$1, $-1
0x0046 00070 (xiecui.go:7)PCDATA$0, $-2
0x0046 00070 (xiecui.go:7)CALLruntime.morestack_noctxt(SB)
0x004b 00075 (xiecui.go:7)PCDATA$0, $-1
0x004b 00075 (xiecui.go:7)JMP0

$ go tool objdump xiecui > xiecui.objdump

TEXT main.main(SB) /home/peter/Sync/gopath/mod/nuts/xiecui.go
  xiecui.go:70x45cc8064488b0c25f8ffMOVQ 
FS:0xfff8, CX
  xiecui.go:70x45cc89483b6110CMPQ 0x10(CX), SP

  xiecui.go:70x45cc8d7637JBE 0x45ccc6

  xiecui.go:70x45cc8f4883ec10SUBQ $0x10, SP

  xiecui.go:70x45cc9348896c2408MOVQ BP, 0x8(SP)

  xiecui.go:70x45cc98488d6c2408LEAQ 0x8(SP), BP

  xiecui.go:100x45cc9d0f1f00NOPL 0(AX)

  xiecui.go:100x45cca0e89b17fdffCALL 
runtime.printlock(SB)
  xiecui.go:100x45cca548c704248200MOVQ $0x82, 
0(SP)
  xiecui.go:100x45ccade8ae1ffdffCALL 
runtime.printint(SB)
  xiecui.go:100x45ccb2e8491afdffCALL 
runtime.printnl(SB)
  xiecui.go:100x45ccb7e80418fdffCALL 
runtime.printunlock(SB)
  xiecui.go:110x45ccbc488b6c2408MOVQ 0x8(SP), BP

  xiecui.go:110x45ccc14883c410ADDQ $0x10, SP

  xiecui.go:110x45ccc5c3RET
  xiecui.go:70x45ccc6e8d5b0CALL 
runtime.morestack_noctxt(SB)
  xiecui.go:70x45cccbebb3JMP main.main(SB)

$ 

Peter

On Tuesday, August 25, 2020 at 11:04:15 PM UTC-4 cuiw...@gmail.com wrote:

> function:
> func test3(a int) int {
>   return a * 3 + 4
> }
>
> go version go1.13.5 darwin/amd64
> generate instructions:
>   LEAQ(AX)(AX*2), AX
>   LEAQ4(AX), AX
>
> As far as i known，there a better choice
>  LEAQ4(AX*3), AX
>
> Can it be optimized?
>
>

-- 
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/d7fe03e4-65bc-4221-a024-95cd9a2dbd5cn%40googlegrou

Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-25 Thread Frederik Zipp 
Ian Lance Taylor schrieb am Dienstag, 25. August 2020 um 00:35:33 UTC+2:

> I've seen objections that a language change for generics should not 
> implicitly pull in a change to non-generic code. That seems fair. It 
> may be the right thing to do, but it should be justified separately. 
> So we're going to start with "any" only being accepted as a type 
> constraint, and we can discuss making the name available for all uses 
> separately, probably on issue 33232.
>

I understand the motivation, but I hope this artificial restriction is 
eventually lifted, because I find special cases and exceptions to 
generality make a language more confusing to learn ("Why can I use this 
here but not there, even though it's referring to the same thing?"). 

-- 
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/2c13095f-ccce-43cc-9e52-f3ecd0bba733n%40googlegroups.com.