From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 01:48:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 328D037B401 for ; Fri, 16 May 2003 01:48:00 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF85343F93 for ; Fri, 16 May 2003 01:47:58 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h4G8lup9022290; Fri, 16 May 2003 18:47:56 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h4G8lnT1022289; Fri, 16 May 2003 18:47:49 +1000 (EST) Date: Fri, 16 May 2003 18:47:49 +1000 From: Peter Jeremy To: Pawel Jakub Dawidek Message-ID: <20030516084749.GA22269@cirb503493.alcatel.com.au> References: <20030515123033.GP45118@garage.freebsd.pl> <20030515151945.GQ45118@garage.freebsd.pl> <200305151407.28717.wes@softweyr.com> <3EC481D3.124F61B8@mindspring.com> <20030516070732.GT45118@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030516070732.GT45118@garage.freebsd.pl> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Optimizations. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 08:48:00 -0000 On Fri, May 16, 2003 at 09:07:32AM +0200, Pawel Jakub Dawidek wrote: >Look at functions in /sys/kern/kern_tc.c. There are so many little >functions. How about put __inline here and there? How about you try this and post some results showing what effect this has - both at the micro-benchmark level and for a real-world application (like a proxy or load balancer). >And second thing. Does anybody think about representing time in BCD code? This would take a lot of effort: There are no BCD primitives in C so you would have to start off with a an arithmetic and I/O library. And, apart from the i386, I don't believe any of the supported CPUs have BCD support in hardware - and the i386 support is very limited. Then you'll need a new BCD gettimeofday() syscall and BCD variants of all the functions in ctime(3). What format time do you want? Seconds-since-epoch or yyyy/mm/dd hh:mm:ss? Converting between these formats needs a fair amount of arithmetic so if you get it wrong, you've probably written off any possible gains. At the end, it's not clear what you gain. You still need the ability to perform arithmetic to convert between UTC and local time. All you've saved is the binary-to-decimal conversion - which is trivial compared to all the other overheads. Peter