From owner-freebsd-questions  Wed May 16 10:43:26 2001
Delivered-To: freebsd-questions@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1854D37B42C; Wed, 16 May 2001 10:43:19 -0700 (PDT)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.3/8.11.2) id f4GHhEl72847;
	Wed, 16 May 2001 10:43:14 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 16 May 2001 10:43:14 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200105161743.f4GHhEl72847@earth.backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: Terry Lambert <tlambert2@mindspring.com>,
	dave <dleimbac@earthlink.net>, freebsd-questions@FreeBSD.ORG,
	arch@FreeBSD.ORG
Subject: Re: Gettimeofday Again...
References:  <Pine.BSF.4.21.0105161759410.8173-100000@besplex.bde.org>
Sender: owner-freebsd-questions@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:On Tue, 15 May 2001, Matt Dillon wrote:
:
:>     Also, using gettimeofday() is a ridiculous way to measure fine grained
:>     time billions of times in production code.  I mean, sure, it works...
:>     but getitimer() is about 5 times faster.
:
:(Bruce)
:
:This seems unlikely, since most of the overhead for both is in the syscall.
:Actual testing shows that getitimer() is a whole 10% faster on a Celeron
:5.5 * 95 MHz:

    I just ran the test using the default timecounter on a 4.3 box (P3).
    timercounter.method was 0, timecounter.hardware was i8254.  In
    that case the itimer was about 4 times faster.  So this was using
    the 'slow' itimer as you indicate below.

    I don't change the timercounter method defaults, and I sure hope you
    aren't advocating that people change their timecounter defaults.  If
    the TSC is a reasonable default, the system should figure it out and
    use it without requiring intervention.

    But, be that as it may, Terry's argument doesn't hold water.  Logging
    and performance just don't go together if you are tring to log thousands
    of connections/sec, so Terry deserves whatever hell he's gotten himself
    into and shouldn't blame gettimeofday() for his problems.  If someone
    needs high performance logging, there are plenty of ways of offloading it.
    A network monitor would be my first choice.  You could also shove a
    UDP packet off to another machine for each connection, etc etc etc.

    Personally speaking, I don't give a damn about contrived cpu-intensive
    performance figures because if cpu were my only problem the solution 
    would be to simply throw another machine into the rack.   You have
    to look at these things from a revenue/price/performance point of view.
    If I have, say, a webserver, which is cpu-bound serving a thousand
    pages a second, and each of those pages is worth a fraction of a cent
    to my bottom line, then the cost of purchasing another machine to help
    with the load is negligible compared to the revenue each machine is
    generating.  And if it isn't someone has fucked the business plan and
    the algorithms up and needs to go fix them.  It's that simple.

					-Matt

:This is for my version of -current, which has a few pessimizations in
:microtime().  Plain -current would be a few nsec faster.
:
:OTOH, gettimeofday() may be significantly slower than getitimer() if the
:hardware timecounter is slow:
:...
:(Bruce)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message