Bug 45065

Summary:	Octave does not use ATLAS
Product:	[Retired] Red Hat Linux	Reporter:	Dmitri A. Sergatskov <dasergatskov>
Component:	octave	Assignee:	Trond Eivind Glomsrxd <teg>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-06-20 18:29:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitri A. Sergatskov 2001-06-20 00:03:09 UTC

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 18:27:29 UTC

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 19:12:30 UTC

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 19:32:33 UTC

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 19:36:39 UTC

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 19:43:30 UTC

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 19:51:26 UTC

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 20:38:59 UTC

Well, if you can make a nice package (preferably integraded in the current
lapack/blas one) I'll be very interested :).