Bug 45065 - Octave does not use ATLAS
Octave does not use ATLAS
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: octave (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-19 20:03 EDT by Dmitri A. Sergatskov
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-20 14:29:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri A. Sergatskov 2001-06-19 20:03:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2smp i686)

Description of problem:
Currently octave uses non-optimised BLAS library though it can
use optimised one (ATLAS). 

How reproducible:
Always

Steps to Reproduce:
1.Since it is not a bug, but a feature request there are
2. no steps to reproduce
3.
	

Actual Results:  It runs slow.

Expected Results:  It runs fast

Additional info:

Debian 2.1 has ATLS enabled Octave.
Comment 1 Trond Eivind Glomsrxd 2001-06-20 14:27:29 EDT
It's hard to do properly... ATLAS is very tied into your specific machine (it
optimizes for a specific cache size, to give one example). So you'll end up with
a non-optimal installation.
Comment 2 Trond Eivind Glomsrxd 2001-06-20 15:12:30 EDT
I've looked closer into it... it detects SSE, L1 and L2 cache etc. during build,
and not when run. If you have any good solutions, I'm interested, but currently,
I think that the best approach would be to change the code from detecting at
compiletime to detecting at runtime.
Comment 3 Dmitri A. Sergatskov 2001-06-20 15:32:33 EDT
Matlab 6 (the current version) has ATLAS as a shared library. There are 4
different version optimized for different archs (PPro, PII, PIII, Athlon).
When run it tries to figure out arch and use an appropriate library.
I do not have Debian machine handy, so do not know how Debian does it
for octave, but I know that Debian as ATLAS as shared library as well
(this is somewhat special since ATLAS team do not support shared libraries).

For Matlab, I tried to build a custom library for AMD-K6-III and the results was
not that much better then any of supplied libraries -- in fact the scatter
between those 4 was withing 10% or so. I assume I could have done better
hand-tuning cache edge etc..., but I have not done so.
I am also wondering how much work would it be to make an SRPM that would
rebuild to a platform specific version. This way RPM could have been done
for say PIII and people who want better will have to rebuild SRPMS.
Comment 4 Dmitri A. Sergatskov 2001-06-20 15:36:39 EDT
Actually, if ATLS build as shared library, then it can be a different package
and one should try to optimize it. Octave package can be generic.

Comment 5 Trond Eivind Glomsrxd 2001-06-20 15:43:30 EDT
Building as a shared library isn't a problem (I did that for LAPACK/BLAS many
years ago, when I was studying - you can find some of the entries in the
official one at netlib), but having one optimized for everyone is. I'm not fond
of the idea of shipping multiple libraries.
Comment 6 Dmitri A. Sergatskov 2001-06-20 15:51:26 EDT
No. I suggest picking one arch (say PIII) and ship ATLAS RPM optimized for it.
 Ideally, rebuilding SRPMS on particular architecture should result
in library optimized for this particular architecture. So you ship
_suboptimal_ library, but I think it is still better than plain lapack.
And people who care can try to optimize further as long as they want. 
Comment 7 Trond Eivind Glomsrxd 2001-06-20 16:38:59 EDT
Well, if you can make a nice package (preferably integraded in the current
lapack/blas one) I'll be very interested :).

Note You need to log in before you can comment on or make changes to this bug.