cherrymui
cherrymui
That is true. I'm not sure either. But I also feel keeping all statements "live" may be too much. Or may be not? Maybe we can analyze some existing benchmarks...
The proposal also mentions > Iteration ramp-up can be done entirely within b.Loop, which means that benchmark setup before b.Loop will happen once and only once, rather than at each...
Could you try Go at tip of the master branch? There were some recent optimizations that didn't make into Go 1.23. Thanks! cc @golang/compiler @dr2chase
> cpu: Apple M3 Pro Also, @dr2chase discovered that Apple Silicon chips may have some weird performance behaviors that we don't yet understand. Specifically, the inner loop runs _faster_ if...
> go build -gcflags="-N -l -S" iter.go Do not use `-N -l` to look at optimizations. `-N -l` is meant to generate slower code, by definition.
cc @golang/release @dmitshur
#68919 has some related discussions.
The failure stacktrace is ``` : internal compiler error: panic: runtime error: index out of range [0] with length 0 goroutine 1 [running]: runtime/debug.Stack() /usr/local/go/src/runtime/debug/stack.go:26 +0x5e cmd/compile/internal/base.FatalfAt({0x43c330?, 0xc0?}, {0xe2d472, 0x9},...
The ARM64 calling convention is to store the frame pointer below the link register. As the LR is stored at 0(SP), we had to store FP at -8(SP). It is...
> couldn't the (FP, LR) pair be stored at the end (highest address) of the stack frame User assembly code depend on LR saved at 0(SP). We can't change it...