From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21083 invoked by alias); 13 Nov 2010 21:09:34 -0000 Received: (qmail 21072 invoked by uid 22791); 13 Nov 2010 21:09:33 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_LV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Nov 2010 21:08:53 +0000 Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id oADL8oup016430 for ; Sat, 13 Nov 2010 13:08:50 -0800 Received: from gxk6 (gxk6.prod.google.com [10.202.11.6]) by kpbe13.cbf.corp.google.com with ESMTP id oADL8mG2010461 for ; Sat, 13 Nov 2010 13:08:48 -0800 Received: by gxk6 with SMTP id 6so3101407gxk.37 for ; Sat, 13 Nov 2010 13:08:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.91.27.32 with SMTP id e32mr5458540agj.37.1289682526698; Sat, 13 Nov 2010 13:08:46 -0800 (PST) Received: by 10.90.60.21 with HTTP; Sat, 13 Nov 2010 13:08:46 -0800 (PST) In-Reply-To: <4BD9B2EB.9060207@redhat.com> References: <4BD9B2EB.9060207@redhat.com> Date: Sat, 13 Nov 2010 23:15:00 -0000 Message-ID: Subject: Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64 From: Xinliang David Li To: Vladimir Makarov Cc: "gcc.gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg00298.txt.bz2 I re-measured the performance difference using trunk gcc and trunk clang/llvm on a core-2 box. -fno-strict-aliasing is added to gcc because clang/llvm's type based aliasing is not incomplete and not enabled by default. I also added -fomit-frame-pointer to clang/llvm as this is gcc's default. The base option is -O2. 32bit: 164.gzip 1210 1239 2.44% 175.vpr 1662 1621 -2.42% 181.mcf 2733 3109 13.75% 186.crafty 1812 1721 -5.00% 197.parser 1328 1289 -2.92% 253.perlbmk 2086 2580 23.67% 254.gap 1968 1912 -2.86% 255.vortex 1842 1965 6.66% 256.bzip2 1440 1553 7.82% 300.twolf 2284 2213 -3.08% 64bit: 164.gzip 1268 1320 4.15% 175.vpr 1605 1534 -4.42% 176.gcc 2203 2315 5.08% 181.mcf 1625 1737 6.85% 186.crafty 2411 2307 -4.30% 197.parser 1173 1166 -0.57% 252.eon 2245 2464 9.72% 253.perlbmk 2214 2444 10.37% 254.gap 1987 1978 -0.47% 255.vortex 2497 2422 -3.00% 256.bzip2 1585 1740 9.80% 300.twolf 2294 2281 -0.58% Though gcc leads LLVM in performance overrall, there are a couple of benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and twolf (32bit), vortex (64bit). This needs to be triaged. gcc miscompiles gcc and eon in 32bit -- is there a bug tracking the problem? Thanks, David On Thu, Apr 29, 2010 at 9:25 AM, Vladimir Makarov wro= te: > =A0GCC-4.5.0 and LLVM-2.7 were released recently. =A0To understand > where we stand after releasing GCC-4.5.0 I benchmarked it on SPEC2000 > for x86/x86-64 and posted the comparison of it with the > previous GCC releases and LLVM-2.7. > > =A0Even benchmarking SPEC2000 takes a lot of time on the fastest > machine I have. So I don't plan to use SPEC2006 for this in near > future. > > =A0You can find the comparison on > http://vmakarov.fedorapeople.org/spec/ (please just click links at the > bottom of the left frame starting with link "GCC release comparison"). > > =A0If you need exact numbers, please use the tables (the links to them > are also given) which were used to generate the corresponding bar > graphs. > > > =A0In general GCC-4.5.0 became faster (upto 10%) in -O2 mode. =A0This is > first considerable compilation speed improvement since GCC-4.2. > GCC-4.5.0 generates a better (1-2% in average upto 4% for x86-64 > SPECFP2000 in -O2 mode) code too in comparison with the previous > release. =A0That is not including LTO and Graphite which can gives even > more (especially LTO) in many cases. > > =A0GCC-4.5.0 has new big optimizations LTO and Graphite (more > accurately graphite was introduced in the previous release). > Therefore I ran additional benchmarks to test them. > > =A0LTO is a promising technology especially for integer benchmarks for > which it results in smaller and faster code. =A0But it might result in > degradations too on SPECFP2000 mainly because of big degradations on a > few benchmarks like wupwise or facerec. =A0Another annoying thing about > LTO, it considerably slows down the compiler. > > =A0Currently Graphite gives small improvements on x86 (one exception is > 2% for peak x86 SPECFP2000) and mostly degradation on x86_64 (with > maximum one more than 10% for SPECFP2000 because of big degradations > on mgrid and swim). =A0So further work is needed on the project because > it seems not mature yet. > > =A0As for LLVM, LLVM became slower (e.g. in comparison with llvm-2.5 on > 15%-50% for x86-64). =A0So the gap between compilation speed of GCC and > LLVM decreased and sometimes achieves 4% on x86_64 and 8% on x86 (both > for SPECInt2000 in -O2 mode). =A0May be I am wrong but I don't think > CLANG will improve this situation significantly (in -O2 and -O3 mode) > because optimizations still take most of time of any serious > optimizing compiler. > > =A0LLVM did a progress in code performance especially for floating > point benchmarks. =A0But the gap between LLVM-2.7 and GCC-4.5 in peak > performance (not including GCC LTO and Graphite) still 6-7% on > SPECInt200 and 13-17% on SPECFP2000. > > =A0In general, IMHO GCC-4.5.0 is a good and promising release. > >