From owner-freebsd-arch Sun Feb 17 20:42: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7BBAF37B402; Sun, 17 Feb 2002 20:41:57 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA07679; Mon, 18 Feb 2002 15:41:41 +1100 Date: Mon, 18 Feb 2002 15:41:40 +1100 (EST) From: Bruce Evans X-X-Sender: To: Matthew Dillon Cc: Terry Lambert , Poul-Henning Kamp , Julian Elischer , Alfred Perlstein , , , , Subject: Re: gettimeofday() and crhold()/crfree() (was Re: gettimeofday()andcopyout(). Is copyout() MPSAFE on non-i386 archs? ) In-Reply-To: <200202180409.g1I49vj10455@apollo.backplane.com> Message-ID: <20020218151249.E4728-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 17 Feb 2002, Matthew Dillon wrote: > Just a note: The gettimeofday() has an overhead of only 2-3 uS in > -current. Squid would have to be doing an aweful lot of transactions And that is only on slow machines and/or under SMP. On my Athlon1600, it has an overhead of 0.3-0.4 nsec. I have been benchmarking it for many years and recently had to change the benchmark program to use clock_gettime(2) instead of gettimeofday() when getttimeofday()'s resolution became too small. > for it to matter and even if it did, if that actually turned out to be the > bottleneck I'll eat my hat. And if I wind up eating my hat the next > thing I'll do is spend the necessary 5 seconds writing a little code > to make squid only call gettimeofday every 5th time. Or use an alarm to set it... Summary of overheads for gettimeofday() (clock_gettime() for sub-usec ones) in a loop:: -my-current on Athlon1600 @ 1532 0.381 usec (TSC) -current on Athlon1600 @ 1532 0.512 usec (TSC) 4.5RC on Athlon1600 @ 1532 0.345 usec (TSC) -my-current-2000 on Celeron366 @ 522 1.389 usec (TSC) -my-current-1999 on Celeron400 @ 450 1.683 usec (TSC) -my-current-1998 on K6-1/233 2.241 usec (TSC) -my-current-2001 on Pentium1 @ 133 5.474 usec (TSC) (reduce SMPng pessim) -my-current-2001 on Pentium1 @ 133 6.786 usec (TSC) (more SMPng pessim) -my-current-2000 on Pentium1 @ 133 5.376 usec (TSC) (SMPng pessim) -my-current-1999 on Pentium1 @ 133 4.630 usec (TSC) -my-current-1998 on Pentium1 @ 133 4.615 usec (TSC) (timecounter pessim) -my-current-1998 on Pentium1 @ 133 3.443 usec (TSC) (pre-timecounter) -my-current-1996 on Pentium1 @ 133 3.320 usec (TSC) -my-current-2000 on 486DX2/66 21.843 usec (i8254) (SMPng pessim) -my-current-1995 on 486DX2/66 14.276 usec (i8254) Except for the non-TSC timecounter, this mostly measure overheads for syscalls generally. The core part of gettimeofday(), i.e., microtime() takes less than 100 nsec on the Athlon. This stuff is fun to optimize, but I haven''t found a case where optimising all syscalls (not just gettimeofday()) makes a difference in a normal application. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message