This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v1.1] Randomize memcpy benchmark addresses.


On 5 September 2013 12:32, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Thu, Sep 05, 2013 at 08:41:02AM +0100, Will Newton wrote:
>> > -
>> > -  printf ("Length %4zd, alignment %2zd/%2zd:", len, align1, align2);
>> > +  printf ("Length %4zd, aligned %c/%c:", len, align1 ? 'y' : 'n', align2 ? 'y' : 'n');
>>
>> This means we no longer print what the buffer alignment is which makes
>> results analysis impossible.
>>
> Could you elaborate.

The current benchmark shows the performance for memcpy for a given
length and source/dest alignment. This can be analyzed to see where
performance is strongest and weakest. If we do not print the alignment
of the buffers for each test then we can't do this analysis.

>> >    test_init ();
>> > +  buf1 = malloc (2 * SIZE + 4096);
>> > +  buf2 = malloc (2 * SIZE + 4096);
>> > +  buf1 = buf1 + 4096 - ((uintptr_t) buf1) % 4096;
>> > +  buf2 = buf2 + 4096 - ((uintptr_t) buf1) % 4096;
>> > +
>>
>> What is 4096? We should avoid magic constants.
>>
>> buf1 and buf2 have already been allocated in bench-string.h. We should
>> make any solution work with that header and work for all string
>> benchmarks, not just one at a time.
>>
> Well buf2 was allocated as
>
>  buf2 = mmap (0, 2 * page_size ...
>
> which is too small for this benchmark, so it needs to get changed.

I think if we need to expand the buffer we should do it in one place.

-- 
Will Newton
Toolchain Working Group, Linaro


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]