From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25046 invoked by alias); 1 Aug 2011 18:04:24 -0000 Received: (qmail 25037 invoked by uid 22791); 1 Aug 2011 18:04:23 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from eng.riverbed.com (HELO smtp2.riverbed.com) (208.70.196.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Aug 2011 18:04:09 +0000 Received: from unknown (HELO tlssmtp) ([10.16.4.52]) by smtp2.riverbed.com with ESMTP; 01 Aug 2011 11:04:09 -0700 Received: from [10.35.81.130] (unknown [216.52.20.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tlssmtp (Postfix) with ESMTP id E5AF56B8B9; Mon, 1 Aug 2011 11:04:08 -0700 (PDT) Message-ID: <4E36EA98.8050101@riverbed.com> Date: Mon, 01 Aug 2011 18:04:00 -0000 From: Oleg Smolsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Benjamin Redelings I CC: gcc@gcc.gnu.org Subject: Re: Performance degradation on g++ 4.6 References: <4E34059C.3060209@nescent.org> In-Reply-To: <4E34059C.3060209@nescent.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2011-08/txt/msg00015.txt.bz2 Hi Benjamin, On 2011/7/30 06:22, Benjamin Redelings I wrote: > I had some performance degradation with 4.6 as well. > > However, I was able to cure it by using -finline-limit=800 or 1000 I > think. However, this lead to a code size increase. Were the old > higher-performance binaries larger? Yes, the older binary for the degraded test was indeed larger: 107K vs 88K. However, I have just re-built and re-run the test and there was no significant difference in performance. IE the degradation in "simple_types_constant_folding" test remains when building with -finline-limit=800 (or =1000) > IIRC, setting finline-limit=n actually sets two params to n/2, but I > think you may only need to change 1 to get the old performance back. > --param max-inline-insns-single defaults to 450, but --param > max-inline-insns-auto defaults to 90. Perhaps you can get the old > performance back by adjusting just one of these two parameters, or by > setting them to different values, instead of the same value, as would > be achieved by -finline-limit. "--param max-inline-insns-auto=800" by itself does not help. The "--param max-inline-insns-single=800 --param max-inline-insns-auto=1000" combination makes no significant difference either. BTW, some of these tweaks increase the binary size to 99K, yet there is no performance increase. Oleg.