Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261464AbUJaBnb (ORCPT ); Sat, 30 Oct 2004 21:43:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261465AbUJaBnb (ORCPT ); Sat, 30 Oct 2004 21:43:31 -0400 Received: from fw.osdl.org ([65.172.181.6]:965 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261464AbUJaBn1 (ORCPT ); Sat, 30 Oct 2004 21:43:27 -0400 Date: Sat, 30 Oct 2004 18:43:21 -0700 (PDT) From: Linus Torvalds To: Andi Kleen cc: Denis Vlasenko , linux-kernel@vger.kernel.org Subject: Re: Semaphore assembly-code bug In-Reply-To: <20041031003934.GA19396@wotan.suse.de> Message-ID: References: <417550FB.8020404@drdos.com.suse.lists.linux.kernel> <200410301228.42561.vda@port.imtp.ilyichevsk.odessa.ua> <20041031003934.GA19396@wotan.suse.de> 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: 1352 Lines: 38 On Sun, 31 Oct 2004, Andi Kleen wrote: > > Using the long stack setup code was found to be a significant > win when enough registers were saved (several percent in real benchmarks) > on K8 gcc. For _what_? Real applications, or SpecInt? The fact is, SpecInt is not very interesting, because it has almost _zero_ icache footprint, and it has generally big repeat-rates, and to make matters worse, you are allowed (and everybody does) warm up the caches by running before you actually do the benchmark run. _None_ of these are realistic for real life workloads. > It speed up all function calls considerably because it > eliminates several stalls for each function entry/exit. .. it shaves off a few cycles in the cached case, yes. > The popls will all depend on each other because of their implicied > reference to esp. Which is only true on moderately stupid CPU's. Two pop's don't _really_ depend on each other in any real sense, and there are CPU's that will happily dual-issue them, or at least not stall in between (ie the pop's will happily keep the memory unit 100% busy). Linus - 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/