From owner-cvs-src@FreeBSD.ORG Tue Jul 22 15:56:46 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94E3E37B401; Tue, 22 Jul 2003 15:56:46 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3396B43FA3; Tue, 22 Jul 2003 15:56:43 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6MMuZV3030549; Tue, 22 Jul 2003 22:56:35 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6MMuY5H016120; Wed, 23 Jul 2003 00:56:34 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Alan L. Cox" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 17:39:01 CDT." <3F1DBD05.A4886D5E@imimic.com> Date: Wed, 23 Jul 2003 00:56:34 +0200 Message-ID: <16119.1058914594@critter.freebsd.dk> cc: src-committers@FreeBSD.org cc: Bosko Milekic cc: Bruce Evans cc: cvs-src@FreeBSD.org cc: Steve Kargl cc: cvs-all@FreeBSD.org cc: Marcel Moolenaar Subject: Re: cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 22:56:46 -0000 In message <3F1DBD05.A4886D5E@imimic.com>, "Alan L. Cox" writes: >Poul-Henning Kamp wrote: >> Compiling the file with and without the inline, and forcing GCC >> to respect the inline finds: >> >> text data bss dec hex filename >> inlined: 17408 76 420 17904 45f0 vm_object.o >> regular: 14944 76 420 15440 3c50 vm_object.o >> ----- >> 2464 >> >Again, in the case of vm_object_backing_scan(), code size is a >bad predictor of inlining's effect. Inlining is being used to achieve a >form of code specialization that will actually reduce the size of the >code that is *executed*. 00001ef0 t vm_object_backing_scan 000023e0 t vm_object_qcollapse The non-inlined function is 1264 bytes, it is inlined 3 times, so best case you have saved up to 1328 bytes from being (mostly) branched over. On the other hand, you have 2464 bytes to cache rather than 1264 bytes to cache. If you had said "I ran a benchmark and it is in fact faster" that would make me conceeded right away. >In conclusion, my point is not that you should stop what you're doing. >It is rather that there are exceptional cases where gcc is doing the >wrong thing and we should have an override to force inlining that can be >applied. I agree that there are exceptional cases, I agree that we need some sort of __inline_damnit, but I still request that we only used it when we know for a fact that there is an actual benefit. And the only two criteria I think are trivial to use for proving an actual benefit is: 1. less code is generated. 2. it runs faster in tests. I am very reluctant to accept "a speculated benefit" when there is as strong a counter indication as 2k extra code segment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.