From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1278 invoked by alias); 27 Nov 2007 18:51:49 -0000 Received: (qmail 1270 invoked by uid 22791); 27 Nov 2007 18:51:48 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Nov 2007 18:51:44 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lARIpg7E021496 for ; Tue, 27 Nov 2007 13:51:42 -0500 Received: from zebedee.littlepinkcloud.COM (vpn-14-8.rdu.redhat.com [10.11.14.8]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lARIpfj7027966; Tue, 27 Nov 2007 13:51:41 -0500 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.8/8.13.5) with ESMTP id lARIpehm011837; Tue, 27 Nov 2007 18:51:40 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.8/8.13.5/Submit) id lARIpdWc011834; Tue, 27 Nov 2007 18:51:39 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18252.26426.789810.865672@zebedee.pink> Date: Tue, 27 Nov 2007 19:21:00 -0000 From: Andrew Haley To: Sven Eschenberg Cc: gcc-help@gcc.gnu.org Subject: Re: reduce compilation times? In-Reply-To: <474C6125.6080407@cs.uni-frankfurt.de> References: <13967871.post@talk.nabble.com> <18251.60312.968806.16303@zebedee.pink> <474C3737.4040204@cs.uni-frankfurt.de> <18252.17718.958557.592362@zebedee.pink> <474C6125.6080407@cs.uni-frankfurt.de> X-Mailer: VM 7.19 under Emacs 22.0.93.1 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00314.txt.bz2 Sven Eschenberg writes: > I am not sure about ccache, but I thought it does some file and > preprocessing caching (not exactly sure, how it works, I thought, > it kinda gets called instead of the preprocessor or at least before > the PP). That's right: if the file has been compiled before, ccache bypasses compilation entirely. > Anyway, what I meant: Compiling a package like firefox, glibc > etc. with ccache gives you some speed increase, but it is small > compared to uncompressing the source directly into a ram disk and > build everything in there. That sounds pretty surprising to me. How is a RAM disk going to be so much faster than. say, /tmp? I suppose there's no overhead of writing the files back to disk after updating them, but thet's usually done in the background anyway. "make -jN" is usually enough to swallow up any rotational latency. But when I'm compling, all CPU cores are usually at 90% plus; the compiler certainly isn't waiting for disk. That RAM disk is going to get me 10% more at best. > Combining both didn't seem to give additional reproduceable > benefit, but I gotta admit, never tried to put ccache's data into a > ramdisk too, since I don't have enough ram for that on sufficently > big enough packages. If -j2 speeds things, it's mostly because of > the kernel's scheduling, I assume. > > The only box I got left, which is Uniprocessore and doesn't have > HT/Multiple cores didn't really compile faster with -j2 - Then > again it is a server, which has a certain minor load anyway all the > time, that's why I assume -j2 on Uniprocessor only benefits from > scheduling strategies. The main purpose of -j2 on a uniprocessor is to absorb any disk latency: when one process blocks because a file is not ready, another process has something useful to do. It's not a huge win when building gcc, but it is significant. It is very usefule when building on an NFS-mounted drive. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903