Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761845AbZATRnX (ORCPT ); Tue, 20 Jan 2009 12:43:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757706AbZATRnI (ORCPT ); Tue, 20 Jan 2009 12:43:08 -0500 Received: from yw-out-2324.google.com ([74.125.46.31]:11434 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754995AbZATRnF (ORCPT ); Tue, 20 Jan 2009 12:43:05 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=krCnMYyP4jcmWpyyUoh/PHtQJbufIgfTbAanBSGwgFsOPEclGiTosBttNtD6aP+O5D f7PRvwXh3GQEWsNPrTLrM38teCSq7VqrpLLAC2p2v20zIHVRob/i+nDvXcKbI2A2EJuh mCKw0s7MA+a3gL7ehcSZVbkrnzcafpOpfbKWo= Message-ID: Date: Tue, 20 Jan 2009 17:43:02 +0000 From: "Miguel F Mascarenhas Sousa Filipe" To: "Linus Torvalds" Subject: Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Cc: "Nick Piggin" , "Ingo Molnar" , "Bernd Schmidt" , "Andi Kleen" , "David Woodhouse" , "Andrew Morton" , "Harvey Harrison" , "H. Peter Anvin" , "Chris Mason" , "Peter Zijlstra" , "Steven Rostedt" , paulmck@linux.vnet.ibm.com, "Gregory Haskins" , "Matthew Wilcox" , "Linux Kernel Mailing List" , linux-fsdevel , linux-btrfs , "Thomas Gleixner" , "Peter Morreale" , "Sven Dietrich" , jh@suse.cz In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090112005228.GS26290@one.firstfloor.org> <496B86B5.3090707@t-online.de> <20090112193201.GA23848@one.firstfloor.org> <496BBE27.2020206@t-online.de> <20090119001345.GA9880@elte.hu> <20090119062212.GC22584@wotan.suse.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2489 Lines: 64 On Mon, Jan 19, 2009 at 9:01 PM, Linus Torvalds wrote: > > > On Mon, 19 Jan 2009, Nick Piggin wrote: >> >> I want to know what is the problem with the restrict keyword? >> I'm sure I've read Linus ranting about how bad it is in the >> past... > > No, I don't think I've ranted about 'restrict'. I think it's a reasonable > solution for performance-critical code, and unlike the whole type-aliasing > model, it actually works for the _sane_ cases (ie doing some operation > over two arrays of the same type, and letting the compiler know that it > can access the arrays without fearing that writing to one would affect > reading from the other). > > The problem with 'restrict' is that almost nobody uses it, and it does > obviously require programmer input rather than the compiler doing it > automatically. But it should work well as a way to get Fortran-like > performance from HPC workloads written in C - which is where most of the > people are who really want the alias analysis. while working in my college thesis, a fortran HPC workload (10k lines of fortran), converted to C resulted in performance speedups. this was with gcc 3.4. A simple f2c conversion + adaptations, resulted in a considerable speedup. (20% IIRC). The conversion was not done by performance reasons, the extra performance was simply a unexpected, but quite nice outcome. Just to let you guys know, that even with gcc3.4, gcc of C code ran faster than gfortran of the equiv. fortran code. ... pushing the optimization engine further (-march tunning and -O3) resulted in bad data. But I can't swear by the correctness of some of the computations with REAL's made in the original fortran code. > >> it seems like a nice opt-in thing that can be used where the aliases are >> verified and the code is particularly performance critical... > > Yes. I think we could use it in the kernel, although I'm not sure how many > cases we would ever find where we really care. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Miguel Sousa Filipe -- 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/