[MUG] 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

Previous by date: [MUG] Coupled, nonlinear ODEs., Anders Ballestad
Next by date: [MUG] 3D surface plotting from data points., 
Previous thread: [MUG] Print the procedure output from dsolve,  Reuben D Budiardja
Next thread: [MUG] 3D surface plotting from data points.,