code review 111350043: runtime: add Benchmark[Clear|Copy]Fat[16|24]

runtime: add Benchmark[Clear|Copy]Fat[16|24]

These benchmarks are important for performance. When compiling the stdlib:

* 77.1% of the calls to sgen (copyfat) are for 16 bytes; another 8.7% are for 24 bytes. (The next most common is 32 bytes, at 5.7%.)
* Over half the calls to clearfat are for 16 or 24 bytes.

[josharian, 2014-07-18 18:25:55]

Hello golang-codereviews@googlegroups.com (cc: khr@golang.org),

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

[josharian, 2014-07-18 18:27:19]

I have follow-up CLs that improve these benchmarks. I will mail them, and other
related work, when the compiler tree thaws.

[khr, 2014-07-18 18:55:23]

On 2014/07/18 18:27:19, josharian wrote:
> I have follow-up CLs that improve these benchmarks. I will mail them, and
other
> related work, when the compiler tree thaws.

Why does one set use [24]byte and the other use [24/4]int32?

[josharian, 2014-07-18 19:11:36]

On 2014/07/18 18:55:23, khr wrote:
> On 2014/07/18 18:27:19, josharian wrote:
> > I have follow-up CLs that improve these benchmarks. I will mail them, and
> other
> > related work, when the compiler tree thaws.
> 
> Why does one set use [24]byte and the other use [24/4]int32?

I was following local precedent. All the existing ClearFat benchmarks use byte
arrays, and all the existing CopyFat benchmarks use uint32 arrays. The CopyFat
benchmarks were changed from byte arrays to uint32 arrays in CL 92760044, which
you authored. I see no hints in that CL as to why.

I tried converting all the Fat benchmarks both directions, and it had no impact
on the numbers either way on my laptop (6g). I'd be happy to send a follow-up CL
making the benchmarks uniform, if you have a strong opinion about which style
you prefer (or if there's an underlying reason to).

[khr1, 2014-07-18 19:17:12]

Maybe there was an issue with alignment testing that precluded faster
copies on arm for [x]bytes.  I don't remember.

In any case, a followup CL is fine.

LGTM.



On Fri, Jul 18, 2014 at 12:11 PM, <josharian@gmail.com> wrote:

> On 2014/07/18 18:55:23, khr wrote:
>
>> On 2014/07/18 18:27:19, josharian wrote:
>> > I have follow-up CLs that improve these benchmarks. I will mail
>>
> them, and
>
>> other
>> > related work, when the compiler tree thaws.
>>
>
>  Why does one set use [24]byte and the other use [24/4]int32?
>>
>
> I was following local precedent. All the existing ClearFat benchmarks
> use byte arrays, and all the existing CopyFat benchmarks use uint32
> arrays. The CopyFat benchmarks were changed from byte arrays to uint32
> arrays in CL 92760044, which you authored. I see no hints in that CL as
> to why.
>
> I tried converting all the Fat benchmarks both directions, and it had no
> impact on the numbers either way on my laptop (6g). I'd be happy to send
> a follow-up CL making the benchmarks uniform, if you have a strong
> opinion about which style you prefer (or if there's an underlying reason
> to).
>
>
> https://codereview.appspot.com/111350043/
>

[josharian, 2014-07-18 19:18:40]

*** Submitted as https://code.google.com/p/go/source/detail?r=696aba5c3fff ***

runtime: add Benchmark[Clear|Copy]Fat[16|24]

These benchmarks are important for performance. When compiling the stdlib:

* 77.1% of the calls to sgen (copyfat) are for 16 bytes; another 8.7% are for 24
bytes. (The next most common is 32 bytes, at 5.7%.)
* Over half the calls to clearfat are for 16 or 24 bytes.

LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews
https://codereview.appspot.com/111350043