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

Why not use the TSC timer for your timings, and convert TSC cycle times into durations during post-run analysis? On Thursday, 29 April 2021 at 04:04:58 UTC+1 Pure White wrote: > Hello, > We are doing heavily tracing, and for each func we need to get the time, > so that’s why I’d like to optim

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

Anyway, I think we are all consensus to optimize `time.Now`, Ian and me both sent pr for this. Thanks for everyone taking part in. 在 2021年4月29日 +0800 AM11:58，Robert Engels ，写道： > If you are timing so short operations that the overhead is 1-2%, just time > every 1000 calls - reduces the overhead t

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

Thanks for your suggestion. But in that way, we are not able to capture the abnormal call. 在 2021年4月29日 +0800 AM11:58，Robert Engels ，写道： > If you are timing so short operations that the overhead is 1-2%, just time > every 1000 calls - reduces the overhead to a minimum. Normally makes no > differ

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

If you are timing so short operations that the overhead is 1-2%, just time every 1000 calls - reduces the overhead to a minimum. Normally makes no difference if the operations are that short. Similar to how benchmarking works - time the total and divide by the number of operations. > On Apr 28

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

Hello, We are doing heavily tracing, and for each func we need to get the time, so that’s why I’d like to optimize this. 在 2021年4月29日 +0800 AM12:11，Ian Lance Taylor ，写道： > In the meantime we both sent speedups for time.Now. I measured > time.Now as taking about 30 nanoseconds per call before the s

Re: [go-nuts] Error Handling Proposal(s)

On Wed, Apr 28, 2021 at 2:29 PM Kaveh Shahbazian wrote: > > Is there a thread on proposals on error handling (with any chance to be > worked on, by the Go team)? > > Found this one by Russ Cox, but couldn't find any active threads on GitHub or > here. There are many error handling proposals. Y

[go-nuts] Error Handling Proposal(s)

Is there a thread on proposals on error handling (with any chance to be worked on, by the Go team)? Found this one by Russ Cox, but couldn't find any active threads on GitHub

Re: [go-nuts] Source code for go get

Thank you very much! Regards, Peter. On Wednesday, 28 April 2021 at 21:58:50 UTC+1 Ian Lance Taylor wrote: > On Wed, Apr 28, 2021 at 1:56 PM Peter Bočan wrote: > > > > Hey guys, I am interested in the inner workings of the go get command > but the codebase is so vast I have a hard time to fin

Re: [go-nuts] Source code for go get

On Wed, Apr 28, 2021 at 1:56 PM Peter Bočan wrote: > > Hey guys, I am interested in the inner workings of the go get command but the > codebase is so vast I have a hard time to find it. Start at src/cmd/go/internal/get. Ian -- You received this message because you are subscribed to the Google

[go-nuts] Source code for go get

Hey guys, I am interested in the inner workings of the go get command but the codebase is so vast I have a hard time to find it. Kindly, Peter. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

Re: [go-nuts] Re: Multi-word Project Name

Assuming by package name your mean package "packagename" and import path import "importpath" Guess by "even if it wasn't" you mean "even if it wasn't top level and was exporting functionality" but don't quite understand what you meant On Wednesday, 28 April 2021 at 21:47:15 UTC+1 axel.wa...@goo

Re: [go-nuts] Re: Multi-word Project Name

FWIW the package name doesn't *have* to be the same as the import path. So even if it wasn't, you could name the package something else and still use that import path. Otherwise, there would be the option to use `_`, which is valid inside an identifier. On Wed, Apr 28, 2021 at 10:40 PM iammadab w

[go-nuts] Re: Multi-word Project Name

Apparently, because it is a top level module and it won't be exporting anything it is actually fine. Thanks. On Wednesday, 28 April 2021 at 21:18:16 UTC+1 seank...@gmail.com wrote: > Yes that can be your module name, it won't affect much > > On Wednesday, April 28, 2021 at 10:14:55 PM UTC+2 iamm

[go-nuts] Re: Multi-word Project Name

Yes that can be your module name, it won't affect much On Wednesday, April 28, 2021 at 10:14:55 PM UTC+2 iammadab wrote: > Hi, I have a github repository name (sherlock-server) of which I have > found no one word description that captures the essence. > > Can I name the module github.com/usernam

[go-nuts] Multi-word Project Name

Hi, I have a github repository name (sherlock-server) of which I have found no one word description that captures the essence. Can I name the module github.com/username/sherlock-server? There will be internal packages in it and so their imports will contain the above module name. What is the be

Re: [go-nuts] Referencing a library name in a cgo comment whose name is known at build time

I've managed to workaround this using cgo pkg-config. Before doing go build, I generate a .pc file that has the necessary library names, includes, etc. My go files now use // #cgo pkg-config: mylib A little bit hacky, but it works. On Wednesday, April 28, 2021 at 12:03:53 PM UTC-4 Ian Lance Tay

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

In the meantime we both sent speedups for time.Now. I measured time.Now as taking about 30 nanoseconds per call before the speedup, and you measured it as taking about 40 nanoseconds per call before the speedup. That makes me wonder about your code: if a 40 nanosecond function is taking 1% to 2%

Re: [go-nuts] Referencing a library name in a cgo comment whose name is known at build time

On Wed, Apr 28, 2021 at 8:41 AM Aaron Epstein wrote: > > I have a C library that I am linking with from Go whose name is known at > build-time, and is not a constant I can write in a comment like > // #cgo LDFLAGS: -lmylib > > The library name is parameterized, i.e. libmy{VAR_NAME}lib.so > > Cgo

[go-nuts] Referencing a library name in a cgo comment whose name is known at build time

Hi, I have a C library that I am linking with from Go whose name is known at build-time, and is not a constant I can write in a comment like // #cgo LDFLAGS: -lmylib The library name is parameterized, i.e. libmy{VAR_NAME}lib.so Cgo doesn't seem to be able to handle environment variables, so I