Cygwin built octave and Windows binary distribution

[Paul Thomas]

Dear All,

Ben Diedrich and I both have the octave-2.1.50a binary distribution running on 
Windows2000, 2.5Ghz Pentium machines.  This really is a superb distribution 
and, as promised by Paul Kienzle, it does not interfere at all with existing 
Cygwin installations.

Wanting the latest and the best, we both downloaded and built later versions; 
2.1.53 and 55 in my case.  For the main part, they are just fine but 
fortran-style programmes are VERY slow. Like, factors of 6 or so....

I thought that I should communicate that I have been pursuing this business but 
I have had little or even negative success:

I reduced my Cygwin installation to bedrock because I suspected that KDE was
playing with various bits and pieces, including libstdc++.dll.  The paths
were all screwed up, with KDE and QT appearing first.

I then re-installed Cywin, X11R6 and octave-2.1.50, to compare like with like.  
Followed Paul Kienzle's route to produce stdc++.dll, ran configure with static 
disabled an share enabled. I modified SH_LDFALGS to enable runtime-pseudo-reloc 
and auto-image-base, as in the binary release.  This is followed by make and 
make install.  The output from octave_config_info reveals two differences: the 
compiler and the prefix.

The result is slightly worse than the octave-2.1.53; for the M.Mouse test
programme, my build takes 10.9s, whereas the binary distribution takes 1.9s.
Vectorised M.Mouse (ie. tic;tot=sum([1:1E5]);toc  takes 3 and 2ms,
respectively.  (Paul, yes the range without the [] operator is the one that
grows quadratically.  It does not in Matlab5, though.  It was getting late
and I must have been working in the Matlab workspace).

If I move to the Sciviews benchmark, both octaves and matlab5 have nearly
identical performance (ie ± 10% between the octaves), except for four of
the tests (the first not being apposite, here):

   Test       My 2.1.50      PKs 2.1.50      MatlabR11

Matrix I,1       2.04           1.89            0.32
(1500x1500 matrix) 

Programming 3    0.69           0.29            0.5
(recursion)

Programming 4    8.1            1.37            0.15             
(Make Toeplitz)

Programming 5    6.4            2.37            1.55
(Escoufier)

The core of the Toeplitz benchmark can be vectorised as
N=220;tic;m=ones(N,1)*[1:1E5];T=abs(m-m')+1;toc   instead of
N=220;for i=1:N;for j=1:N;T=abs(i-j)+1;end;end; 
which causes the test to run 9ms for both octaves and less than 1ms for
Matlab.

In conclusion, then, the octave compiled using the mingw version of gcc 3.3
runs factors of 5 or 6 times slower, for fortran-style programmes, than that
with compiled with gcc 3.2 for Cygwin.  Otherwise, (where g77 dominates?)
they are very much the same.

Math is unaffected, so it is not some default assumption about math
exceptions or CPU type.  Something wierd must be happening to the tree
walking, it seems to me. But what?  I note that we can "pessimilize" it at a 
stroke, so it perhaps gives some indication where improvements in performance might be 
found?

I guess that the Windows version might be different? I am using Windows
2000.  What is used for the binary release?

I have tried variations; including --enable-auto-import (which does work
BTW, Paul) and excluding stdc++.dll but the effects are in the noise.

I could not find a gcc 3.2 binary for Cygwin.  I tried building the source
but the compilation failed after completing most of the source........ *grrrrr* 

I can only say, that I hope that the maestro keeps his gcc 3.2  and updates
soon to 2.1.55+.  Frankly, between this and the Tru64 struggle, I have had 
enough of building octave for a while!

Best regards

Paul T