Re: [go-nuts] GOEXPERIMENT source code build

['Michael Pratt' via golang-nuts]

You can just set the environment variable, so `GOEXPERIMENT=swissmap go
test`.

On Fri, Aug 16, 2024 at 3:28 PM Leah Stapleton 
wrote:

> Hi,
> I have a question about building go source code to run the tests go swiss
> maps experiments.
>
> first off,
> There are tests with the same name in map_swiss_test.go and
> map_noswiss_test.go, and when I *go test -run TestMapIterOrder, *it is by
> default running the test in map_noswiss_test.go, so I assume I need to
> build the source code for this experiment.
>
> How do I indicate I want the go source code build to use swiss maps
> experiment?
>
> I normally run just run /make.bash from the /src dir.
>
>
>
> --
> 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/4010244f-ebb0-4766-a6a5-d984e3108869n%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/CALoThU_tfHVUkSVBUTU1DmFDtze5XGxLBL-XsumVrLyTLp7jEw%40mail.gmail.com.

Re: [go-nuts] Shrinking pprof data for PGO through quantization.

['Michael Pratt' via golang-nuts]

Hi Adam,

Thanks for sending this, lots of interesting ideas here!

I've been meaning for a long time to have more concrete guidelines for how
much data collection is enough for good results, to include on
https://go.dev/doc/pgo.

I also think it would be valuable to provide tooling that can help minimize
file sizes. I played with this a bit last year, with results in
https://go.dev/cl/449500. In this CL I experimented with a few approaches:
truncating stacks (as you mention, though it seems this part didn't make it
into the code in my CL?), as well as aggregation: I drop PCs entirely since
the compiler can't use them anyway, and drop line numbers from leaf
functions since they don't matter to our current optimizations. Another
thing you'll see the source of that tool do is truncate the profile to 99%
CDF. i.e., drop all any samples in the coldest 1% of the application. This
is not a lossless operation because the compiler performs its own CDF
computations to determine which calls are hot and by removing some of the
total sample weight from the profile the compiler will probably decide a
few functions on the edge are no longer hot. To do this losslessly, I think
we'd need to keep the remaining weight in the profile as a single "unknown"
sample and have the compiler always sort that last.

Some other thoughts inline below:

On Thu, Nov 9, 2023 at 3:15 PM 'Adam Azarchs' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> It's great that we have PGO support in go now, and it's relatively easy to
> use.  One thing that is of mild concern to me is that typically one will be
> checking the default.pgo file in to the repo, and git is notoriously not
> great at handling binary blobs that are updated  frequently.  Its "diff
> compression" doesn't really work on compressed data, of course, which means
> that in a standard (non-shallow) clone that pulls down all history, over
> time it can contribute significantly to time to clone and size of the
> `.git` directory.  git lfs avoids the cumulative burden over time, but has
> its own set of problems.  At a few hundred kB each, they're not so
> concerning, but if you had for example an automated system that collected
> data from production and updated the profile data every few days (which you
> want to do if you're deploying new code that often), possibly for multiple
> executables, it starts to add up.  So far I've been recompressing the pprof
> data (which is automatically gzip-compressed) with zopfli, but I was
> thinking about making a tool to do better than that.
>
> Firstly, we can drop entries from the mappings table if they aren't
> referenced by any locations in samples.  For a linux cgo binary this will
> include stuff like libc.  We can then also drop corresponding entries from
> the string table.
>
> We can drop values for sample_types which are not of interest
> .
> That is, the first sample_type that is "samples"/"count" or
> "cpu"/"nanoseconds".  Most profiles seem to have both, but we only need to
> keep one of them.
>
> Next, it seems like PGO ignores all but the last two stack frames
> .
> This is of course an implementation detail subject to change, but the logic
> for why it does this is sound, and so it's probably still safe to truncate
> stack frames at least somewhat.  Doing so would likely permit many samples
> to be merged, which could significantly reduce the uncompressed size of the
> profile.
>
> A pprof profile is, for purposes of PGO, effectively table of execution
> stacks and how often they were sampled.  If you want to get really good
> profiling data, you do as the PGO guide tells you
>  and collect multiple samples and merge
> them, which gets you more coverage, but also makes for larger, more varied
> sample counts, which decreases the effectiveness of compression.  For
> purposes of PGO, we only care about the relative frequency of different
> code paths at a pretty coarse granularity.  There's two opportunities here.
>
> Normalizing and quantizing the sample counts should be possible to do with
> no significant effect on the accuracy or usefulness to PGO, and would
> improve the effectiveness of compression.  That is, you could for example
> round each sample count to the nearest power of N, and then scale them all
> so that the smallest sample count is N (where N is e.g. 2).  The effect of
> this would likely be minor, since most of the space in the profile is taken
> up by other things like the location and function tables, but it wouldn't
> hurt.
>

This sounds feasible, but, as you say, I imagine the impact on the final
size would be very small.



>
> The other, much more complicated thing we can do is merge sampled
> locations.  PGO is using the profile data to improve its guesses about
> wh

Re: [go-nuts] How long does it take to import packages?

['Michael Pratt' via golang-nuts]

Setting GODEBUG=inittrace=1 will log a trace of init function execution,
which you can use to determine if init is slow, and if so which packages.

e.g., `GODEBUG=inittrace=1 go version` ends with "init main @9.5 ms",
indicating that it look 9.5ms to run all init functions.

The format is described at
https://pkg.go.dev/runtime#hdr-Environment_Variables.

On Wed, Aug 31, 2022 at 3:00 AM ag9920  wrote:

> Hi, recently I've been trying to make my unit test faster. It seems too
> much time were spent on initialization. After removing all init() function
> in relevant packages. The speed was still very slow.It even takes dozens of
> seconds before entering my real unit test function.
>
> So I take a look at all the possible factors that might slow down the
> testing. The only possible reason I can think of is the time cost on
> import. Golang needs to import all packages recursively. And in my
> scenario, that's roughly dozens of packages.Maybe initializing const, var
> takes too much time.
>
> Is there any solution that could help me figured out the reason? I didn't
> find any tools that could tell me the time cost on import several packages.
>
> And if that's the case,  import a package does take much time, is it still
> possible for me to speed up my unit test?
>
>
> --
> 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/cd58955e-0c4b-4d56-afd7-1153d7be06dcn%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/CALoThU9aog7qArW8%3DfHQ6QL5gA%3DAV1136Mib0d3EOeJsfXv3oQ%40mail.gmail.com.

Re: [go-nuts] noinline is 25% faster than inline on apple m1 ?

['Michael Pratt' via golang-nuts]

I can reproduce similar behavior on linux-amd64:

$ perf stat ./example.com.test -test.bench=BenchmarkInline
-test.benchtime=1x
goos: linux
goarch: amd64
pkg: example.com
cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz
BenchmarkInline-12  1   16.78 ns/op

PASS

 Performance counter stats for './example.com.test
-test.bench=BenchmarkInline -test.benchtime=1x':

  1,691.95 msec task-clock:u  #1.004 CPUs utilized

 0  context-switches:u#0.000 /sec

 0  cpu-migrations:u  #0.000 /sec

   352  page-faults:u #  208.044 /sec

 6,732,752,072  cycles:u  #3.979 GHz

22,405,823,428  instructions:u#3.33  insn per cycle

 6,501,294,164  branches:u#3.842 G/sec

   149,596  branch-misses:u   #0.00% of all
branches

   1.684677260 seconds time elapsed

   1.692474000 seconds user
   0.00402 seconds sys



$ perf stat ./example.com.test -test.bench=BenchmarkNoInline
-test.benchtime=1x
goos: linux
goarch: amd64
pkg: example.com
cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz
BenchmarkNoInline-121   10.79 ns/op
PASS

 Performance counter stats for './example.com.test
-test.bench=BenchmarkNoInline -test.benchtime=1x':

  1,091.71 msec task-clock:u  #1.005 CPUs utilized

 0  context-switches:u#0.000 /sec

 0  cpu-migrations:u  #0.000 /sec

   363  page-faults:u #  332.505 /sec

 4,490,159,750  cycles:u  #4.113 GHz

20,205,764,499  instructions:u#4.50  insn per cycle

 6,701,281,015  branches:u#6.138 G/sec

   586,073  branch-misses:u   #0.01% of all
branches

   1.086302272 seconds time elapsed

   1.08771 seconds user
   0.008027000 seconds sys

The non-inlined version is actually fewer instructions to run the same
benchmark, which surprises me because naively looking at the disassembly it
seems that the inlined version is much more compact.


On Fri, Jul 22, 2022 at 5:52 AM eric...@arm.com  wrote:

> For this piece of code, two test functions are the same, but one is
> inlined, the other is not. However the inlined version is about 25% slower
> than the no inlined version on apple m1 chip. Why is it?
>
> The code is here https://go.dev/play/p/0NkLMtTZtv4
>
> --
> 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/527264d7-7cc1-4278-9a29-c04eb3ec4e86n%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/CALoThU8pAFzz_CGEQ1c4J_tEiLdyeu6kLkkYNjGZKkaLeTgYhw%40mail.gmail.com.

Re: [go-nuts] Re: Can’t view golang source when clicking on method name in a pkg.go.dev

['Michael Pratt' via golang-nuts]

This sounds like https://go.dev/issue/48956. In that case, it was some
interference from an extension.

On Tue, Apr 26, 2022 at 4:55 PM Ian Lance Taylor  wrote:

> On Tue, Apr 26, 2022 at 12:40 AM christoph...@gmail.com
>  wrote:
> >
> > This is a screen capture of what I see https://imgur.com/a/nuBfZeY
>
> That's odd.  I don't see that.  And that doesn't look like anything
> that Google would display.  Is it possible that this has something to
> do with the local administration at your site?
>
> Ian
>
> > Le mardi 26 avril 2022 à 09:37:38 UTC+2, christoph...@gmail.com a écrit
> :
> >>
> >> Sorry, my message needs a clarification. The page
> https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49
> doesn’t show me the source code.
> >> I see a big gray circle with the message, "authorization rejected,
> contact the administrator" which is hopeless of course.
> >>
> >>
> >> Le mardi 26 avril 2022 à 09:16:06 UTC+2, christoph...@gmail.com a
> écrit :
> >>>
> >>> I’m redirected to this page
> https://cs.opensource.google/go/go/+/go1.18.1:src/encoding/json/stream.go;l=49
> when I click on the Decode method in the web page
> https://pkg.go.dev/encoding/json#Decoder.
> >>>
> >>> Is this a transient problem or is the code not open source anymore ?
> >
> > --
> > 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/42a27298-a12f-4276-a23e-ce6bc573d4afn%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/CAOyqgcVQXcrHh19UC40orc%2BMHjzaeSD%2B_LnErp9GycvtaiKM%2BA%40mail.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/CALoThU_PdyTEytShNxB3H04hkq%3DqesZOd%3D52xYvxs5jokQ8Hsg%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

['Michael Pratt' via golang-nuts]

Go has a non-moving GC [1], so that is not an issue. That said,
unsafe.Pointer states "the referenced allocated object, if any, is retained
and not moved until the call completes". It doesn't say that this
recursively applies to objects referenced by the converted object, though I
perhaps it should.

[1] Except for stacks, but taking the address of a byte slice and putting
it in Iovec.Base will force it to escape anyways.

On Fri, May 14, 2021 at 9:44 AM Shaun Crampton  wrote:

> > You can use a *byte for the buffer. For instance, unix.Iovec does this
>
> Are you sure that's not a bug?  What's to stop the *Byte from being
> moved by the GC?
>
> On Fri, May 14, 2021 at 2:27 PM Michael Pratt  wrote:
> >
> > You can use a *byte for the buffer. For instance, unix.Iovec does this:
> https://pkg.go.dev/golang.org/x/sys/unix#Iovec
> >
> > Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall
> without any special handling of the *byte field.
> >
> > On Fri, May 14, 2021, 09:01 sh...@tigera.io  wrote:
> >>
> >> Now, is it technically legal to convert a uintptr to some location that
> was manually allocated and then cast it to an unsafe.Pointer?  When I look
> at the docs for unsafe.Pointer, I can't match that to any of the cases but
> it seems very likely to be safe by analogy with the GCO rules for handling
> "C" pointers and "Go" pointers.
> >>
> >> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
> >>>
> >>> Thanks for the pointer to that package; looking at our go.mod, looks
> like we've already got it as a transitive dependency so it looks ideal for
> my use case.
> >>>
> >>> On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote:
> 
>  On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io 
> wrote:
> 
>  > One way I could see to solve this would be to do some manual memory
> management with MMap or BRK to allocate the buffer but I wondered if there
> was an easier way?
> 
>  IMO using manual memory management _is_ the easy way in this case. I'm
>  using https://pkg.go.dev/modernc.org/memory for 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/317d44cf-8f2b-42d6-ab10-b42da7280616n%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/CALoThU8Qe8p1XyycwcoHnAcXG46DXYKWvDhLSUakAKN7fYmwHA%40mail.gmail.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

['Michael Pratt' via golang-nuts]

You can use a *byte for the buffer. For instance, unix.Iovec does this:
https://pkg.go.dev/golang.org/x/sys/unix#Iovec

Users can cast a *unix.Iovec directly to unsafe.Pointer for Syscall without
any special handling of the *byte field.

On Fri, May 14, 2021, 09:01 sh...@tigera.io  wrote:

> Now, is it technically legal to convert a uintptr to some location that
> was manually allocated and then cast it to an unsafe.Pointer?  When I look
> at the docs for unsafe.Pointer, I can't match that to any of the cases but
> it seems very likely to be safe by analogy with the GCO rules for handling
> "C" pointers and "Go" pointers.
>
> On Friday, May 14, 2021 at 1:24:28 PM UTC+1 sh...@tigera.io wrote:
>
>> Thanks for the pointer to that package; looking at our go.mod, looks like
>> we've already got it as a transitive dependency so it looks ideal for my
>> use case.
>>
>> On Friday, May 14, 2021 at 12:10:45 PM UTC+1 Jan Mercl wrote:
>>
>>> On Fri, May 14, 2021 at 12:36 PM sh...@tigera.io 
>>> wrote:
>>>
>>> > One way I could see to solve this would be to do some manual memory
>>> management with MMap or BRK to allocate the buffer but I wondered if there
>>> was an easier way?
>>>
>>> IMO using manual memory management _is_ the easy way in this case. I'm
>>> using https://pkg.go.dev/modernc.org/memory for 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/317d44cf-8f2b-42d6-ab10-b42da7280616n%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/CALoThU-Ph1vE%3DgAPLGtD76aBHU6bgxxuquf_3E7c__9dm0UH1A%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

['Michael Pratt' via golang-nuts]

Oops, I should say the syscall package could do this. x/sys/unix has the
extra complexity of not being tied to a Go release.

On Tue, Apr 27, 2021, 12:53 Michael Pratt  wrote:

> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a case that would certainly
> benefit.
>
> Regardless, one fairly clean way we could support this would be to make
> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
> than performing the syscall. That is always a valid operation (the VDSO
> will make the syscall if it doesn't support the specific options passed),
> and I think would solve this problem without even changing the API. It
> seems we don't do that already for simplicity of implementation and prior
> lack of need.
>
> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:
>
>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
>> wrote:
>>
>>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>>> scritto:
>>>
 On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
 wrote:
 >
 > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
 scritto:
 >>
 >> So I really want to know what is the right way to do vdso call
 outside runtime?
 >>
 > What about using a different function instead of time.Now, and using
 RawSyscall?

 That wouldn't be a VDSO call. VDSO calls are in general faster than
 system calls. There is more background at
 https://man7.org/linux/man-pages/man7/vdso.7.html.
>>>
>>> Ian
>>>
>>>
>>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo
>>> , maybe RawSyscall will be more efficient?
>>>
>>
>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
>> is possible that RawSyscall of clock_gettime with a coarse clock would be
>> faster than time.Now, but I would be surprised.
>>
>> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%40mail.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/CALoThU9C6uQHtHKFE7v38J-z5Ek5QgnUgHigQYOS6ZBp%3DRkY6Q%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

['Michael Pratt' via golang-nuts]

I'm not sure if calling through the VDSO is the best solution to this
specific issue, though it does sound like a case that would certainly
benefit.

Regardless, one fairly clean way we could support this would be to make
x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
than performing the syscall. That is always a valid operation (the VDSO
will make the syscall if it doesn't support the specific options passed),
and I think would solve this problem without even changing the API. It
seems we don't do that already for simplicity of implementation and prior
lack of need.

On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:

> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
> wrote:
>
>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>> scritto:
>>
>>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
>>> wrote:
>>> >
>>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>>> scritto:
>>> >>
>>> >> So I really want to know what is the right way to do vdso call
>>> outside runtime?
>>> >>
>>> > What about using a different function instead of time.Now, and using
>>> RawSyscall?
>>>
>>> That wouldn't be a VDSO call. VDSO calls are in general faster than
>>> system calls. There is more background at
>>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>>
>> Ian
>>
>>
>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo ,
>> maybe RawSyscall will be more efficient?
>>
>
> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
> is possible that RawSyscall of clock_gettime with a coarse clock would be
> faster than time.Now, but I would be surprised.
>
> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%40mail.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/CALoThU-sH_HvNbZz-NSR-OOa3tZNybw2YNYK43YqWsYkmT-XsA%40mail.gmail.com.

Re: [go-nuts] Re: [golang-dev] Go 1.16.3 and Go 1.15.11 are released

['Michael Pratt' via golang-nuts]

mgcsweepbuf.go was deleted in 1.16, so it seems you still have files from
1.15 sitting around in /usr/local/go/.

On Fri, Apr 2, 2021 at 4:13 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Apr 1, 2021 at 11:52 PM Dmitri Shuralyov 
> wrote:
>
> > We have just released Go versions 1.16.3 and 1.15.11, minor point
> releases.
>
> Cleared everything ($ go clean -cache -modcache -testcache ; rm -rf ~/pkg
> ~/.cache/go-build) and upgraded from 1.15.10 to 1.16.3. Now I am seeing
> while hacking some current project:
>
> jnml@3900x:~/src/modernc.org/qbe$ go test
> # runtime
> /usr/local/go/src/runtime/mgcsweepbuf.go:87:80: memstats.gc_sys undefined
> (type mstats has no field or method gc_sys)
> /usr/local/go/src/runtime/mgcsweepbuf.go:106:102: memstats.gc_sys
> undefined (type mstats has no field or method gc_sys)
> FAIL modernc.org/qbe [build failed]
> jnml@3900x:~/src/modernc.org/qbe$ go version
> go version go1.16.3 linux/amd64
> jnml@3900x:~/src/modernc.org/qbe$ go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/jnml/.cache/go-build"
> GOENV="/home/jnml/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/home/jnml/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/jnml"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct";
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.16.3"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/jnml/src/modernc.org/qbe/go.mod"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build1728759906=/tmp/go-build
> -gno-record-gcc-switches"
> jnml@3900x:~/src/modernc.org/qbe$
>
> Any ideas what's wrong? Thanks in advance.
>
> --
> 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/CAA40n-XUw%3D_SBa-dTVNFVuKKWdDreBjScwMxpHk4DGR7MyK-YQ%40mail.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/CALoThU86odpTdo8oFatbpyc%3Dc-o%3Di6%3DHToxrDuTF03zEeafm_A%40mail.gmail.com.