From owner-freebsd-chat@FreeBSD.ORG Fri Mar 5 19:33:55 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC2B916A4CE for ; Fri, 5 Mar 2004 19:33:55 -0800 (PST) Received: from priv-edtnes14-hme0.telusplanet.net (outbound03.telus.net [199.185.220.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A7543D31 for ; Fri, 5 Mar 2004 19:33:55 -0800 (PST) (envelope-from cpressey@catseye.mine.nu) Received: from catseye.biscuit.boo ([154.5.85.228]) by priv-edtnes14-hme0.telusplanet.netSMTP <20040306033355.OGMC27288.priv-edtnes14-hme0.telusplanet.net@catseye.biscuit.boo>; Fri, 5 Mar 2004 20:33:55 -0700 Date: Fri, 5 Mar 2004 19:38:53 -0800 From: Chris Pressey To: Rahul Siddharthan Message-Id: <20040305193853.51f74391.cpressey@catseye.mine.nu> In-Reply-To: <20040306031954.GA3713@online.fr> References: <20040306012556.GA2554@online.fr> <200403060245.05790.dgw@liwest.at> <1078538135.40492f9742e70@imp4-q.free.fr> <20040305192200.7a377e92.cpressey@catseye.mine.nu> <20040306031954.GA3713@online.fr> Organization: Cat's Eye Technologies X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: dgw@liwest.at cc: chat@freebsd.org Subject: Re: FreeBSD Most wanted X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2004 03:33:55 -0000 On Fri, 5 Mar 2004 22:19:54 -0500 Rahul Siddharthan wrote: > Chris Pressey said on Mar 5, 2004 at 19:22:00: > > On Sat, 6 Mar 2004 02:55:35 +0100 > > Rahul Siddharthan wrote: > > > > > Daniela wrote: > > > > I like doing AI programming, that's numbercrunching most of the > > > > time. > > > > > > > > A compiler can't, for example, know whether you need to have > > > > zero returned from the atoi() function when the user entered > > > > nonsense. If you don't need to check whether the user has > > > > entered a valid number, you can do it *much* faster. > > > > > > Excellent example. Here you're limited by the speed of the > > > fingers of the user who's entering the data, so there's > > > *absolutely no point* in optimising the atoi() function in this > > > way. (Or if you're reading from the disk, the disk I/O will be > > > the bottleneck, though it's admittedly faster than fingers.) > > > > I don't understand your point... atoi() is not an I/O function. > > Where did the "a" in the "atoi" come from? > > The point is that some very slow i/o routine gives you an ascii string > (that's the only reason you'd ever need to deal with an ascii string), Y'think? That ASCII string could be in core, loaded there at some point in the distant past, and only now you find you need to convert it to an integer as quickly as possible. I think you're also assuming that all I/O is slow. What about pipes, memory-backed filesystems, mmap'ed files, IPC, etc etc? > and then the C library's atoi() converts that to an integer. Now, > what's the advantage of optimising atoi()? > > R I love how everyone in this thread is trying to show that they're wiser than a sixteen-year-old. :) -Chris