[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More on slow min function

From: Daniel J Sebald
Subject: Re: More on slow min function
Date: Wed, 02 Feb 2005 16:06:36 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

Quentin Spencer wrote:

I just found something odd that may be related to the max/min problem that was recently discovered. It was triggered by the following loop:

for i=1:10
      (long simulation)

The long simulation was a bit-error-rate Monte Carlo simulation that uses David Bateman's bchenco and bchdeco functions from octave-forge. It is called inside a lower-level function. The timing result was that the first run was always about 30% faster than subsequent runs. The first time I saw this I thought it was a coincidence due to external CPU load factors, but I have now observed it repeatedly. My experience is also consistent with the other comments--stopping the script and restarting gives the slower run time, while restarting octave or "clear all" give the fast run time the first time through. Like max and min, bchenco and bchdeco are in the same .oct file.

I think you are right, Quentin. We looked at loops comprised mainly of min/max (multiple factor loss). You likely have more code in your loops with the occasional call to bchenco/bchdeco (fractional loss). Confirms the problem.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]