delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/01/24/11:25:23

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3C502FDB.EEAE1B5B@lapo.it>
Date: Thu, 24 Jan 2002 17:01:32 +0100
From: Lapo Luchini <lapo AT lapo DOT it>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: it,en,fr,es,ja
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: gettimeofday/PerformanceCounter overhead
References: <00af01c1a3de$7af04b40$60a407d5 AT BRAMSCHE> <3C4E6FD1 DOT 9060505 AT computer DOT org> <20020123172718 DOT GE6765 AT redhat DOT com> <3C4F01DF DOT 70AA4F00 AT lapo DOT it> <20020123190335 DOT GC18042 AT redhat DOT com> <3C4F64B4 DOT 380E84AF AT lapo DOT it> <00b201c1a4ac$935891f0$0200a8c0 AT lifelesswks>

> As long as the calibration only occurs when someone is using
> gettimeofday, not on every cygwin1.dll load, then that sounds fine to
> me.

At the end of the mail there is some benchmarking to show PerformanceCounter
use is not that "slow" even in its setup (which is done on it's first call).

Columns are:
-original: call to the gettimeofday() by DJ as found in
winsup/cygwin/times.cc (which uses GetSystemTimeAsFileTime)
-new: overall use of the new gettimeofday()
-new_init: a version that has a "bug" in "initialization" so that
initializes itself at every call
-new_old: a version thar has a "bug" in detection of Performancecounter
presence to force use of original call
all times are in seconds per 1 millions of consecutive calls
(e.g. can be considered roughly microsecond per call)

The following consideration arise:
-on 98 QueryPerformanceCounter is 12.5 times faster
-on 2000/XP QueryPerformanceCounter is 2-3 times slower, except 2 cases in
which is 7 and 9 times slower
-in the typical case QueryPerformanceCounter take 5-10us at first call and
2-4us at other calls
-even in the worst case QueryPerformanceCounter takes "only" 11us

This sound to me as the new function would be good... what do you think of
it?

My only real concern is that as it is it has an "absolute" uncertainty of
15ms on the time measurement (but only 2-4us on deltas).
An approach to have some kind of syncronization would be to poll original
gettimeofday() until it changes value and to "sync" on that "edge", but this
would slow the first call from 5-10us down to 1-16ms, which is way too much
IMHO.

--------+---------+-------+--------+----------+----------+----------+----------+

Machine |compiler |OS     |CPU     |original  |new       |new_init
|new_old   |
--------+---------+-------+--------+----------+----------+----------+----------+

CyberOne|no-cygwin|2000sp2|2xP3-450|   .846679|  1.746022|  5.503428|
.918950|
CyberOne|MSVisualC|2000sp2|2xP3-450|   .862335|  1.914982|  5.498225|
.868891|
NoEmOn  |no-cygwin|2000sp2|P3-450  |  1.228030| 11.458962| 28.876049|
1.820429|
Jastar  |no-cygwin|2000sp?|P2-400  |  1.184996|  8.016424| 10.086791|
1.285417|
Magic   |MSVisualC|2000sp?|P3-350  |  1.190737|  3.377681| 10.157640|
1.178946|
Cikku   |no-cygwin|2000sp?|P2-300  |  1.401790|  4.222252| 11.412069|
1.382729|
Omero   |no-cygwin|XP     |XP1700+ |   .296723|  1.051282|  3.200104|
.289188|
Viri    |no-cygwin|98first|P2-333  | 74.665424|  5.960425| 88.101787|
75.279405|
Jex     |no-cygwin|98se   |P2-233  |114.010888|
9.040290|136.016347|114.065398|
--------+---------+-------+--------+----------+----------+----------+----------+

--
Lapo 'Raist' Luchini
lapo AT lapo DOT it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019