From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6652 invoked by alias); 21 Apr 2002 10:38:28 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6644 invoked from network); 21 Apr 2002 10:38:27 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 21 Apr 2002 10:38:27 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 88ECC1E25C; Sun, 21 Apr 2002 12:38:26 +0200 (MEST) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 16zEbf-0006Ez-00; Sun, 21 Apr 2002 12:30:07 +0200 Mail-Copies-To: never To: Michel LESPINASSE Cc: gcc list Subject: Re: GCC performance regression - up to 20% ? References: <20020421005718.GA16378@zoy.org> From: Andreas Jaeger Date: Sun, 21 Apr 2002 03:41:00 -0000 In-Reply-To: <20020421005718.GA16378@zoy.org> (Michel LESPINASSE's message of "Sat, 20 Apr 2002 17:57:18 -0700") Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg01036.txt.bz2 Michel LESPINASSE writes: > Hi, > > I have downloaded the latest 3.1 snapshot (20020415) and ran some > performance tests. So far I've been impressed by the FP performance, > but kinda disappointed by the integer performance. > > The benchmarks I've run are two libraries I maintain, libmpeg2 and > liba52. These are used by several open-source dvd players, and are > quite CPU intensive (especially libmpeg2). So here are my results, > using gcc 2.95 as a reference: > > First the good news: liba52 (mostly FP intensive workload) > on athlon tbird 950, using -mcpu=pentiumpro: > gcc-3.0 is between 4.5% and 6.5% faster than 2.95.4 depending on streams > gcc-3.1 snapshot is between 8% and 9.5% faster than 2.95.4 > from these measurements 3.1 has a very nice performance, very close to > intel's icc. Great work ! Also using -march=athlon-tbird and > generating sse code, I can get yet a few extra % of performance. > > Now the bad news: for libmepg2, which is an integer-only workload, I > get a 10% to 20% performance regression between 2.95.4 and 3.1... 3.0 > was already slower than 2.95.4, but 3.1 seems to be worse for this > workload at least. > > libmpeg2, on athlon tbird 950, with mmx optimizations: > gcc-3.0 is about 2% slower than 2.95.4 > gcc-3.1 snapshot is about 10% slower than 2.95.4 > > libmpeg2, on athlon tbird 950, using pure C code: > gcc-3.0 is about 4.5% slower than 2.95.4 > gcc-3.1 snapshot is about 5.5% slower than 2.95.4 > > libmpeg2, on celeron 366, with mmx optimizations: > gcc-3.0 is about 4% slower than 2.95.4 > gcc-3.1 snapshot is about 20.5% slower than 2.95.4 (!!!!) > > These results are all very repeatable. the celeron 366 results are the > most worrying, as this processor already has borderline performance > for decoding mpeg2 streams. > > Is there a known performance regression in current GCCs (say, do they > get lower SPECint scores ?) or is it only with my code ? Can you distill a test case that is as small as possible (the optimal way would be just the loop that causes the problem) and show it to us? That way it's much easier to discuss the issues and start looking into what needs to be done. > Also, is there anything I could do in my code to enhance performance > with newer gcc versions ? One thing I noticed is that 3.1 snapshot > produces less inlining than 3.0 or 2.95. This probably accounts for > some of the slowdown I see when using mmx optimizations, as my mmx > routines are written using a few routines that I really expect to get > inlined. Is there any way I can get back control about that, so that > gcc honours the inline keyword ? I have not managed to do this either. Try -finline-limit=2000 but check the manual for the exact name of the switch. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj