List Archives >
Maple User Group List Archive >
Archive by date >
This Month By Date >
This Month By Topic
[MUG] Re: Precise and invariant timing of a Maple program
| [MUG] Re: Precise and invariant timing of a Maple program |
|
Author: Maple User Group
Posted: Fri, 17 May 2002 15:11:19 -0400
|
>> From: Maple User Group "maple_gr"
| >> From: "pennestri"
| Dear Maple User Group,
| I am comparing the execution time of two
| different algorithms implemented in Maple.
| When I monitor the CPU time required to
| execute each algorithm in Maple, I do not get
| always the same answer.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
From: "Harold Bien" "harold.bien"
To: "maple-list"
Subject: Precise and invariant timing of a Maple program
Date: Wed, 15 May 2002 15:44:10 -0400
One thing I can think of is that you are using Windows2000 - a
multitasking operating system. Essentially it means that if you have
other programs running in the background, then depending upon those
programs' usage of the CPU the time required could vary. Unfortunately,
there is really no true method for Maple to determine how much CPU time
was spent performing your calculation, and even if you have no
"background" programs running you very well may have background
processes. For instance, Windows will once in a while flush its disk
cache - that takes time.
While it is possible for Maple to only count time that has been allotted
to Maple from Windows2000 (perhaps kernelops(cputime) takes this into
consideration), the pre-emptive multitasking nature of Windows2000 makes
it extremely difficult for Maple to really know when it has control and
when it does not.
It sounds to me like these little nuances may be causing you grief - but
it also means that the differences between your two algorithms may be so
slight as to be hidden by these variations. One potential solution,
then, would be to loop through your algorithm several times (maybe even
millions of times) to exaggerate any differences so that you can
overcome these minor variations. If you then wish to report time
required for the procedure, then you may divide by the number of
iterations.
Hope that helps.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
From: "Dr Francis J. Wright" "F.J.Wright"
To: "pennestri"
Subject: Precise and invariant timing of a Maple program
Date: Thu, 16 May 2002 13:19:53 +0100
This is a standard problem with software such as computer algebra systems
and it's certainly not peculiar to Maple.
The time taken will change depending on how much information is remembered
by Maple, the need to garbage collect, the time taken swapping virtual
memory pages, competing with other processes and perhaps other users, etc.
It might help always to time each algorithm in a newly started Maple, or
always time the second run ignoring the first, depending on exactly what you
want to measure. Try to make sure the machine is in the same state each
time, so that any other load on the machine is the same (if that's an
issue). I usually time several runs and take an average.
The variability is often much worse than in your example. For less trivial
cases you probably can't expect successive timings to agree to better than
about 10% however careful you are.
Francis
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Date: Thu, 16 May 2002 07:55:12 +0200
From: Helmut Kahovec "helmut.kahovec"
To: "maple-list" "pennestri"
Subject: Precise and invariant timing of a Maple program
Well, the execution times are different from session to session (and
even during a single session) because Maple does a lot of things in the
background, which may not always be the same. Additionally, an efficient
algorithm may become less efficient (or vice versa) when implemented in
Maple since the input is parsed and interpreted by the kernel, the
latter executing precompiled code (the so-called kernel functions) only
at certain stages of the computation.
If the execution times of two algorithms do not differ much then those
algorithms should be considered equally good when working with Maple.
However, if one of the algorithms is significantly faster than the other
then you will certainly notice that. For example, using the matrix
constructor matrix() and seq() is significantly faster than using zip()
in parallel computing with matrices:
Session 1
=========
> restart;
> N:=100:
> A:=matrix(N,N,[seq(i,i=1..N^2)]):
> B:=matrix(N,N,[seq(i,i=1..N^2)]):
> t0:=time(): zip(`*`,A,B): (time()-t0)*seconds;
1.111 seconds
> t0:=time():
> matrix(N,N,[seq(seq(A[i,j]*B[i,j],j=1..N),i=1..N)]):
> (time()-t0)*seconds;
.942 seconds
Session 2
=========
> restart;
> N:=100:
> A:=matrix(N,N,[seq(i,i=1..N^2)]):
> B:=matrix(N,N,[seq(i,i=1..N^2)]):
> t0:=time(): zip(`*`,A,B): (time()-t0)*seconds;
1.052 seconds
> t0:=time():
> matrix(N,N,[seq(seq(A[i,j]*B[i,j],j=1..N),i=1..N)]):
> (time()-t0)*seconds;
.930 seconds
Session 3
=========
> restart;
> N:=100:
> A:=matrix(N,N,[seq(i,i=1..N^2)]):
> B:=matrix(N,N,[seq(i,i=1..N^2)]):
> t0:=time(): zip(`*`,A,B): (time()-t0)*seconds;
1.061 seconds
> t0:=time():
> matrix(N,N,[seq(seq(A[i,j]*B[i,j],j=1..N),i=1..N)]):
> (time()-t0)*seconds;
.931 seconds
Kind regards,
Helmut
|
[View Complete Thread]
Previous by date: [MUG] evaluating _F1 /_F2 in pdsolve o/p, Nagaraj Mahavir
Next by date: [MUG] bug in sum?, Max_joern
Previous thread: [MUG] Numerical solution of ODE, PierLuigi Zezza
Next thread: [MUG] bug in sum?, Max_joern
|
(NAG)
