FreeBSD Most wanted

[Chris Pressey]

On Fri, 5 Mar 2004 22:19:54 -0500
Rahul Siddharthan <rsidd at online.fr> wrote:

> Chris Pressey said on Mar  5, 2004 at 19:22:00:
> > On Sat,  6 Mar 2004 02:55:35 +0100
> > Rahul Siddharthan <rsidd at online.fr> 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