I know that it is possible to get space and time profiling with the
function time and in many cases this is all I want.
but what to do when you have to know the precise time in milliseconds
or even more exactly? I'm working with acl 7.0 on windows and there,
the smallest piece of time, I can grab is 15 ms!
some ideas like the CFFI or an OSI came into my mind, but could not go
further, even a dos shell calling "time" is not worth talking about.
can anyone give me a hint?
the task: get the run time for a function call (just calling it once)
in a range between 0.01 and 15 ms. it wouldn't matter if the times
acquired where wrong by a constant factor, because I would need them
for comparing with themselves only.
On Thu, 14 Jun 2007 13:36:55 -0700, "(typep 'nil (statisfies 'identity))" <··············@yahoo.it> said:
| ...
| but what to do when you have to know the precise time in milliseconds
| or even more exactly? I'm working with acl 7.0 on windows and there,
| the smallest piece of time, I can grab is 15 ms!
Is (APROPOS "RUN-TIME") of any help?
---Vassil.
--
The truly good code is the obviously correct code.
(typep 'nil (statisfies 'identity)) wrote:
> I know that it is possible to get space and time profiling with the
> function time and in many cases this is all I want.
>
> but what to do when you have to know the precise time in milliseconds
> or even more exactly? I'm working with acl 7.0 on windows and there,
> the smallest piece of time, I can grab is 15 ms!
>
> some ideas like the CFFI or an OSI came into my mind, but could not go
> further, even a dos shell calling "time" is not worth talking about.
You could set up some CFFI bindings to the PAPI performance counter
library. PAPI generally has access to the hardware's native cycle
counters; its website will tell you how accurate it is, but it's
certainly more accurate than even POSIX gettimeofday() (which has a
resolution of around 10^{-5} - 10^{-6} seconds).
Accurate timing of short-duration events is a tricky thing in general.
You could repeat the event several times and compute an average time,
but then you're likely to get cache effects that improve performance
over a one-shot timing.
mfh
(message (Hello '(typep)
(you :wrote :on '(Thu, 14 Jun 2007 13:36:55 -0700))
(
tns> but what to do when you have to know the precise time in milliseconds
tns> or even more exactly? I'm working with acl 7.0 on windows and there,
tns> the smallest piece of time, I can grab is 15 ms!
they seem to be using GetTickCount Windows API, or something similar.
tns> some ideas like the CFFI or an OSI came into my mind, but could not go
tns> further, even a dos shell calling "time" is not worth talking about.
if Allegro doesn't have it yet (you can search with apropos), you can use
timeGetTime or QueryPerformanceCounter APIs.
timeGetTime is a multimedia timer, returning DWORD, it can be tuned to have
1 ms precision.
QueryPerformanceCounter (used together with QueryPerformanceFrequency)
gives you extremely high precision (on scale of CPU speed -- Ghz), but it's
more complex.
you can find both this functions in MSDN online.
tns> can anyone give me a hint?
tns> the task: get the run time for a function call (just calling it once)
tns> in a range between 0.01 and 15 ms
unfortunately calling function once won't give you any meaningful results --
because Windows does not give processes quantas deterministically. it can
help a little if you run it on dual-core CPU, and give ACL higher priority,
so it will not be preempted.
and better call it several times anyway. i suspect you can't do it because
function has side effects. but ain't it possible to undo those side effects,
and re-do function?
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")