Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965052AbVINGlt (ORCPT ); Wed, 14 Sep 2005 02:41:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965051AbVINGlt (ORCPT ); Wed, 14 Sep 2005 02:41:49 -0400 Received: from fsmlabs.com ([168.103.115.128]:49604 "EHLO fsmlabs.com") by vger.kernel.org with ESMTP id S965050AbVINGls (ORCPT ); Wed, 14 Sep 2005 02:41:48 -0400 Date: Tue, 13 Sep 2005 23:48:22 -0700 (PDT) From: Zwane Mwaikambo To: Chris White cc: Margit Schubert-While , linux-kernel@vger.kernel.org Subject: Re: 2.6.13/14 x86 Makefile - Pentiums penalized ? In-Reply-To: <200509141414.08343.chriswhite@gentoo.org> Message-ID: References: <5.1.0.14.2.20050913075517.0259c498@pop.t-online.de> <200509141414.08343.chriswhite@gentoo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 962 Lines: 23 On Wed, 14 Sep 2005, Chris White wrote: > That's correct, gcc 3.4 started the -mtune flag. Chances are if you really > want the -mtune optimizations you're going to have to upgrade to gcc 3.4 or > greater. > > > This, of course, heavily penalizes P4's (the notorious inc/dec). > > Are you referring to cpu cycle counts? Is there certain code that causes the > kernel to perform that unfavorably by a large scale? It's documented as being suboptimal to use inc/dec due to it modifying all of eflags resulting in dependency related stalls. add/sub only modifies one bit of eflags so is more optimal. However there is a problem of increased code size with add/sub. But i've never benchmarked all of this ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/