Re: [go-nuts] Generic constant type parameters?

I was able to convert the fixed package to use generics to allow a variable number of decimal places. benchmark old ns/op new ns/op delta BenchmarkAddFixed-8 0.98 0.96 -1.66% BenchmarkMulFixed-8 5.44 22.8 +318.15%

Re: [go-nuts] Generic constant type parameters?

Thanks. Is there something in the language spec that covers this ? The design doc is the only thing that appears in a Google search. > On Oct 16, 2024, at 8:09 AM, Ian Lance Taylor wrote: > > On Tue, Oct 15, 2024 at 10:18 PM Robert Engels wrote: >> >> Hmm, I thought I had it “working” using

Re: [go-nuts] Generic constant type parameters?

t 15, 2024 at 5:01 PM 'Robert Engels' via golang-nuts > wrote: >> >> Is there someway of doing this with Go generics? >> https://github.com/robaho/cpp_fixed/blob/6770b217acd84e4b723449e4c4bb42c92e7f2af1/fixed.h#L18-L23 > > Not at present, sorry. > > Ian

[go-nuts] Generic constant type parameters?

Hi, Is there someway of doing this with Go generics? https://github.com/robaho/cpp_fixed/blob/6770b217acd84e4b723449e4c4bb42c92e7f2af1/fixed.h#L18-L23 I could make the type and interface and add a method for ‘decimal places’, but I would like all of the constants to be resolved at compile time.

Re: [go-nuts] Mutex profiling question

024, at 10:14 AM, 'Robert Engels' via golang-nuts <golang-nuts@googlegroups.com> wrote:I found this issue, https://github.com/golang/go/issues/57071 and tried running with GODEBUG=profileruntimelocks=1but it made no difference in the output.I am using Go 1.22.4 on OSX.Any ideas how I ca

[go-nuts] Mutex profiling question

I found this issue, https://github.com/golang/go/issues/57071 and tried running with GODEBUG=profileruntimelocks=1 but it made no difference in the output. I am using Go 1.22.4 on OSX. Any ideas how I can determine what is causing this high contention shown below: (pprof) tree Showing nodes

Re: [go-nuts] Importing non-module based code

Thanks. Make sense. > On Jul 16, 2024, at 9:00 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Tue, Jul 16, 2024 at 3:57 PM Robert Engels wrote: > >> Yes, I just added that tag and pushed it, but @latest wouldn’t pick it up >> for some reason, needed to specify the release exactly using @v0.3.1

Re: [go-nuts] Importing non-module based code

Yes, I just added that tag and pushed it, but @latest wouldn’t pick it up for some reason, needed to specify the release exactly using @v0.3.1 > On Jul 16, 2024, at 8:55 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Tue, Jul 16, 2024 at 3:50 PM Robert Engels wrote: >> >> Weird, even after I a

Re: [go-nuts] Importing non-module based code

rader to use modules. > >> On Jul 16, 2024, at 8:47 AM, Jan Mercl <0xj...@gmail.com> wrote: >> >> On Tue, Jul 16, 2024 at 3:41 PM 'Robert Engels' via golang-nuts >> wrote: >> >>> The go get works, and the code is there, but it isn’t seeing

Re: [go-nuts] Importing non-module based code

Thanks. Yea, because it needs a later tag now. I guess it never compiled after I changed go-trader to use modules. > On Jul 16, 2024, at 8:47 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Tue, Jul 16, 2024 at 3:41 PM 'Robert Engels' via golang-nuts > wrote: >

[go-nuts] Importing non-module based code

Has it changed so that Go repo that imports a from another repo that doesn’t use modules no longer works? Maybe a recent change? I have a repo github.com/robaho/go-trader that imports githut.com/robaho/gocui (which is a fork

Re: [go-nuts] Benchmark "overall" operation

> The usual way is to factor out any parts that can skew the results > before the benchmark loop and call b.ResetTimer() just before entering > the 'for i := 0; i < b.N; i++ {' loop. That isn’t applicable here. It is the performing of the operation that gets progressively slower. So when comparin

Re: [go-nuts] Benchmark "overall" operation

onical way of doing this? > On Jul 8, 2024, at 3:22 PM, Jan Mercl <0xj...@gmail.com> wrote: > > On Mon, Jul 8, 2024 at 10:08 PM 'Robert Engels' via golang-nuts > wrote: > >> Given this code (which I know is not “correct”): > > Setting b.N in the bench

[go-nuts] Benchmark "overall" operation

Given this code (which I know is not “correct”): func BenchmarkOrders(b *testing.B) { var ob = orderBook{} var inst = Equity{} var ex = testExchangeClient{} const N_ORDERS = 100 b.ResetTimer() b.N = N_ORDERS for i:=0;ihttps://groups.google.com/d/msgid/golang-nut

[go-nuts] More excellent work by the Go team!

I had the opportunity to revisit my interface dispatch benchmark (https://github.com/robaho/go-dispatch-test ). Previously, the dispatching using pointer receivers was nearly 3x slower (i.e. 5.5 ns to 12.6 ns): goos: darwin goarch: amd64 pkg: github.

Re: [go-nuts] Congrats to the Go team

² > > > StringBigFloat-8 7.000 ± ∞ ¹ 7.000 ± ∞ ¹ ~ > (p=1.000 n=1) ²

Re: [go-nuts] Congrats to the Go team

g.go.dev/golang.org/x/perf/cmd/benchstat > <https://pkg.go.dev/golang.org/x/perf/cmd/benchstat> which will provide a > nice side by side comparison? > > On Wed, 24 Apr 2024 at 19:26, 'Robert Engels' via golang-nuts > mailto:golang-nuts@googlegroups.com>> wrote

[go-nuts] Congrats to the Go team

I have a fairly stable project github.com/robaho/fixed which is almost 100% cpu bound. It doesn’t change so it makes a great way to compare the performance of different Go versions using the same hardware. I took the time to re-run the tests today. Using 1.21.17