Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

timingmodule for Win NT ?

2 views
Skip to first unread message

Thomas Freytag

unread,
Feb 27, 1997, 3:00:00 AM2/27/97
to

Unfortunately the included timingmodule.c does'nt compile under
Win NT 4.0 (MSDev 4.0) because of some incompatible data structures.
Does there exist a ported version of it or any other module
supporting the measurement of execution times ?

Thanx
Thomas
______________________________________________________________________

Thomas Freytag E-Mail: t...@aifb.uni-karlsruhe.de
Institut AIFB Telefon: +49 721 608 4063
Universitaet Karlsruhe Telefax: +49 721 693717
76128 Karlsruhe
Germany http://www.aifb.uni-karlsruhe.de/Staff/tfr.html
______________________________________________________________________

Guido van Rossum

unread,
Feb 27, 1997, 3:00:00 AM2/27/97
to

> Unfortunately the included timingmodule.c does'nt compile under
> Win NT 4.0 (MSDev 4.0) because of some incompatible data structures.
> Does there exist a ported version of it or any other module
> supporting the measurement of execution times ?

As far as I'm concerned the timing module should be eradicated. Use
time.clock() for precise timings.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Christian Tismer

unread,
Feb 27, 1997, 3:00:00 AM2/27/97
to

Guido van Rossum wrote:
>
> > Unfortunately the included timingmodule.c does'nt compile under
> > Win NT 4.0 (MSDev 4.0) because of some incompatible data structures.
> > Does there exist a ported version of it or any other module
> > supporting the measurement of execution times ?
>
> As far as I'm concerned the timing module should be eradicated. Use
> time.clock() for precise timings.
-------------------^^^^^^^
exception raised in module pythonlistscanner.py
Traceback (innermost last):
File "<interactive input>", line 0, in ?
SemanticMismatchError: a resolution of 1/18.2 sec is not precise.
Proposal: insert another OS. Rejected by user.
trying to fork solutiongenerator.py......
failed. Notifying python-list....
done.

Mark Hammond

unread,
Feb 28, 1997, 3:00:00 AM2/28/97
to

> exception raised in module pythonlistscanner.py
> Traceback (innermost last):
> File "<interactive input>", line 0, in ?
> SemanticMismatchError: a resolution of 1/18.2 sec is not precise.
> Proposal: insert another OS. Rejected by user.
> trying to fork solutiongenerator.py......
> failed. Notifying python-list....
> done.
:-)

Ive spent too long looking into this now :-)

It seems the GetProcess/ThreadTimes function has the same resolution
as clock() on an NT box, which is still not good.

There is a better resolution "counter" we can use. To quote some
doco: "The unit of measurement is determined by the hardware; on
Intel-based CPUs it is about 0.8 microseconds."
But it is just a simple counter. This means:

* Need some sort of static "start value", which is set when the
process starts, so I can return to Python in seconds. An easy hack
is to set this the first time clock() is called, but then it wont
reflect any sort of real time - but would be useful for relative
times...

* Doesnt give indication of "process time" - is really just a very
high resolution real time counter. However, to quote some MSoft
doco I found: "...or to turn to the highest-resolution time service
of all, QueryPerformanceCounter. This function was designed mainly
for profiling, ..."

For the purposes of profiling, the first problem shouldnt be :-) And
for the purposes of getting _any_ reasonable results, and within the
limitations that most win32 people are on Intel, and anyone who isnt still
has less than 2^32 performance ticks per second, I humbly submit the
following patch to timemodule.c. All criticisms welcome, as long as you
submit your fix too :-)

And to tell the truth, Im not sure the "largeint.h" didnt come first
with MSVC4.2 - someone else will need to test this. It has been
tested on NT4/Win95, but has not been tested using the profiler - just a
"time.clock()" loop.

Guido - any chance of getting this accepted?

Mark.

70a71,76
> #ifdef MS_WIN32
> /* Win32 has better clock replacement */
> #include <largeint.h>
> #undef HAVE_CLOCK /* We have our own version down below */
> #endif /* MS_WIN32 */
>
119a126,127
>
>
120a129,167
>
> #ifdef MS_WIN32
> static object *
> time_clock(self, args)
> object *self;
> object *args;
> {
> static LARGE_INTEGER ctrStart;
> static LARGE_INTEGER divisor = {0,0};
> LARGE_INTEGER now, diff, rem;
> ULONG ulRem;
> double result;
>
> if (!getnoarg(args))
> return NULL;
>
> if (LargeIntegerEqualToZero(divisor)) {
> QueryPerformanceCounter(&ctrStart);
> if (!QueryPerformanceFrequency(&divisor) ||
> LargeIntegerEqualToZero(divisor)) {
> /* Unlikely to happen -
> this works on all intel machines at least!
> Revert to clock() */
> return newfloatobject(clock());
> }
> }
> QueryPerformanceCounter(&now);
> diff = LargeIntegerSubtract(now, ctrStart);
> diff = LargeIntegerDivide(diff, divisor, &rem);
> /* XXX - we assume both divide results fit in 32 bits. This is
> true on Intels. First person who can afford a machine that
> doesnt deserves to fix it :-)
> */
> return newfloatobject((double)diff.LowPart +
> ((double)rem.LowPart / (double)divisor.LowPart) );
> }
> #define HAVE_CLOCK /* so it gets included in the methods */
> #endif /* MS_WIN32 */
>
----------------------------------------------------------------------
Mark Hammond - MHam...@skippinet.com.au
Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc
<http://www.python.org> & <http://www.python.org/ftp/python/pythonwin>

0 new messages