Re: [go-nuts] print* in runtime running into deadlocks
>> It ought to be impossible, because printlock increments mp.locks.
Thanks, realized it's NOT a problem with printlock/printunlock.
>> Have you seen this happen?
Not yet with normal program, but a deadlock could be produced with the
diagnostic change to mgcsweep.go (say, running ./make.bash will likely
deadlock
in go_bootstrap), turns out it involves 'mheap_.lock' and 'debuglock' when
print* triggers copystack.
The scenario may look like:
Goroutine-A: printlock -> hold 'debuglock' -> printing -> trigger copystack
-> try to allocate -> acquiring 'mheap_.lock'
Goroutine-B: hold 'mheap_.lock' -> allocating -> running into activeSweep's
diagnostics -> acquiring 'debuglock'
On Friday, February 24, 2023 at 7:47:08 AM UTC+8 Ian Lance Taylor wrote:
> On Wed, Feb 22, 2023 at 6:43 PM Xiangdong Ji wrote:
> >
> > Looks like the print* helper functions may run into deadlocks if the
> printer Goroutine is rescheduled to a different M to execute 'printunlock'
> as the "if mp.printlock==0" checking is likely to fail if M has changed.
>
> Have you seen this happen? It ought to be impossible, because
> printlock increments mp.locks. When mp.locks is not zero the M can't
> be preempted and the goroutine can't block.
>
> Ian
>
>
> > Wondering is it intentional behavior? As print* are (almostly if not
> always) used in runtime during STW or guarded by high level locks.
> >
> > I didn't figure out how to produce a deadlock by user testcase, but the
> change below could easily deadlock 'go_bootstrap' when running
> './src/make.bash'.
> >
> > A similar issue was opened in https://github.com/golang/go/issues/54786,
> but no follow-up for months.
> >
> > Thanks.
> >
> > ```
> > diff --git a/src/runtime/mgcsweep.go b/src/runtime/mgcsweep.go
> > index 6ccf090ac5..3336823dc0 100644
> > --- a/src/runtime/mgcsweep.go
> > +++ b/src/runtime/mgcsweep.go
> > @@ -155,6 +155,7 @@ func (a *activeSweep) begin() sweepLocker {
> > return sweepLocker{mheap_.sweepgen, false}
> > }
> > if a.state.CompareAndSwap(state, state+1) {
> > + println("activeSweep.begin, old:", state, ",new:", state+1)
> > return sweepLocker{mheap_.sweepgen, true}
> > }
> > }
> > @@ -172,6 +173,7 @@ func (a *activeSweep) end(sl sweepLocker) {
> > throw("mismatched begin/end of activeSweep")
> > }
> > if a.state.CompareAndSwap(state, state-1) {
> > + println("activeSweep.end, old:", state, ",new:", state-1)
> > if state != sweepDrainedMask {
> > return
> > }
> > ```
> >
> > --
> > 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/e48221e3-0709-49e1-8cbd-314044558c56n%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/be422e54-9c13-40fc-88cd-d51ffda0fc1cn%40googlegroups.com.
Re: [go-nuts] print* in runtime running into deadlocks
>> Have you seen this happen? It ought to be impossible, because
>> printlock increments mp.locks. When mp.locks is not zero the M can't
>> be preempted and the goroutine can't block.
Not yet with normal program, but a deadlock could be produced with the
diagnostic change to mgcsweep.go (say, running ./make.bash will likely
deadlock
in go_bootstrap), turns out it involves 'mheap_.lock' and 'debuglock' when
print* triggers copystack.
The scenario may look like:
Goroutine-A: printlock -> hold 'debuglock' -> printing -> trigger copystack
-> try to allocate -> acquiring 'mheap_.lock'
Goroutine-B: hold 'mheap_.lock' -> allocating -> running into activeSweep's
diagnostics -> acquiring 'debuglock'
On Friday, February 24, 2023 at 7:47:08 AM UTC+8 Ian Lance Taylor wrote:
> On Wed, Feb 22, 2023 at 6:43 PM Xiangdong Ji wrote:
> >
> > Looks like the print* helper functions may run into deadlocks if the
> printer Goroutine is rescheduled to a different M to execute 'printunlock'
> as the "if mp.printlock==0" checking is likely to fail if M has changed.
>
> Have you seen this happen? It ought to be impossible, because
> printlock increments mp.locks. When mp.locks is not zero the M can't
> be preempted and the goroutine can't block.
>
> Ian
>
>
> > Wondering is it intentional behavior? As print* are (almostly if not
> always) used in runtime during STW or guarded by high level locks.
> >
> > I didn't figure out how to produce a deadlock by user testcase, but the
> change below could easily deadlock 'go_bootstrap' when running
> './src/make.bash'.
> >
> > A similar issue was opened in https://github.com/golang/go/issues/54786,
> but no follow-up for months.
> >
> > Thanks.
> >
> > ```
> > diff --git a/src/runtime/mgcsweep.go b/src/runtime/mgcsweep.go
> > index 6ccf090ac5..3336823dc0 100644
> > --- a/src/runtime/mgcsweep.go
> > +++ b/src/runtime/mgcsweep.go
> > @@ -155,6 +155,7 @@ func (a *activeSweep) begin() sweepLocker {
> > return sweepLocker{mheap_.sweepgen, false}
> > }
> > if a.state.CompareAndSwap(state, state+1) {
> > + println("activeSweep.begin, old:", state, ",new:", state+1)
> > return sweepLocker{mheap_.sweepgen, true}
> > }
> > }
> > @@ -172,6 +173,7 @@ func (a *activeSweep) end(sl sweepLocker) {
> > throw("mismatched begin/end of activeSweep")
> > }
> > if a.state.CompareAndSwap(state, state-1) {
> > + println("activeSweep.end, old:", state, ",new:", state-1)
> > if state != sweepDrainedMask {
> > return
> > }
> > ```
> >
> > --
> > 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/e48221e3-0709-49e1-8cbd-314044558c56n%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/338c0538-8190-4bf5-b9e2-006730069812n%40googlegroups.com.
[go-nuts] print* in runtime running into deadlocks
Hi experts,
Looks like the print* helper functions may run into deadlocks if the
printer Goroutine is rescheduled to a different M to execute 'printunlock'
as the "if mp.printlock==0" checking is likely to fail if M has changed.
Wondering is it intentional behavior? As print* are (almostly if not
always) used in runtime during STW or guarded by high level locks.
I didn't figure out how to produce a deadlock by user testcase, but the
change below could easily deadlock 'go_bootstrap' when running
'./src/make.bash'.
A similar issue was opened in https://github.com/golang/go/issues/54786,
but no follow-up for months.
Thanks.
```
diff --git a/src/runtime/mgcsweep.go b/src/runtime/mgcsweep.go
index 6ccf090ac5..3336823dc0 100644
--- a/src/runtime/mgcsweep.go
+++ b/src/runtime/mgcsweep.go
@@ -155,6 +155,7 @@ func (a *activeSweep) begin() sweepLocker {
return sweepLocker{mheap_.sweepgen, false}
}
if a.state.CompareAndSwap(state, state+1) {
+ println("activeSweep.begin, old:", state, ",new:",
state+1)
return sweepLocker{mheap_.sweepgen, true}
}
}
@@ -172,6 +173,7 @@ func (a *activeSweep) end(sl sweepLocker) {
throw("mismatched begin/end of activeSweep")
}
if a.state.CompareAndSwap(state, state-1) {
+ println("activeSweep.end, old:", state, ",new:",
state-1)
if state != sweepDrainedMask {
return
}
```
--
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/e48221e3-0709-49e1-8cbd-314044558c56n%40googlegroups.com.
[go-nuts] expected number of pprof 'total samples'
Hi I wonder if the expected number of pprof 'total samples' could be calculated by: duration * sample_rate (100HZ) * CPU usage (by 'top') say if my program's CPU usage reported by 'top' is 200%, and sampling period is 30 seconds, could I expect the total samples of pprof is approximately: 30 * 100 * 2 => 6K ? The formula works well on some physical machines/docker containers, but not all of them, sometimes the samples made by pprof is only 50~60% of the expected number, that ratio is stable on a specific machine/container. Curious to know what could be the rationale behind it? 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/5f8ca229-1390-46c1-93aa-2840406122a8n%40googlegroups.com.
Re: [go-nuts] how to pass analyzer's flag with 'go vet -vettool'
Thanks Wagner. I concur that there might be a bug, or at least the documentation could CLARIFY whether analyzer's option is not supported or not, referring to the usage of 'go vet' I assume the answer would be 'no'. I tried to modify fieldalignment to turn its '-fix' option on by default, change worked as expected if running fieldalignment as a standalone utility, but no rewriting is applied when running it as a tool of 'go vet', could any expert here shed a light? Thanks. On Tuesday, April 13, 2021 at 9:50:16 AM UTC+8 wagner riffel wrote: > On Mon Apr 12, 2021 at 10:23 AM -03, Xiangdong Ji wrote: > > Hi, > > > > I'm trying to run "go vet -vettool=$(which fieldalignment) ./..." for a > > large project, and wish to turn its '-fix' option on, wondering how to > > pass > > that option? > > Hi Xiangdong, I found that surprising that even docs didn't mention > this anywhere, I also got confused by how go vet -vettool works but I > think I understood after reading the source code, after a -vettool is > specified, all flags that are not build flags should be sent to the > vettool, apparently those old tools like fieldalignemnt are broken > with the new "vet command line protocol" mentioned in the source code, > even some flags for those tools is broken, it's clear to me that > there's a bug going on here. Please also consider that possible that I > just think I understood the problem. :) > > BR. > > --wagner > > -- 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/ddc5863d-cf77-4015-91f1-b1cae4863ed8n%40googlegroups.com.
[go-nuts] how to pass analyzer's flag with 'go vet -vettool'
Hi, I'm trying to run "go vet -vettool=$(which fieldalignment) ./..." for a large project, and wish to turn its '-fix' option on, wondering how to pass that option? Any comment is highly appreciated. -- 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/3ea457d9-60da-4e39-a177-3ce0cdd93314n%40googlegroups.com.
[go-nuts] How to clean cache for 'go tool dist test'
Hi, I'm trying to run 'go tool dist test' after the binary has been built successfully, while always get a cached result, running "go clean -i -r -testcache " and "go clean -cache" in prior doesn't help, can anyone please help here? Thanks. $ go tool dist test -run=go_test:crypto/ # go tool dist test -run=^go_test:crypto/aes$ ok crypto/aes (cached) ok crypto/cipher (cached) ok crypto/des (cached) ok crypto/dsa (cached) ok crypto/ecdsa(cached) ok crypto/ed25519 (cached) ok crypto/elliptic (cached) ok crypto/hmac (cached) ok crypto/internal/subtle (cached) ok crypto/md5 (cached) ok crypto/rand (cached) ok crypto/rc4 (cached) ok crypto/rsa (cached) ok crypto/sha1 (cached) ok crypto/sha256 (cached) ok crypto/sha512 (cached) ok crypto/subtle (cached) ok crypto/tls (cached) ok crypto/x509 (cached) -- 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/6a04b76e-27e1-43bc-87af-06bd4a966216%40googlegroups.com.
Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'
Thanks Robert, I'm trying to utilize the tool now, the new output rendered by goanalyzer contains a page for PC:0 goroutines, which were discussed in #29103 <https://github.com/golang/go/issues/29103>, but seems no further details are available, are they considered irrelevant to perf. analysis? On Thursday, March 5, 2020 at 8:09:18 PM UTC+8, Robert Engels wrote: > > You might be interested in github.com/robaho/go-analyzer which I believe > significantly improves the profiling information when dealing with highly > concurrent Go programs. > > On Mar 5, 2020, at 12:13 AM, Xiangdong JI > > wrote: > > > Thanks Ian. > > I'm using schedtrace and scheddetail to help understand the scheduling > flow, the minimum monitoring window seems to be 1ms only, possible to get > more detailed info? > Furthermore, sched* outputs extensive logs but what I expect, at present, > might be something like when a goroutine is parked due to what reason, > etc., can I get it with the existing diagnostics? > > > On Thursday, March 5, 2020 at 11:24:23 AM UTC+8, Ian Lance Taylor wrote: >> >> On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI wrote: >> > >> > Given the attached screenshot of pprof output, I wonder how to figure >> out the callers of 'runtime.mcall' and their cost? Thanks. >> >> You can't, but it doesn't matter. The mcall function is used when a >> thread changes from executing one goroutine to a different goroutine. >> Knowing the code that triggers the call into mcall won't tell you >> anything. It's just where that goroutine happened to be preempted. >> >> 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 golan...@googlegroups.com . > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/71ecd07a-0b42-4eba-9b22-5c7cc9821243%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/71ecd07a-0b42-4eba-9b22-5c7cc9821243%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/5b1f728e-68c5-407e-98c6-5e366fc28e53%40googlegroups.com.
Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'
Thanks Ian. I'm using schedtrace and scheddetail to help understand the scheduling flow, the minimum monitoring window seems to be 1ms only, possible to get more detailed info? Furthermore, sched* outputs extensive logs but what I expect, at present, might be something like when a goroutine is parked due to what reason, etc., can I get it with the existing diagnostics? On Thursday, March 5, 2020 at 11:24:23 AM UTC+8, Ian Lance Taylor wrote: > > On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI > wrote: > > > > Given the attached screenshot of pprof output, I wonder how to figure > out the callers of 'runtime.mcall' and their cost? Thanks. > > You can't, but it doesn't matter. The mcall function is used when a > thread changes from executing one goroutine to a different goroutine. > Knowing the code that triggers the call into mcall won't tell you > anything. It's just where that goroutine happened to be preempted. > > 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/71ecd07a-0b42-4eba-9b22-5c7cc9821243%40googlegroups.com.
[go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'
Hi, Given the attached screenshot of pprof output, I wonder how to figure out the callers of 'runtime.mcall' and their cost? Thanks. (The image is generated by profiling BenchmarkGoroutineBlocking). [image: Capture.JPG] -- 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/b0ac497f-ae50-4033-b970-d35c02350df3%40googlegroups.com.
[go-nuts] Re: How to reduce the fluctuation of micro benchmark results
Thanks for the replying, tried -benchtime=Nx and the results appeared a little stable now. On Wednesday, January 8, 2020 at 10:19:25 AM UTC+8, Xiangdong JI wrote: > > Hi, > > Significant fluctuation is observed when running micro benchmarks, even > with the same version of go, e.g the following numbers from math/big > package, could anyone please share practices that may help generate stable > result? > > > FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05% > (p=0.008 n=5+5) > FloatAdd/10-64 5.29µs ± 1%5.56µs ± 0%+5.08% > (p=0.008 n=5+5) > FloatSub/10-64125ns ± 0% 125ns ± 0% ~ > (p=0.444 n=5+5) > FloatSub/100-64 126ns ± 0% 126ns ± 0% ~ > (all equal) > FloatSub/1000-64 150ns ± 0% 150ns ± 0% ~ > (all equal) > FloatSub/1-64 393ns ± 0% 447ns ± 0% +13.79% > (p=0.008 n=5+5) > FloatSub/10-64 3.20µs ± 0%3.20µs ± 0% ~ > (p=0.056 n=5+5) > ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26% > (p=0.016 n=5+5) > ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1% ~ > (p=0.690 n=5+5) > GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60% > (p=0.029 n=4+4) > GCD10x10/WithXY-64746ns ± 1% 747ns ± 1% ~ > (p=0.810 n=4+5) > GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0% ~ > (p=0.730 n=5+5) > GCD10x100/WithXY-64 2.35µs ±14%2.23µs ± 2% ~ > (p=0.175 n=5+5) > GCD10x1000/WithoutXY-64 1.16µs ±13%1.37µs ±43% ~ > (p=0.310 n=5+5) > GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29% ~ > (p=0.841 n=5+5) > GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46% ~ > (p=0.151 n=5+5) > GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53% ~ > (p=0.310 n=5+5) > GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16% ~ > (p=0.421 n=5+5) > GCD10x10/WithXY-64 * 169µs ±19% 271µs ±28% > +60.47% * (p=0.016 n=5+5) > GCD100x100/WithoutXY-64 2.37µs ±18%2.31µs ± 8% ~ > (p=0.841 n=5+5) > GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1% ~ > (p=0.556 n=5+4) > GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27% ~ > (p=0.841 n=5+5) > GCD100x1000/WithXY-64 * 7.44µs ± 3% 10.67µs ±22% > +43.33%* (p=0.008 n=5+5) > GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3% -35.83% > (p=0.016 n=5+4) > GCD100x1/WithXY-64 71.3µs ±93% 118.5µs ±44% ~ > (p=0.151 n=5+5) > GCD100x10/WithoutXY-64199µs ±56% 195µs ±29% ~ > (p=1.000 n=5+5) > GCD100x10/WithXY-64 * 459µs ±33% 892µs ±60% > +94.33% * (p=0.016 n=5+5) > GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10% ~ > (p=1.000 n=5+5) > GCD1000x1000/WithXY-64 39.8µs ± 0%43.9µs ±10% +10.26% > (p=0.008 n=5+5) > GCD1000x1/WithoutXY-64 41.6µs ± 0%56.0µs ±16% +34.70% > (p=0.008 n=5+5) > GCD1000x1/WithXY-64 *154µs ± 0% 302µs ±29% > +96.15%* (p=0.008 n=5+5) > GCD1000x10/WithoutXY-64 240µs ± 0% 268µs ±11% +11.64% > (p=0.016 n=4+5) > GCD1000x10/WithXY-64 *2.51ms ±60% 9.28ms ±197% > +270.21%* (p=0.032 n=5+5) > GCD1x1/WithoutXY-64 545µs ± 0% 549µs ± 0%+0.69% > (p=0.008 n=5+5) > GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1% ~ > (p=0.222 n=5+5) > GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27% +19.66% > (p=0.008 n=5+5) > GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14% ~ > (p=0.841 n=5+5) > GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0% ~ > (p=0.690 n=5+5) > GCD10x10/WithXY-64 84.9ms ± 0%85.0ms ± 0% ~ > (p=0.905 n=5+4) > Hilbert-64 1.93ms ± 0%1.93ms ± 1% ~ > (p=1.000 n=4+5) > Binomial-64 3.42µs ± 2%3.59µs ± 8% ~ > (p=0.095 n=5+5) > QuoRem-644.55µs ± 0%4.55µs ± 0% ~ > (p=0.659 n=5+5) > Exp-64 17.1ms ± 0%17.1ms ± 0% ~ > (p=0.841 n=5+5) > Exp2-64 17.1ms ± 0%17.1ms ± 0% ~ > (p=0.421 n=5+5) > Bitset-6420.8ns ± 0%20.8
[go-nuts] Re: How to reduce the fluctuation of micro benchmark results
BTW. 'drop cache' is made, while setting cpu governor is not supported by the platform. Thanks. On Wednesday, January 8, 2020 at 10:19:25 AM UTC+8, Xiangdong JI wrote: > > Hi, > > Significant fluctuation is observed when running micro benchmarks, even > with the same version of go, e.g the following numbers from math/big > package, could anyone please share practices that may help generate stable > result? > > > FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05% > (p=0.008 n=5+5) > FloatAdd/10-64 5.29µs ± 1%5.56µs ± 0%+5.08% > (p=0.008 n=5+5) > FloatSub/10-64125ns ± 0% 125ns ± 0% ~ > (p=0.444 n=5+5) > FloatSub/100-64 126ns ± 0% 126ns ± 0% ~ > (all equal) > FloatSub/1000-64 150ns ± 0% 150ns ± 0% ~ > (all equal) > FloatSub/1-64 393ns ± 0% 447ns ± 0% +13.79% > (p=0.008 n=5+5) > FloatSub/10-64 3.20µs ± 0%3.20µs ± 0% ~ > (p=0.056 n=5+5) > ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26% > (p=0.016 n=5+5) > ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1% ~ > (p=0.690 n=5+5) > GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60% > (p=0.029 n=4+4) > GCD10x10/WithXY-64746ns ± 1% 747ns ± 1% ~ > (p=0.810 n=4+5) > GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0% ~ > (p=0.730 n=5+5) > GCD10x100/WithXY-64 2.35µs ±14%2.23µs ± 2% ~ > (p=0.175 n=5+5) > GCD10x1000/WithoutXY-64 1.16µs ±13%1.37µs ±43% ~ > (p=0.310 n=5+5) > GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29% ~ > (p=0.841 n=5+5) > GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46% ~ > (p=0.151 n=5+5) > GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53% ~ > (p=0.310 n=5+5) > GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16% ~ > (p=0.421 n=5+5) > GCD10x10/WithXY-64 * 169µs ±19% 271µs ±28% > +60.47% * (p=0.016 n=5+5) > GCD100x100/WithoutXY-64 2.37µs ±18%2.31µs ± 8% ~ > (p=0.841 n=5+5) > GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1% ~ > (p=0.556 n=5+4) > GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27% ~ > (p=0.841 n=5+5) > GCD100x1000/WithXY-64 * 7.44µs ± 3% 10.67µs ±22% > +43.33%* (p=0.008 n=5+5) > GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3% -35.83% > (p=0.016 n=5+4) > GCD100x1/WithXY-64 71.3µs ±93% 118.5µs ±44% ~ > (p=0.151 n=5+5) > GCD100x10/WithoutXY-64199µs ±56% 195µs ±29% ~ > (p=1.000 n=5+5) > GCD100x10/WithXY-64 * 459µs ±33% 892µs ±60% > +94.33% * (p=0.016 n=5+5) > GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10% ~ > (p=1.000 n=5+5) > GCD1000x1000/WithXY-64 39.8µs ± 0%43.9µs ±10% +10.26% > (p=0.008 n=5+5) > GCD1000x1/WithoutXY-64 41.6µs ± 0%56.0µs ±16% +34.70% > (p=0.008 n=5+5) > GCD1000x1/WithXY-64 *154µs ± 0% 302µs ±29% > +96.15%* (p=0.008 n=5+5) > GCD1000x10/WithoutXY-64 240µs ± 0% 268µs ±11% +11.64% > (p=0.016 n=4+5) > GCD1000x10/WithXY-64 *2.51ms ±60% 9.28ms ±197% > +270.21%* (p=0.032 n=5+5) > GCD1x1/WithoutXY-64 545µs ± 0% 549µs ± 0%+0.69% > (p=0.008 n=5+5) > GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1% ~ > (p=0.222 n=5+5) > GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27% +19.66% > (p=0.008 n=5+5) > GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14% ~ > (p=0.841 n=5+5) > GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0% ~ > (p=0.690 n=5+5) > GCD10x10/WithXY-64 84.9ms ± 0%85.0ms ± 0% ~ > (p=0.905 n=5+4) > Hilbert-64 1.93ms ± 0%1.93ms ± 1% ~ > (p=1.000 n=4+5) > Binomial-64 3.42µs ± 2%3.59µs ± 8% ~ > (p=0.095 n=5+5) > QuoRem-644.55µs ± 0%4.55µs ± 0% ~ > (p=0.659 n=5+5) > Exp-64 17.1ms ± 0%17.1ms ± 0% ~ > (p=0.841 n=5+5) > Exp2-64 17.1ms ± 0%17.1ms ± 0% ~ > (p=0.421 n=5+5) > Bitset-6420.8ns ±
[go-nuts] How to reduce the fluctuation of micro benchmark results
Hi, Significant fluctuation is observed when running micro benchmarks, even with the same version of go, e.g the following numbers from math/big package, could anyone please share practices that may help generate stable result? FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05% (p=0.008 n=5+5) FloatAdd/10-64 5.29µs ± 1%5.56µs ± 0%+5.08% (p=0.008 n=5+5) FloatSub/10-64125ns ± 0% 125ns ± 0% ~ (p=0.444 n=5+5) FloatSub/100-64 126ns ± 0% 126ns ± 0% ~ (all equal) FloatSub/1000-64 150ns ± 0% 150ns ± 0% ~ (all equal) FloatSub/1-64 393ns ± 0% 447ns ± 0% +13.79% (p=0.008 n=5+5) FloatSub/10-64 3.20µs ± 0%3.20µs ± 0% ~ (p=0.056 n=5+5) ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26% (p=0.016 n=5+5) ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1% ~ (p=0.690 n=5+5) GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60% (p=0.029 n=4+4) GCD10x10/WithXY-64746ns ± 1% 747ns ± 1% ~ (p=0.810 n=4+5) GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0% ~ (p=0.730 n=5+5) GCD10x100/WithXY-64 2.35µs ±14%2.23µs ± 2% ~ (p=0.175 n=5+5) GCD10x1000/WithoutXY-64 1.16µs ±13%1.37µs ±43% ~ (p=0.310 n=5+5) GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29% ~ (p=0.841 n=5+5) GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46% ~ (p=0.151 n=5+5) GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53% ~ (p=0.310 n=5+5) GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16% ~ (p=0.421 n=5+5) GCD10x10/WithXY-64 * 169µs ±19% 271µs ±28% +60.47% * (p=0.016 n=5+5) GCD100x100/WithoutXY-64 2.37µs ±18%2.31µs ± 8% ~ (p=0.841 n=5+5) GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1% ~ (p=0.556 n=5+4) GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27% ~ (p=0.841 n=5+5) GCD100x1000/WithXY-64 * 7.44µs ± 3% 10.67µs ±22% +43.33%* (p=0.008 n=5+5) GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3% -35.83% (p=0.016 n=5+4) GCD100x1/WithXY-64 71.3µs ±93% 118.5µs ±44% ~ (p=0.151 n=5+5) GCD100x10/WithoutXY-64199µs ±56% 195µs ±29% ~ (p=1.000 n=5+5) GCD100x10/WithXY-64 * 459µs ±33% 892µs ±60% +94.33% * (p=0.016 n=5+5) GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10% ~ (p=1.000 n=5+5) GCD1000x1000/WithXY-64 39.8µs ± 0%43.9µs ±10% +10.26% (p=0.008 n=5+5) GCD1000x1/WithoutXY-64 41.6µs ± 0%56.0µs ±16% +34.70% (p=0.008 n=5+5) GCD1000x1/WithXY-64 *154µs ± 0% 302µs ±29% +96.15%* (p=0.008 n=5+5) GCD1000x10/WithoutXY-64 240µs ± 0% 268µs ±11% +11.64% (p=0.016 n=4+5) GCD1000x10/WithXY-64 *2.51ms ±60% 9.28ms ±197% +270.21%* (p=0.032 n=5+5) GCD1x1/WithoutXY-64 545µs ± 0% 549µs ± 0%+0.69% (p=0.008 n=5+5) GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1% ~ (p=0.222 n=5+5) GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27% +19.66% (p=0.008 n=5+5) GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14% ~ (p=0.841 n=5+5) GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0% ~ (p=0.690 n=5+5) GCD10x10/WithXY-64 84.9ms ± 0%85.0ms ± 0% ~ (p=0.905 n=5+4) Hilbert-64 1.93ms ± 0%1.93ms ± 1% ~ (p=1.000 n=4+5) Binomial-64 3.42µs ± 2%3.59µs ± 8% ~ (p=0.095 n=5+5) QuoRem-644.55µs ± 0%4.55µs ± 0% ~ (p=0.659 n=5+5) Exp-64 17.1ms ± 0%17.1ms ± 0% ~ (p=0.841 n=5+5) Exp2-64 17.1ms ± 0%17.1ms ± 0% ~ (p=0.421 n=5+5) Bitset-6420.8ns ± 0%20.8ns ± 0% ~ (p=1.000 n=5+5) BitsetNeg-64 105ns ± 0% 106ns ± 1% ~ (p=0.238 n=4+5) BitsetOrig-64 231ns ±20% 183ns ± 2% -20.92% (p=0.016 n=5+5) BitsetNegOrig-64 786ns ±49% 543ns ±32% ~ (p=0.143 n=5+5) -- 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/5d57b1f4-7e9e-4aa5-bc74-85fac11c
[go-nuts] Re: Is a public go benchmarking database/dashboard available
Hi Tong, I meant public performance data from regular benchmarkings of public Go benchmark sets, say the 'go1' set. It could serve multiple purposes, as a source of perf. tuning investigation, for cross-checking with internal data, etc. I'm not proposing a 'cover-it-all' one but looking for data that could provide supplementary information. https://perf.golang.org/ is the only one I found so far, but its benchmarks seem to be private. Thanks. On Friday, December 6, 2019 at 9:28:28 AM UTC+8, Tong Sun wrote: > > > > On Monday, December 2, 2019 at 10:33:25 PM UTC-5, Xiangdong JI wrote: >> >> Hi, >> >> Wondering if there is any public database/dashboard of Go's benchmarking >> data available? Thanks. >> > > And by "public database" you meant a central one that covers everything? > I.e., the purpose of benchmarking varies dramatically, please elaborate > why you would think a cover-it-all one is a good idea. > > > -- 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/53c155f4-34ca-40a1-9923-db6b22f30c94%40googlegroups.com.
[go-nuts] Is a public go benchmarking database/dashboard available
Hi, Wondering if there is any public database/dashboard of Go's benchmarking data available? 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/1d6a2b2c-cd94-4c52-b55d-574b207c5e8b%40googlegroups.com.
[go-nuts] question about 'go vet ' with flag specifying 'analyzer'
Hi, When I run 'go vet' on specific package with the 'analyzer' flag, its behavior seems to depend on where the command is invoked, can anyone please shed a light here, any code pointers that may help me understand the difference is highly appreciated. 1. under /src, -unreachable=false suppress the 'unreachable' warning as expected $ go vet runtime/testdata/testprog # runtime/testdata/testprog runtime/testdata/testprog/deadlock.go:45:2: unreachable code runtime/testdata/testprog/deadlock.go:50:2: unreachable code $ go vet -unreachable=false runtime/testdata/testprog 2. under /, the flag doesn't take effect $ go vet -unreachable=false runtime/testdata/testprog # runtime/testdata/testprog src/runtime/testdata/testprog/deadlock.go:45:2: unreachable code src/runtime/testdata/testprog/deadlock.go:50:2: unreachable code $ go vet runtime/testdata/testprog # runtime/testdata/testprog src/runtime/testdata/testprog/deadlock.go:45:2: unreachable code src/runtime/testdata/testprog/deadlock.go:50:2: unreachable code -- 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/c278244e-2b80-40ac-bbad-fd129326782b%40googlegroups.com.
[go-nuts] Re: Any way to print a 'struct g' within delve/gdb
Thank your Derek, that's really helpful.
On Tuesday, November 12, 2019 at 10:52:58 PM UTC+8, Derek Parker wrote:
>
> If you look at the output of your first command you see the result
> `(**runtime.g)()`, however you're trying to cast to
> `(runtime.g*)()`. The correct syntax you're looking for is
> ` *(*runtime.g)()`. Hope that helps!
>
> On Monday, November 11, 2019 at 11:29:42 PM UTC-8, Xiangdong JI wrote:
>>
>> Hi Derek,
>>
>> Say I have the pointer value of a specific G struct, how to convert it to
>> 'struct g' (or any other form) in delve so that I can check
>> the details of its fields?
>>
>> For example (simply utilized runtime.m0.curg to get a pointer value here)
>>
>> (dlv) p &runtime.m0.curg
>> (**runtime.g)(0x56a140)
>>
>> Just tried a few commands to convert the value back to 'struct g' or a
>> pointer to 'struct g'
>>
>> (dlv) p (runtime.g*)(0x56b140)
>> Command failed: 1:12: expected operand, found ')'
>> (dlv) p ('runtime.g'*)(0x56b140)
>> Command failed: 1:2: illegal rune literal
>> (dlv) p ("runtime.g"*)(0x56b140)
>> Command failed: 1:14: expected operand, found ')'
>> (dlv) p ("runtime".g*)(0x56b140)
>> Command failed: 1:14: expected operand, found ')'
>>
>> Thanks.
>>
>> On Tuesday, November 12, 2019 at 2:28:12 AM UTC+8, Derek Parker wrote:
>>>
>>> Can you reply with a gist showing the exact Delve commands you are
>>> attempting to use and what errors are being returned?
>>>
>>> There is some more information on the expression parser here
>>> <https://github.com/go-delve/delve/blob/master/Documentation/cli/expr.md>.
>>> You can also open an issue on the Delve Github repo and we can help you out
>>> over there as well.
>>>
>>> On Sunday, November 10, 2019 at 11:58:24 PM UTC-8, Xiangdong JI wrote:
>>>>
>>>> Given a valid goroutine structure's pointer, say retrieving from the
>>>> register 'g', how can I convert it to 'struct g' in delve or gdb?
>>>>
>>>> gdb usually reports "A syntax error in expression ...", and delve
>>>> issues various "Command failed" message (failed to figure the proper way
>>>> of
>>>> converting a literal, I guess).
>>>>
>>>> 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/877cfa56-827a-4a7f-9822-889b66400e01%40googlegroups.com.
[go-nuts] Re: Any way to print a 'struct g' within delve/gdb
Hi Derek,
Say I have the pointer value of a specific G struct, how to convert it to
'struct g' (or any other form) in delve so that I can check
the details of its fields?
For example (simply utilized runtime.m0.curg to get a pointer value here)
(dlv) p &runtime.m0.curg
(**runtime.g)(0x56a140)
Just tried a few commands to convert the value back to 'struct g' or a
pointer to 'struct g'
(dlv) p (runtime.g*)(0x56b140)
Command failed: 1:12: expected operand, found ')'
(dlv) p ('runtime.g'*)(0x56b140)
Command failed: 1:2: illegal rune literal
(dlv) p ("runtime.g"*)(0x56b140)
Command failed: 1:14: expected operand, found ')'
(dlv) p ("runtime".g*)(0x56b140)
Command failed: 1:14: expected operand, found ')'
Thanks.
On Tuesday, November 12, 2019 at 2:28:12 AM UTC+8, Derek Parker wrote:
>
> Can you reply with a gist showing the exact Delve commands you are
> attempting to use and what errors are being returned?
>
> There is some more information on the expression parser here
> <https://github.com/go-delve/delve/blob/master/Documentation/cli/expr.md>.
> You can also open an issue on the Delve Github repo and we can help you out
> over there as well.
>
> On Sunday, November 10, 2019 at 11:58:24 PM UTC-8, Xiangdong JI wrote:
>>
>> Given a valid goroutine structure's pointer, say retrieving from the
>> register 'g', how can I convert it to 'struct g' in delve or gdb?
>>
>> gdb usually reports "A syntax error in expression ...", and delve issues
>> various "Command failed" message (failed to figure the proper way of
>> converting a literal, I guess).
>>
>> 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/c3cca170-5e93-442f-b5f5-6d827dcd30d8%40googlegroups.com.
[go-nuts] Any way to print a 'struct g' within delve/gdb
Given a valid goroutine structure's pointer, say retrieving from the register 'g', how can I convert it to 'struct g' in delve or gdb? gdb usually reports "A syntax error in expression ...", and delve issues various "Command failed" message (failed to figure the proper way of converting a literal, I guess). 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/df956377-531b-4469-883a-155d24a83133%40googlegroups.com.
Re: [go-nuts] Any non-split 'print' functions available?
Thanks Ian, having difficulty figuring out how to print a pointer using
write1, could you please shed a light? Thanks.
On Friday, November 1, 2019 at 2:00:04 PM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 31, 2019 at 5:10 AM Xiangdong JI > wrote:
> >
> > seeking utilities for diagnosing some 'nosplit' runtime functions.
> Thanks a lot.
>
> b := []byte("my debug message\n")
> write1(2, &b[0], len(b))
>
> 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/d097f1f1-7127-49d3-834c-e22c8b7ecb26%40googlegroups.com.
[go-nuts] Any non-split 'print' functions available?
seeking utilities for diagnosing some 'nosplit' runtime functions. Thanks a lot. -- 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/746e4708-fcdf-4e81-8b60-238e68f10572%40googlegroups.com.
[go-nuts] 'print' in runtime code causes panic "newstack at runtime.printlock" and "morestack on g0"
Hi,
A few 'print' statements in runtime for diagnosing result in panic like the
following, what could be the root cause? any alternatives to display g's
value?
Thanks a lot.
1 g := getg() // existing code
2 print(g, g.stack.lo, g.stack.hi)// new line
runtime: newstack at runtime.printlock+0x7c sp=0x400074cc40
stack=[0x40008d8000, 0x40008da000]
morebuf={pc:0x51bf8 sp:0x400074cc40 lr:0x0}
sched={pc:0x3dfdc sp:0x400074cc40 lr:0x51bf8 ctxt:0x0}
runtime.sigtrampgo(0x11, 0x400074cda0, 0x400074ce20)
runtime.sigtrampgo(0x11, 0x40003dcda0, 0x40003dce20)
fatal error: runtime: stack split at bad time
runtime: newstack at runtime.printlock+0x7c sp=0x4000442c40
stack=[0x4000818000, 0x400081a000]
morebuf={pc:0x51bf8 sp:0x4000442c40 lr:0x0}
sched={pc:0x3dfdc sp:0x4000442c40 lr:0x51bf8 ctxt:0x0}
runtime.sigtrampgo(0x11, 0x4000442da0, 0x4000442e20)
--
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/8e384613-ceea-47c6-a66f-69016d264021%40googlegroups.com.
Re: [go-nuts] How to invoke child 'go' process in playground?
Thanks Kurtis.
On Saturday, October 12, 2019 at 12:09:52 PM UTC+8, Kurtis Rader wrote:
>
> The Go playground does not allow running arbitrary external commands. No
> doubt primarily for security reasons. But also because the playground
> environment is not a complete virtualized OS. For example, try to execute
>
> exec.Command("/bin/ls", "-la")
>
> You'll get a "not implemented on nacl" error. See
> https://blog.golang.org/playground
>
> On Fri, Oct 11, 2019 at 8:34 PM Xiangdong JI > wrote:
>
>> Hi,
>>
>> Given a command execution like "cmd := exec.CommandContext(ctx, "go",
>> "run", file)" playground reports the following error:
>>
>> child error: exec: "go": executable file not found in $PATH
>>
>>
>> Could it be solved by specifying a full path for 'go', which path shall I
>> use? Thanks a lot.
>>
>> https://play.golang.org/p/6b79TLLCzfP
>>
>> --
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/30f33420-47d9-4fe7-8e39-980f8d5370db%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/30f33420-47d9-4fe7-8e39-980f8d5370db%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
>
> --
> 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/8615b967-2026-485e-990f-d68cbd8b1538%40googlegroups.com.
[go-nuts] How to invoke child 'go' process in playground?
Hi, Given a command execution like "cmd := exec.CommandContext(ctx, "go", "run", file)" playground reports the following error: child error: exec: "go": executable file not found in $PATH Could it be solved by specifying a full path for 'go', which path shall I use? Thanks a lot. https://play.golang.org/p/6b79TLLCzfP -- 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/30f33420-47d9-4fe7-8e39-980f8d5370db%40googlegroups.com.
Re: [go-nuts] lots of 'undeclared name' errors with vscode/gopls
Thanks for the hint. My vscode project is built on Go source code tree, turns out gopls, the project (go compiler source) and go binary should be version compatible, I solved the problem by setting the source code path as GOROOT in settings.json and rebuild the extension tools. On Friday, September 27, 2019 at 2:50:11 PM UTC+8, MUNGAI wrote: > > Hi, had the same issue when using Go modules. Does your project have > modules? > > Also, check GOPATH and GROOT setting. > > On Fri, Sep 27, 2019, 8:21 AM Xiangdong JI > > wrote: > >> Hi, >> >> I got a lot of 'undeclared name' errors with vscode, not sure it's >> something wrong with vscode or gopls, or my settings, hopefully someone can >> shed a light here, thanks. >> >> Take src/runtime/mbitmap.go as an example, seems that any cross-file >> reference is not recognized, tried to run 'gopls check mbitmap.go' in >> terminal and got the same output, >> the first few lines of gopls' output: >> >> 2019/09/27 05:16:28 Info:2019/09/27 05:16:28 96.267909ms for GOROOT= >> GOPATH=/home/xiaji01/.go GO111MODULE= >> PWD=/mnt/share/homes/xiaji01/src/go.svc/src/runtime go "list" "-e" "-json" >> "-compiled=true" "-test=true" "-export=false" "-deps=true" "-find=false" >> "--" "/mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go", stderr: >> <<>> >> 2019/09/27 05:16:28 Info:2019/09/27 05:16:28 go/packages.Load >> packages = 1 >> 2019/09/27 05:16:28 Info:2019/09/27 05:16:28 go/packages.Load >> package = command-line-arguments >> files = >> [/mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go] >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:150:29-41: >> undeclared name: heapAddrBits >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:150:43-57: >> undeclared name: heapArenaBytes >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:168:10-15: >> undeclared name: mspan >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:177:10-15: >> undeclared name: mspan >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:195:10-15: >> undeclared name: mspan >> /mnt/share/homes/xiaji01/src/go.svc/src/runtime/mbitmap.go:246:10-15: >> undeclared name: mspan >> >> >> $ gopls version >> golang.org/x/tools/gopls v0.1.7 >> golang.org/x/tools/gopls@v0.1.7 >> h1:YwKf8t9h69++qCtVmc2q6fVuetFXmmu9LKoPMYLZid4= >> >> $ go version >> go version devel +20f0bcb0c1 Sun Sep 22 17:10:30 2019 + linux/amd64 >> >> >> [image: Capture.JPG] >> >> -- >> 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 golan...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/d4000ccd-cb3d-4e8e-b2cf-6391311ce836%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/d4000ccd-cb3d-4e8e-b2cf-6391311ce836%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/90522c8f-85ef-4869-bf03-fa2a14fae084%40googlegroups.com.
[go-nuts] Building go 1.13 on aarch64 failed in pkg testing
Hello, I got the following error while building the latest source code (synced to d0eaec79f9) on aarch64, both cache and /tmp/go-build* had been cleaned in advance, can anyone shed a light? Thanks a lot. go tool dist: unexpected stale targets reported by go list -gcflags="" -ldflags="" for [std]: STALE crypto/tls: not installed but available in build cache STALE crypto/x509: not installed but available in build cache STALE net: not installed but available in build cache STALE net/http: not installed but available in build cache STALE net/http/cookiejar: not installed but available in build cache STALE net/http/httptest: not installed but available in build cache STALE net/http/httptrace: not installed but available in build cache STALE net/http/httputil: not installed but available in build cache STALE net/textproto: not installed but available in build cache STALE os/signal/internal/pty: not installed but available in build cache STALE os/user: not installed but available in build cache STALE vendor/golang.org/x/net/http/httpguts: not installed but available in build cache STALE vendor/golang.org/x/net/http/httpproxy: not installed but available in build cache STALE vendor/golang.org/x/net/nettest: not installed but available in build cache // go env GOARCH="arm64" GOHOSTARCH="arm64" GOHOSTOS="linux" GOOS="linux" GOROOT="/usr/lib/go-1.10" GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_arm64" CGO_ENABLED="1" -- 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/8f38c5f3-7ca8-405f-b2d2-1804dd9bdddb%40googlegroups.com.
Re: [go-nuts] what do init functions like "math ~math" in .gox refer to?
Thanks Ian. Curious to know the purpose of those dummy functions, and for the 'import' functions do they have real function bodies? On Wednesday, August 21, 2019 at 12:40:44 PM UTC+8, Ian Lance Taylor wrote: > > On Tue, Aug 20, 2019 at 9:12 PM Xiangdong JI > wrote: > > > > In 'init' section of .gox files, there might be functions like the > followings besides those 'import', > > > > math ~math bits ~math..z2fbits atomic > ~runtime..z2finternal..z2fatomic > > > > where and how are those functions generated, any source code or doc I > can refer to? Thanks. > > These are pairs of package name and init function name. If the init > function name starts with "~" then it is a dummy name and there is no > actual function. Otherwise it is a real function. The function is > generated by the compiler and handles initialization of package scope > variables that cannot be statically initialized, and calls all the > init functions in the package. > > 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/322e7407-bc21-44ea-8ca3-4ad07a7851b7%40googlegroups.com.
[go-nuts] Re: Patch RFA: [C family frontend]: avoid weird constant values in libgo/sysinfo.go
Thanks a lot, Ian. the schedule is fine. On Wednesday, August 21, 2019 at 7:37:10 AM UTC+8, Ian Lance Taylor wrote: > > On Mon, Aug 12, 2019 at 8:21 PM Xiangdong JI > wrote: > > > > The .go files generated during building gccgo seem to have a few > constants with weird values, for example: > > > > // sysinfo.go (on x86-64, latest gcc-9 trunk) > > > > const ___FLT128_MAX__ = 1.1 > > const ___FLT32X_DENORM_MIN__ = 1.1 > > > > as a comparison, gollvm generates expected values. > > Could it be caused by incorrect building setting? > > Per later discussion, this problem is fixed by this patch. > Bootstrapped and ran full testsuite on x86_64-pc-linux-gnu. > > OK for mainline? > > Ian > > > 2019-08-20 Ian Lance Taylor > > > * c-cppbuiltin.c (builtin_define_with_hex_fp_value): Always expand > when using -fgo-dump-spec. > -- 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/3ad9946e-6a97-469c-9adf-5b8fdadfd677%40googlegroups.com.
[go-nuts] what do init functions like "math ~math" in .gox refer to?
Hello, In 'init' section of .gox files, there might be functions like the followings besides those 'import', math ~math bits ~math..z2fbits atomic ~runtime..z2finternal..z2fatomic where and how are those functions generated, any source code or doc I can refer to? 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/97cedf72-39bb-4875-ab03-0ef6e92cde44%40googlegroups.com.
[go-nuts] [gccgo] weird constant values in sysinfo.go
Hello, The .go files generated during building gccgo seem to have a few constants with weird values, for example: // sysinfo.go (on x86-64, latest gcc-9 trunk) const ___FLT128_MAX__ = 1.1 const ___FLT32X_DENORM_MIN__ = 1.1 as a comparison, gollvm generates expected values. Could it be caused by incorrect building setting? 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/b808ccdd-023c-4b95-9db0-2a00b3435735%40googlegroups.com.
[go-nuts] [gollvm] build failure (mangled name of 'prefetch' inconsistent between llvm and gollvm)
Hello, I got a build failures after syncing llvm, gollvm and gofront-end to their latest commits, llvm-goc errors out: = Intrinsic name not mangled correctly for type arguments! Should be: llvm.prefetch.p0i8 void (i8*, i32, i32, i32)* @llvm.prefetch.p0i8.i32.i32 = commit c0702618c0e0a5c742aa20b831041bde366417f1 -: Intrinsic<[], [ llvm_ptr_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty ], +: Intrinsic<[], [ llvm_anyptr_ty, llvm_i32_ty, llvm_i32_ty, llvm_i32_ty ], The above commit submitted last week in llvm makes 'prefetch' an overloaded built-in now. Gollvm considers all arguments of 'prefetch' being of overloaded type when calculating its mangled name, while llvm only takes the first which of iPTRAny, should gollvm be enhanced to align with llvm? -- 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/8c15d3f3-acc3-499d-a803-2f59e688a0eb%40googlegroups.com.
[go-nuts] [gollvm] compiling error of libgo/runtime/aeshash.c on ARM
Hello,
I am trying to build gollvm on ARM with a few experimental changes, looks
like some ARM Neon intrinsics in
libgo/runtime/aeshash.c are not supported by GCC 7/8, wondering if it could
be solved by any additional compile
options, or should the latest gcc-9 or clang be used?
clang could compile this single file without errors but I haven't made it
pass the CMake test, and seems
that building gcc-9 on my platform will take much longer time than
expected, it would be of great help if the issue
could be addressed with gcc-7/8.
Any comment is highly appreciated!
-- errors issued by gcc
aeshash.c:733:11: error: incompatible types when assigning to type
‘uint8x16x3_t {aka struct uint8x16x3_t}’ from type ‘int’
avseed3 = vld1q_u8_x3((uint8*)(pseed + 3));
^
aeshash.c:754:10: error: incompatible types when assigning to type
‘uint8x16x2_t {aka struct uint8x16x2_t}’ from type ‘int’
avval2 = vld1q_u8_x2((uint8*)(p));
^
It turns out:
gcc-7.4.0 doesn't recognize both "vld1q_u8_x3" and "vld1q_u8_x2"
gcc-8.3.0 doesn't recognize "vld1q_u8_x3"
--
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/016162a0-8b4a-4f3b-8047-dbe4d2ecc2a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
