From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5340 invoked by alias); 12 Nov 2011 10:10:12 -0000 Received: (qmail 5326 invoked by uid 22791); 12 Nov 2011 10:10:10 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 Nov 2011 10:09:55 +0000 From: "grygoriy.fuchedzhy at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/51078] [PATCH] performance improvement of std::count algorithm Date: Sat, 12 Nov 2011 12:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: grygoriy.fuchedzhy at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg01281.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51078 --- Comment #14 from Grygoriy Fuchedzhy 2011-11-12 10:09:52 UTC --- (In reply to comment #13) > I would say, the next step, is analyzing why: std::count seems a very simple > algorithm, no aliasing issues for example, compiler should be able to unroll, > maybe vectorize too, and everything else, without having to fiddle with the > code in an ad-hoc way. I completely agree that analizing why is necessary, but this probably should be done in separate bug?(should I open it?) As regarding current bug: it seems that automatic loop unrolling is far from being considered "stable" or "recommended" optimization, so this patch may improve performance until this optimization become commonly used. By the way, manually unrolled std::find, one of old algorithms you mentioned also performs significantly better than version without loop unrolling.