Re: [go-nuts] Value copy costs are not very predictable.

I believe it is save to say, even without other benchmarks, that a) you are correct that the cost is "unpredictable"¹ and b) that will always be the case. The compiler will always chose different strategies for differently sized values and if not that, the architecture of computers will have differ

Re: [go-nuts] Value copy costs are not very predictable.

On Sunday, May 30, 2021 at 12:28:55 AM UTC-4 Kurtis Rader wrote: > On Sat, May 29, 2021 at 8:50 PM tapi...@gmail.com > wrote: > >> The benchmark code: https://play.golang.org/p/bC1zO14eNeh >> > ... >> > From the benchmark result, it looks >> * the cost of copying a [13]int value is much large

Re: [go-nuts] Value copy costs are not very predictable.

On Sat, May 29, 2021 at 8:50 PM tapi...@gmail.com wrote: > The benchmark code: https://play.golang.org/p/bC1zO14eNeh > ... > From the benchmark result, it looks > * the cost of copying a [13]int value is much larger than copying a > [12]int value. > * the cost of copying a struct{a, b, c int} val

[go-nuts] Value copy costs are not very predictable.

The benchmark code: https://play.golang.org/p/bC1zO14eNeh The result: $ go test -bench=. goos: linux goarch: amd64 pkg: example.com/valuecopy cpu: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz Benchmark_CopyBool-410 0.8885 ns/op Benchmark_CopyByte-4

Re: [go-nuts] Operator precedence

Yes, Go will evaluate as specified in the spec. So it can't do (a*3.0)/2.0 as a*(3.0/2.0). At least, it always needs to produce results *as if* the former was used. Normally for floats that means it does the ops exactly in the order specified. For integers there are often rewrites that will make

Re: [go-nuts] Operator precedence

I would read it that way, yes. Note that regardless of the spec you can always indicate the intended precedence using parenthesis. If in doubt, I'd recommend to do that - if you are in doubt, the reader of the code will be as well. On Sun, May 30, 2021 at 12:54 AM Scott Pakin wrote: > When the O

[go-nuts] Operator precedence

When the Operator precedence section of the language specification says that "Binary operators of the same precedence associate from left to right. For instance, x / y * z is the same as (x / y) * z", does this imply that the language guarantees