[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] (x)memcoll: performance improvement when input is known to b
From: |
Pádraig Brady |
Subject: |
Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited. |
Date: |
Wed, 21 Apr 2010 09:46:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 |
On 14/03/10 14:24, Bruno Haible wrote:
> Hi Chen,
>
>> ... it was consistently (as in every run for 20 runs) faster, and thus I've
>> included it in the patch.
>
> Thanks. I'll wait for the FSF notification that the legal papers have arrived.
Hi Chen, The copyright stuff is sorted now I presume?
>
>> This is not what I expected at all, and I'm having a hard time coming up with
>> a reason why this is
>
> 15 years ago, on a Linux/x86 machine, I could measure CPU performance with
> about 1% precision (with 3 or 5 runs of a program). At the same time, on
> Windows, I got only about 5% precision.
>
> On SPARC CPUs, sometimes the same program was 30% slower than the previous
> day.
> So, such platforms were unusable for benchmarking.
lol
> Today, x86 CPUs have additional complexity: multiple CPU cores that fight over
> the memory bus; hyperthreads. The Linux memory management has become more
> complex as well (the kernel actively swapping out some pages). Sometimes
> you're
> even running inside a virtual machine. I usually can get only about 2% of
> precision nowadays.
That's why I keep my single core laptop for benchmarking.
After a suspend/resume cycle or large memory thrashing
performance can vary quite a bit, but for multiple runs
within a particular session, it's quite stable.
cheers,
Pádraig.
- Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.,
Pádraig Brady <=