Date: Wed, 16 May 2001 10:43:14 -0700 (PDT) From: Matt Dillon <dillon@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... Message-ID: <200105161743.f4GHhEl72847@earth.backplane.com> References: <Pine.BSF.4.21.0105161759410.8173-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105161743.f4GHhEl72847>