code review 6819087: test/bench/go: new package

test/bench/go: new package

As discussed in CL 6813045, this package contains low level micro-benchmarks for gc compiler implementations.

Also added additional benchmarks for issues 2230 and 2671.

[dave_cheney.net, 2012-11-05 01:16:18]

Hello minux.ma@gmail.com, r@golang.org, rsc@golang.org (cc:
golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[r, 2012-11-05 06:59:44]

I thought we decided on test/bench/go

-rob

[dave_cheney.net, 2012-11-05 07:02:44]

Yes, but

package go

is a syntax error.

The workaround is to drop doc.go and move the remaining files into

package go_test

On Mon, Nov 5, 2012 at 5:59 PM, Rob Pike <r@golang.org> wrote:
> I thought we decided on test/bench/go
>
> -rob

[rsc, 2012-11-06 18:42:37]

Please make the directory test/bench/go.
The package can be 'package bench'.
Thanks.

[dave_cheney.net, 2012-11-07 00:14:16]

Hello minux.ma@gmail.com, r@golang.org, rsc@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[rsc, 2012-11-07 14:25:40]

LGTM

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go
File test/bench/go/asop_test.go (right):

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
test/bench/go/asop_test.go:12: }
I would suggest add a global

var x int

and then after each of these loops insert a use of the variable, like:

x += v

just so that a smarter compiler does not (1) complain that v is never really
used and (2) does not throw the entire loop away.

Thanks.

[r, 2012-11-07 16:12:40]

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go
File test/bench/go/asop_test.go (right):

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
test/bench/go/asop_test.go:9: func BenchmarkLSL(b *testing.B) {
it seems if you have these, you might as well finish the list.

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go
File test/bench/go/doc.go (right):

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go#newcode5
test/bench/go/doc.go:5: // Package bench contains low level code generation
micro benchmarks.
s/micro /micro-/

[dave_cheney.net, 2012-11-08 01:20:33]

Thank you for your comments. I know these benchmarks must appear trivial, but
they expose some codegen improvements that 5g can make in the future.

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go
File test/bench/go/asop_test.go (right):

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
test/bench/go/asop_test.go:9: func BenchmarkLSL(b *testing.B) {
On 2012/11/07 16:12:40, r wrote:
> it seems if you have these, you might as well finish the list.

Done.

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
test/bench/go/asop_test.go:12: }
On 2012/11/07 14:25:40, rsc wrote:
> I would suggest add a global
> 
> var x int
> 
> and then after each of these loops insert a use of the variable, like:
> 
> x += v
> 
> just so that a smarter compiler does not (1) complain that v is never really
> used and (2) does not throw the entire loop away.
> 
> Thanks.

Done.

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go
File test/bench/go/doc.go (right):

https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go#newcode5
test/bench/go/doc.go:5: // Package bench contains low level code generation
micro benchmarks.
On 2012/11/07 16:12:40, r wrote:
> s/micro /micro-/

Done.

[dave_cheney.net, 2012-11-09 22:35:37]

On 2012/11/08 01:20:33, dfc wrote:
> Thank you for your comments. I know these benchmarks must appear trivial, but
> they expose some codegen improvements that 5g can make in the future.
> 
> https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go
> File test/bench/go/asop_test.go (right):
> 
>
https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
> test/bench/go/asop_test.go:9: func BenchmarkLSL(b *testing.B) {
> On 2012/11/07 16:12:40, r wrote:
> > it seems if you have these, you might as well finish the list.
> 
> Done.
> 
>
https://codereview.appspot.com/6819087/diff/10001/test/bench/go/asop_test.go#...
> test/bench/go/asop_test.go:12: }
> On 2012/11/07 14:25:40, rsc wrote:
> > I would suggest add a global
> > 
> > var x int
> > 
> > and then after each of these loops insert a use of the variable, like:
> > 
> > x += v
> > 
> > just so that a smarter compiler does not (1) complain that v is never really
> > used and (2) does not throw the entire loop away.
> > 
> > Thanks.
> 
> Done.
> 
> https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go
> File test/bench/go/doc.go (right):
> 
>
https://codereview.appspot.com/6819087/diff/10001/test/bench/go/doc.go#newcode5
> test/bench/go/doc.go:5: // Package bench contains low level code generation
> micro benchmarks.
> On 2012/11/07 16:12:40, r wrote:
> > s/micro /micro-/
> 
> Done.

After consideration I don't think this benchmark needs to live inside the tree.
I will abandon this proposal and move these benchmarks to a 3rd party package.

[r, 2012-11-09 22:40:37]

I think they do belong.

-rob

[r, 2012-11-09 22:41:55]

https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go
File test/bench/go/divmul_test.go (right):

https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go...
test/bench/go/divmul_test.go:158: func BenchmarkMul4(b *testing.B) {
let's be pedantic and name these more accurately

BenchmarkIntMul4 etc.

we can add Float64Mul4 later if we want.

[dave_cheney.net, 2012-11-09 22:50:22]

Yes, I also realised I need to add benchmarks for int8,uint8,int16,uint16,etc. 

Thank you for your encouragement, I'll take another pass when I get home.  

On 10/11/2012, at 9:41, r@golang.org wrote:

> 
> https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go
> File test/bench/go/divmul_test.go (right):
> 
>
https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go...
> test/bench/go/divmul_test.go:158: func BenchmarkMul4(b *testing.B) {
> let's be pedantic and name these more accurately
> 
> BenchmarkIntMul4 etc.
> 
> we can add Float64Mul4 later if we want.
> 
> https://codereview.appspot.com/6819087/

[r, 2012-11-09 22:57:39]

It might make sense to generate the benchmarks rather than type them all in.

[mtj1, 2012-11-09 23:00:19]

I use M4 for things like this...

On Fri, Nov 9, 2012 at 2:57 PM, Rob Pike <r@golang.org> wrote:

> It might make sense to generate the benchmarks rather than type them all
> in.

Michael T. Jones | Chief Technology Advocate  | mtj@google.com |  +1
650-335-5765

[r, 2012-11-09 23:19:15]

I use Go for things like this.

-rob

[mtj1, 2012-11-09 23:23:45]

no doubt.

On Fri, Nov 9, 2012 at 3:19 PM, Rob Pike <r@golang.org> wrote:

> I use Go for things like this.
>
> -rob
>



-- 
Michael T. Jones | Chief Technology Advocate  | mtj@google.com |  +1
650-335-5765

[bradfitz, 2012-11-11 23:48:02]

https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go
File test/bench/go/divmul_test.go (right):

https://codereview.appspot.com/6819087/diff/5005/test/bench/go/divmul_test.go...
test/bench/go/divmul_test.go:176: func BenchmarkMagicMul10(b *testing.B) {
if v == 5, the result of this is 42, not 50.

[remyoudompheng, 2012-11-14 22:31:12]

Dave, are you going to finalize these microbenchmarks? I don't understand why
the CL is closed.

[dave_cheney.net, 2012-11-14 22:34:07]

As I've been working on this CL I've learnt that the task is larger then I
originally thought so I'm going to try again with a fresh proposal, soon, I
promise. 

On 15/11/2012, at 9:31, remyoudompheng@gmail.com wrote:

> Dave, are you going to finalize these microbenchmarks? I don't
> understand why the CL is closed.
> 
> http://codereview.appspot.com/6819087/