octave-maintainers
[Top][All Lists]
Advanced

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

Report on progress...


From: Daniel J Sebald
Subject: Report on progress...
Date: Thu, 03 Mar 2005 10:22:26 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

address@hidden wrote:

A while back Dmitri suggested it might be the compiler... e.g., think back
LAPACK problems, etc.  The Fedora website has an update to the compiler (a
big jump in the version number, pretty much the most recent version).  I
downloaded the update but didn't have time to install and try it before
leaving on my trip.  I'll let you know later if the compiler upgrade fixes
things.

After getting back to town I looked once again at the Fedora web site.  I
can no longer find:

gcc-3.4.3-17.i386.rpm       gcc-java-3.4.3-17.i386.rpm
gcc-g77-3.4.3-17.i386.rpm   gcc-objc-3.4.3-17.i386.rpm
gcc-gnat-3.4.3-17.i386.rpm

That gives me a queasy feeling, so I didn't install the new compiler.  Rather
I just compiled 2.1.65.

I'm happy to report that both the "two functions in one file on multiple
reads" problem and the "external pager quitting kills standard error"
problem seem to have gone away.  So, thank you very much to JWE and Dmitri.

I note an improved performance in speed for some intensive number crunching.
A program to process multichannel data has gone from:

with 2.1.64
  textstr = 0, 3.233
  textstr = 1, 88.33
  textstr = 2, 171.8

with 2.1.65
  textstr = 0, 3.226
  textstr = 1, 64.41
  textstr = 2, 123.9

There aren't the most indicative numbers, but I can say a couple things.
These are the number of CPU seconds consumed to process the data (one
tick for every processed second of data).

1) Either the "two functions in one file" fix has solved an
existing problem I was unaware of, or the fact that I no longer
define min(x) as -max(-x) to get around the "two functions"
problem has improved things by 30%.  More likely the former.

2) My intuition is that the looping is still slower than it
seems it should be, but don't put too much weight in that.
I've too old of a machine to judge, and given the dodgy
state of FC3 compilers, it is too difficult to investigate
right now.  I make the conclusion based on the fact that some
similar code that uses filter()--as opposed to looping and
indexing--to process 1 second blocks runs fairly fast.

Anyway, those two fixes are a big improvement as far as I'm
concerned.

Thanks,

Dan



reply via email to

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