Array Access Time regression, significantly slower than slice

[Ugorji]

This looks like a bug, but wanted to run it by you guys first. 

When I run the benchmark at http://play.golang.org/p/p7IMmQPmOM, I expected that accessing the array would be faster. In Go 1.0, the speeds are equal. However, in Go 1.1, it seems that array access time regressed significantly (by about 20%).

Go 1.0.3:

BenchmarkArray  500000      5780 ns/op

BenchmarkSlice  500000      5780 ns/op

Go tip:

BenchmarkArray  200000      6970 ns/op

BenchmarkSlice  500000      5781 ns/op

I would have expected that accessing an array would be faster, as there is no pointer dereferencing necessary.

[Russ Cox]

Feel free to file a bug, but it will not be addressed before Go 1.1.

Using a pointer instead of a global will get most of the speed back. Making the array smaller (<4KB in size) will also help.

http://play.golang.org/p/7jU-7Sqd_x

[Rob Pike]

http://play.golang.org/p/-yeIKK7qRd

[Ugorji]

Thanks Russ and Rob.

I've verified that, as you said, most of the speed comes back when I make the array local to the function or as part of a local struct field. Using a pointer to the global array didn't seem to make a difference. 

I filed https://code.google.com/p/go/issues/detail?id=5108

Also, is there a short explanation for why a pointer to a global array may be faster than accessing the global array directly, even if we're not assigning it to anything (and thus not copying it)? 

Results from run:

arrlen: 1024

BenchmarkArrayGlobal 2000000       860 ns/op

BenchmarkArrayGlobalPtr 2000000       872 ns/op

BenchmarkSliceGlobal 5000000       741 ns/op

BenchmarkArrayLocal 2000000       862 ns/op

BenchmarkSliceLocal 2000000       941 ns/op

BenchmarkArrayStructField 1000000      1090 ns/op

BenchmarkSliceStructField 1000000      1249 ns/op

arrlen: 2048

BenchmarkArrayGlobal 1000000      1742 ns/op

BenchmarkArrayGlobalPtr 1000000      1738 ns/op

BenchmarkSliceGlobal 1000000      1454 ns/op

BenchmarkArrayLocal 1000000      1734 ns/op

BenchmarkSliceLocal 1000000      1836 ns/op

BenchmarkArrayStructField 1000000      2160 ns/op

BenchmarkSliceStructField 1000000      2488 ns/op

Thanks.

On Friday, March 22, 2013 1:02:43 PM UTC-4, Rob Pike wrote:

http://play.golang.org/p/-yeIKK7qRd 

 

[Rémy Oudompheng]

On 2013/3/22 Ugorji <ugo...@gmail.com> wrote:
> Thanks Russ and Rob.
>
> I've verified that, as you said, most of the speed comes back when I make
> the array local to the function or as part of a local struct field. Using a
> pointer to the global array didn't seem to make a difference.
>
> I filed https://code.google.com/p/go/issues/detail?id=5108
>
> Also, is there a short explanation for why a pointer to a global array may
> be faster than accessing the global array directly, even if we're not
> assigning it to anything (and thus not copying it)?

Do you observe a difference in benchmarks if you apply
https://codereview.appspot.com/7221077/ ?

Thanks,
Rémy.

[Ugorji Nwoke]

I just did a hg clpatch with that CL, and re-ran the benchmark. No difference.

Ugorji
An eagle, aspiring for greater heights ...

[Taru Karttunen]

On 22.03 09:46, Ugorji wrote:
> This looks like a bug, but wanted to run it by you guys first.
>
> When I run the benchmark at http://play.golang.org/p/p7IMmQPmOM, I expected
> that accessing the array would be faster. In Go 1.0, the speeds are equal.
> However, in Go 1.1, it seems that array access time regressed significantly
> (by about 20%).

I recently ended up rewriting an inner loop using pointers to byte arrays
in asm when 8g and 6g generated too slow code.

- Taru Karttunen