From octave-maintainers-request at bevo dot che dot wisc dot edu Mon Nov 18 09:26:14 2002
Subject: Re: sparse matrices and error handling
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: octave-maintainers at bevo dot che dot wisc dot edu
Date: Mon, 18 Nov 2002 09:25:56 -0600

On 18-Nov-2002, Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov> wrote:

| I was assuming that we wouldn't want to interfere with the optimizer by
| putting OCTAVE_QUIT in the middle of a tight loop.  To demonstrate this
| I looked for an appropriate loop in filter.cc, but I see that that is 
| where you put the OCTAVE_QUIT.  
| 
| I measure a 4% in the following unrealistic case:
| 
| [...]
| 
| In the following realistic case there is less than 1% performance
| penalty:
| 
| [...]
| 
| Am I correct in assuming nobody will be bothered by this?

I don't think it is too bad, and there have been bug reports about
memory leaks due to signal handling behavior.

In cases like filter, where we have loops like this,

  for (int i = 0; i < x_len; i++)
    {
      ...

      for (int i = 0; i < si_len; i++)
	{
	  OCTAVE_QUIT;
	  ...
	}
    }

I put OCTAVE_QUIT in the inner loop because if we put it at the top of
the outer loop and x_len is 1 and si_len is some large number, then we
might not be very responsive to interrupts.  OTOH, the inner loop is
just

  si(j) = si(j+1) - a(j+1) * y(i) + b(j+1) * x(i);

so how many iterations would be have to have to make this take more
than a few tenths of a second on reasonably modern hardware?

If it becomes a problem, we could always rewrite to break up the loops
so they process blocks of data before checking the interrupt state.

I suppose I'd rather leave things as simple as possible until we
actually see a performance problem, and there are probably lots of
other places in Octave where some optimization could make a much
bigger difference.

jwe