This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Limit std::sort comparisons on small list
- From: David Kastrup <dak at gnu dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 08 Oct 2013 22:06:52 +0200
- Subject: Re: Limit std::sort comparisons on small list
- Authentication-results: sourceware.org; auth=none
- References: <52409F6F dot 7040609 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309232317070 dot 4088 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 10 dot 1309290031480 dot 4104 at laptop-mg dot saclay dot inria dot fr> <CA+jCFLvhxsbAu+3Ti07pL0hg7UJfDgBzzbAV5EMwvMUtaa1ZYQ at mail dot gmail dot com> <5249A299 dot 3060103 at oracle dot com> <CA+jCFLu-r8SCWhSv-h+vrcSbWXWAXEiFxVhfNTUpworkXMJsRw at mail dot gmail dot com> <524B322A dot 1090703 at gmail dot com> <C62520F9-5A70-406F-AAE8-0F7900034CC3 at oracle dot com> <524DCDC7 dot 1000801 at gmail dot com> <524DD93A dot 30100 at oracle dot com> <524DDACB dot 7010207 at oracle dot com> <524F2892 dot 3040204 at gmail dot com> <CA+jCFLu-9cj544=u+cKub_RPQ4hbxDWofV6focJTNhd0cKXuCw at mail dot gmail dot com> <52546313 dot 8010303 at gmail dot com>
François Dumont <frs.dumont@gmail.com> writes:
> On 10/07/2013 02:56 PM, Christopher Jefferson wrote:
>> I'm unconvinced by this optimisation. I have already heard the
>> occasional complaint that libstdc++ is quite large, so even in this
>> tiny case I would be unsure about producing a very small code size
>> increase for a very small performance improvement.
>>
>> On 4 October 2013 21:44, François Dumont <frs.dumont@gmail.com> wrote:
>>> so with a limited number of elements we can see the gain even if it looks
>>> like for the sort algo it is limited to 1 comparison. For stable_sort it is
>>> better.
>>>
>>> François
>>>
>
> I am surprised, code bloat is indeed the only drawback of this patch,
> but isn't sometimes the compiler unrolling loop itself ? You can even
> see in __find_if implementation that we sometimes unroll loops
> manually so I guess that in general it is rather good for
> performance. Especially in this case with the first iteration that is
> better taken care separately.
>
> Of course it is a small optimization but also a rather trivial one. I
> am sorry that I can't check the result on the generated code but I am
> quite sure that the "code bloat" will be even smaller than the
> optimization.
The important cases are the large ones. Rolling out of cache because of
exceptions can really make a difference. If your times are O(n lg n),
and you make special exceptions to speed up n operations, then it's easy
to get a hit on n ((lg n) -1) operations.
--
David Kastrup