From help-octave-request at bevo dot che dot wisc dot edu  Tue Mar  7 15:53:46 2000
Subject: Re: QUERY: what is status/recommendations for Octave + ATLAS compilation 
From: Dennis Decoste <decoste at aig dot jpl dot nasa dot gov>
To: help-octave at bevo dot che dot wisc dot edu
cc: decoste at aig dot jpl dot nasa dot gov, "John W. Eaton" <jwe@bevo.che.wisc.edu>
Date: Tue, 07 Mar 2000 13:53:43 -0800


"John W. Eaton" <jwe at bevo dot che dot wisc dot edu> wrote:
>I will only be adding ATLAS to the development sources.  I consider
>the stable sources to be pretty much dead unless someone wants to
> ...
> As I see it, ATLAS will definitely be available in some future version
> of Octave.  The only question is whether it should be optional.  I'm
> leaning toward making it the default.  If it is the default, then the
> ...
> a simple `untar; configure; make; make install'.  So I think it would
> be better to include ATLAS with Octave and build it along with the
> rest of Octave.

 As far as I'm concerned, ATLAS being part of Octave would be just great.

 One possible problem might be if there are users with platforms
 that are not supported by ATLAS but historically have been by
 Octave (if such platforms exist).
 [I guess such users should chime in soon, if they exist ...]

 Also, it might be a source of even more "Octave doesn't compile for me"
 messages, if ATLAS doesn't almost always compile well straight-out
 of the box.   But I think your keeping the frozen stable Octave as
 a fall back for such users seems a fair option.


 So, I guess for the short-term then I will use Steve's posted patches
 on top of the latest development Octave --- which is apparently:
 ftp://ftp.che.wisc.edu/pub/octave/bleeding-edge/
  octave-2.1.28.tar.gz                                4649 Kb    Tue Feb  8 13:48:00 2000

--------------------------------------------------------------------------

 BTW, for comparison, I've been using the newer MATLAB
 LAPACK-based numerics library mentioned previously
 (e.g. http://www.che.wisc.edu/octave/mailing-lists/help-octave/2000/288):

 For example, on my (dual-CPU) 450Mhz Sun Sparc Ultra60 with
 2Gb RAM (and plenty to spare -- no swapping occured):

  >> X=randn(1000,1000); Y=randn(1000,1000);

 MATLAB classic:
  >> version
   ans = 5.3.1.29215a (R11.1)
  >> tic; Z=inv(X); toc
    elapsed_time = 36.9865
  >> tic; Z=X*Y; toc
    elapsed_time = 23.6816

 MATLAB with new Mathworks LAPACK-based patches:
 >> tic; Z=inv(X); toc
   elapsed_time = 7.8835
 >> tic; Z=X*Y; toc
   elapsed_time = 6.5953

 Octave (without ATLAS):
  >> version
  ans = 2.0.16
  >> tic; Z=inv(X); toc
  ans = 40.512
  >> tic; Z=X*Y; toc
  ans = 52.003

 Octave (with ATLAS):
  [don't know yet, but would expect to be much faster]


 Apparently MATLAB optimized their new numerics
 library a bit more than the standard BLAS/LAPACK
 available with the standard Octave distribution.
 E.g. Octave's "inv" is basically only as fast as
 MATLAB's old classic one.  I'm also a bit surprised to
 find Octave's standard mult is more than twice as slow
 as MATLAB's old one, for such 1000x1000 randn examples.
 [I tried a few randn mats and mults, to make
 sure this wasn't some statistical fluke].

 [For the record, I had compiled my Octave 2.0.16 based on:
 ../configure --prefix=/proj/DMD/octave/octave-2.0.16/zLOCAL --enable-shared --enable-dl --enable-lite-kernel
 which apparently for my system used f77 to compile the Fortran parts]

 Anyway, I would expect/hope that ATLAS (more than)
 evens the playing field ...

-- Dennis



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------