slowness of Schur decomposition in octave-2

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

slowness of Schur decomposition in octave-2

Francesco Potorti`-9
With a huge delay (one month and half, approximately, I am sorry), I
forward to the list extracts from two messages that Klaus Gebhardt
sent to me, explaining why octave-2 is slow on some platforms when
doing Schur decomposition.  

By the way, this slowness -- which depends on platforms -- is the
reason why I have stopped collecting benchmark results for octave-2.


 Date: Thu, 22 May 1997 22:39:52 -0400
 From: [hidden email]
 Subject: Re: benchmark 1.10

 Hi,

  > The Fortran compiler is suspected, but no evidence has been gathered yet.

 If the reference time was produced with an Octave version build with
 G77, it would explain the bad result for the Schur decomposition. A
 few months ago i have tested the OS/2 version of the G77 and the most
 significant change was, that the Schur decomposition was 43 % slower
 (compared to the value for the Octave build with f2c). This was
 because the G77 uses static variables, while the f2c was configured
 to automatic variables. I've tried to change this, but when G77 also
 uses automatic variables, Octave crashes sometimes and on the other
 hand Octave is not faster than the with f2c compiled version.  So i
 decided to uses f2c.

 Date: Sat, 24 May 1997 00:28:20 -0400
 From: [hidden email]
 Subject: Re: benchmark 1.10

  > Can you suggest a good solution, even a future one?

 For the moment i found the best solution is using f2c -A -a and the
 best optimization options for the GCC. There is also a flag for the
 G77 to use automatic variables instead of static, but this caused
 problems, at least on my system (OS/2 with G77 0.5.18). Also Octave
 compiled with G77 was not faster in any of your tests.

 For the future the best solution would be using native C code.

 Klaus Gebhardt [TEAM OS/2]


Reply | Threaded
Open this post in threaded view
|

Re: slowness of Schur decomposition in octave-2

Takafumi Hayashi
>  If the reference time was produced with an Octave version build with
>  G77, it would explain the bad result for the Schur decomposition. A
>  few months ago i have tested the OS/2 version of the G77 and the most
>  significant change was, that the Schur decomposition was 43 % slower
>  (compared to the value for the Octave build with f2c). This was
>  because the G77 uses static variables, while the f2c was configured
>  to automatic variables. I've tried to change this, but when G77 also
>  uses automatic variables, Octave crashes sometimes and on the other
>  hand Octave is not faster than the with f2c compiled version.  So i
>  decided to uses f2c.
I forwarded this message to g77 list.
I got comments...

--------
This sounds like some sort of OS/2 lossage to me.  Octave on my x86
GNU/Linux system doesn't try to compile anything with -fno-automatic
AFAICT and it passed all the tests (when I hacked configure
appropriately).  I no longer have a compiled version to run, though.

[fx@djlvig octave]$ find . -name Make\* |xargs grep no-automatic
[fx@djlvig octave]$

Of course, if it did use -fno-automatic and g77 0.5.18, the slowness
is understandable.
--------
Regards,
---
Takafumi Hayashi             [hidden email]
The University of Aizu       phone : +81-242-37-2614
FCS Lab.                     fax   : +81-242-37-2734


Reply | Threaded
Open this post in threaded view
|

Re: slowness of Schur decomposition in octave-2

Francesco Potorti`-9
   This sounds like some sort of OS/2 lossage to me

This does not explain the slowness of Schur's decomposition on other
platforms, namely Sun and Alpha.  Others also report the same on PCs.

--
Francesco Potorti` (researcher)        Voice:    +39-50-593203
Computer Network Division              Operator: +39-50-593211
CNUCE-CNR, Via Santa Maria 36          Fax:      +39-50-904052
56126 Pisa - Italy                     Email:    [hidden email]