From owner-svn-src-head@FreeBSD.ORG Tue Jun 3 12:35:57 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F2C36B3; Tue, 3 Jun 2014 12:35:57 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 428D22459; Tue, 3 Jun 2014 12:35:56 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id CB02BD44FBD; Tue, 3 Jun 2014 22:04:09 +1000 (EST) Date: Tue, 3 Jun 2014 22:04:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore Subject: Re: svn commit: r266974 - in head/sys: dev/dc dev/fxp dev/mii dev/netmap kern net In-Reply-To: <1401735801.20883.103.camel@revolution.hippie.lan> Message-ID: <20140603212553.P1018@besplex.bde.org> References: <201406021754.s52Hsd1B039620@svn.freebsd.org> <1401735801.20883.103.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=U6SrU4bu c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=A1emcgW2bmQA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=vIjQHYS3pqU84ZPjkucA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 Cc: Adrian Chadd , Marcel Moolenaar , "svn-src-all@freebsd.org" , Marcel Moolenaar , "src-committers@freebsd.org" , "svn-src-head@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:35:57 -0000 On Mon, 2 Jun 2014, Ian Lepore wrote: > On Mon, 2014-06-02 at 11:42 -0700, Marcel Moolenaar wrote: >> On Jun 2, 2014, at 11:27 AM, Adrian Chadd wrote: >> >>> .. and actually, bikeshedding for a moment, would we be able to move a >>> lot of these accessor methods over to inlines? Would that break the >>> Juniper way of doing things? >> >> That would definitely break Juniper as it doesn't give a stable >> ABI. >> >> I've suggested an approach that allows for both, but it was deemed >> unnecessary. The argument being that the function call overhead is >> negligible. >> >> We can always revisit that decision if needed... I thought it was obviously necessary. Juniper gets the stable ABI and slowness, while the default is to have the same code as before, except it is obfuscated by macros or inline functions. > In my experience, function call overhead is anything but minimal, > especially on ARM platforms. This is of course machine-dependent. It is not very large on modern x86. It was large on old x86. I think it needs mainly deep pipelines and out of order execution to be fase. Testing on old Athlon64 showed that the overhead is quite large even on modern x86. Direct accesses to a memory variable can be done at 2 per cycle in a 4-way unrolled loop, but the best I could find for accessor(&var) in a function call was 1 per 8 cycles, with unrolling making the accesses slower. 16 times slower. The unrolled loop is favourable to the simple operation of a memory load or store of a single memory (in-cache) variable, but also to calling a single accessor function. Bruce