From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29626 invoked by alias); 18 Aug 2004 01:33:49 -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 29619 invoked from network); 18 Aug 2004 01:33:48 -0000 Received: from unknown (HELO caip.rutgers.edu) (128.6.236.10) by sourceware.org with SMTP; 18 Aug 2004 01:33:48 -0000 Received: from caip.rutgers.edu (localhost [127.0.0.1]) by caip.rutgers.edu (8.12.11/8.12.9) with ESMTP id i7I1Xkmw006916; Tue, 17 Aug 2004 21:33:46 -0400 (EDT) Received: (from ghazi@localhost) by caip.rutgers.edu (8.12.11/8.12.9/Submit) id i7I1XkkY006915; Tue, 17 Aug 2004 21:33:46 -0400 (EDT) Date: Wed, 18 Aug 2004 01:35:00 -0000 From: "Kaveh R. Ghazi" Message-Id: <200408180133.i7I1XkkY006915@caip.rutgers.edu> To: coyote@coyotegulch.com Subject: Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004 Cc: gcc@gcc.gnu.org References: <411F794B.8090704@coyotegulch.com> X-SW-Source: 2004-08/txt/msg00849.txt.bz2 > 3.2.3 3.3.3 3.4.2 3.5.0 icc 8 > ----- ----- ----- ----- ----- > alma time: 39.5 39.6 39.0 22.3 13.3 > arco time: 27.8 26.9 25.1 27.3 27.7 > evo time: 43.1 42.9 42.4 42.1 30.1 > fft time: 27.4 27.4 27.0 27.3 30.2 > huff time: 23.1 23.6 18.0 13.1 16.3 > lin time: 19.1 19.1 18.9 19.5 19.1 > mat1 time: 7.4 7.5 7.5 7.5 7.4 > mole time: 31.6 30.5 30.9 31.3 5.1 > tree time: 30.9 32.3 28.3 25.6 28.8 > ---------- ----- ----- ----- ----- ----- > total time: 249.9 249.7 237.1 215.8 178.0 > > Since we're interested in generated code speed, all compiles were performed with the option set used by typical users: > > -O3 -ffast-math -march=pentium4 Hi Scott, Does your glibc contain the fixes posted here? http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01720.html It seems like Jakub predicts these fixes will be in glibc 2.3.4 which is the version you listed you have, but I wanted to be sure. Otherwise, it's not a fair test if the well known glibc trig "inlines" are killing gcc vs icc. If you have the fixes, I'm curious to know if Jakub got all the builtin cases gcc handles. You can easily tell by looking at the -E output for alma with 3.5.0 and checking for asm statements. (There shouldn't be any because I think all the trig funcs alma used were done.) Conversely, if -D__NO_MATH_INLINES improves alma, then he missed a few. I'd also like to know how icc works around this issue. Does it provide it's own C library? Does it use glibc but disable the inlines somehow? Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu