From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27652 invoked by alias); 17 Jan 2004 22:00:23 -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 27640 invoked from network); 17 Jan 2004 22:00:22 -0000 Received: from unknown (HELO mailout08.sul.t-online.com) (194.25.134.20) by sources.redhat.com with SMTP; 17 Jan 2004 22:00:22 -0000 Received: from fwd00.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1AhyUK-0003qp-05; Sat, 17 Jan 2004 23:00:16 +0100 Received: from kolme (bRp6NyZ-oeangwf5JgmadoTdTNZcgJuHyqS9YC4u001NVR-NQy8dr5@[80.138.175.50]) by fmrl00.sul.t-online.com with esmtp id 1AhyUB-0fT5Hc0; Sat, 17 Jan 2004 23:00:07 +0100 Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy) by kolme with esmtp (Exim 3.35 #1 (Debian)) id 1AhyU7-0000dO-00; Sat, 17 Jan 2004 23:00:03 +0100 Received: from richard (helo=localhost) by goofy with local-esmtp (Exim 3.36 #1 (Debian)) id 1AhyU9-00016L-00; Sat, 17 Jan 2004 23:00:05 +0100 Date: Sat, 17 Jan 2004 22:00:00 -0000 From: Richard Guenther To: Jan Hubicka cc: Scott Robert Ladd , gcc mailing list Subject: Re: povray: Revised numbers In-Reply-To: <20040117214855.GQ26819@atrey.karlin.mff.cuni.cz> Message-ID: References: <4009AA3F.2020208@coyotegulch.com> <20040117214855.GQ26819@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Seen: false X-ID: bRp6NyZ-oeangwf5JgmadoTdTNZcgJuHyqS9YC4u001NVR-NQy8dr5@t-dialin.net X-SW-Source: 2004-01/txt/msg01124.txt.bz2 On Sat, 17 Jan 2004, Jan Hubicka wrote: > > Here are revised numbers for my povray test, based on comments both > > public and private: > > > > compile benchmark > > time time > > -------- --------- > > gcc mainline 1:43 7:59 > > w/ -mfpmath=sse 1:46 6:30 > > > > gcc tree-ssa 1:46 7:35 > > w/ -mfpmath=sse ** SEG fault ** > > > > icc 8.0 1:53 5:50 > > > Thanks for testing. > If you have code where -mfpmath=sse lose considerably on mainline > (3.3 branch had very fresh SSA implementation and lacked P4 tunning), I > would be interested in seeing it. As can Scott, so can I ;) Here are some benchmarks for my favorite POOMA based application. For current 3.3, 3.4 and Intel 8.0 (tree-ssa ICEs). For a fair comparison, I dropped __attribute__((leafify)) in one round of testing, as I cannot hack Intel 8.0 for my needs. Compiler flags are -O2 -funroll-loops -ffast-math -march=athlon for gcc and -O2 -ip for icc. Tests are done on an Athlon 1GHz with 1GB ram. gcc 3.3 is 3.3.3 20040112, gcc 3.4 is 3.4.0 20040114, icc 8.0 is build 20031231Z. compile time run time binary size (static, stripped) gcc3.3 6m57s 1m24s 2877232 8m23s 0m34s 2963408 __attribute__((leafify)) gcc3.4 3m41s 1m10s 2584088 5m04s 0m39s 2682520 __attribute__((leafify)) icc8.0 12m41s 0m42s 5046476 So what one can clearly see, Intel 8.0 looses all the way down in compilation speed and binary size, but is a lot better in runtime than plain gcc. And it should be clear, why I'm still maintaining the leafify attribute patch... :) The leafify test also shows that mainline/3.4 has somewhat regressed in speed compared to 3.3 - performance I expect to get back after rtlopt been merged. Together with the new parser and improved ISO compliance I'm quite happy with 3.4. I'd love to test tree-ssa, but that doesn't build my application at the moment (and I don't have the leafify attribute fixed wrt the latest cgraph changes yet). Richard.