| Summary: | sci-mathematics/octave-2.1.73 hangs at first matrix inversion | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | alexsaa |
| Component: | Current packages | Assignee: | Gentoo Science Mathematics related packages <sci-mathematics> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info output | ||
Please post your `emerge --info' too. Created attachment 168612 [details]
emerge --info output
This is `emerge --info` from (second) machine with same hang symptoms (dlamc1_) and make.conf settings very similar to those given above.
What blas/lapack implementation are you are using
(i.e. what does eselect blas/lapack show) give)?
Have you tried recompiling your lapack and blas
libs? Also, you may want to set some FFLAGS to
be used with your Fortran compiler, something
like
FFLAGS=${CFLAGS}
in /etc/make.conf should do.
Thanks,
Markus
It seems I have no blas/lapack:
tux ~ # eselect blas/lapack show
!!! Error: Can't load module blas/lapack
Killed
tux ~ # eselect blas show
!!! Error: Can't load module blas
Killed
tux ~ # eselect lapack show
!!! Error: Can't load module lapack
Killed
tux ~ #
Setting FFLAGS in make.conf affects the bug:
FFLAGS="${CFLAGS} -ffloat-store" # octave works as expected
FFLAGS="${CFLAGS}" # octave hungs
FFLAGS="-ffloat-store" # octave works as expected
(-ffloat-store is from the first url mentioned in bug report)
So, setting FFLAGS="-ffloat-store" in make.conf is a usable fix/workaround.
Ahh, so you are presumably using octave's internal blas/lapack routines. If you are planning on doing anything that requires non-trivial matrix and linear algebra I would strongly advice to emerge a separate blas and lapack library since these will likely be much more efficient. I'd recommend lapack-reference blas-reference which should give pretty reasonable results and emerge fast or blas/lapack-atlas if speed is very important (these take longer to compile though). Best, Markus Thanks for the performance notice. I wish ebuild displayed that in pkg_postinst(). blas-reference (export USE=blas; emerge octave) did not affect the result: the result still depends on -ffloat-store. Adding lapack-reference (export USE=blas; emerge lapack; emerge octave) fixes the problem: without ffloat-store, [1 0; 0 1]^-1 does not hang. (In reply to comment #6) > Adding lapack-reference (export USE=blas; emerge lapack; emerge octave) fixes > the problem: without ffloat-store, [1 0; 0 1]^-1 does not hang. > Great! Once octave-3.* will become stable these issues should be a thing of the past. I'll close this bug then as FIXED even though technically we've only come up with a workaround. I hope this is all right and please feel free to reopen if you have additional concerns. Best, Markus |
At first request to inverse a matrix [1 0; 0 1], octave hangs. Reproducible: Always Steps to Reproduce: $ octave octave:1> [1 0; 0 1]^-1 Actual Results: octave hang with 100% cpu usage Expected Results: octave:1> [1 0; 0 1]^-1 ans = 1 -0 0 1 octave:2> After Ctrl-C and asking again, inversion works. gdb showed a loop in dlamc1_/dlamc3_. Reproduced on 2 machines. emerge octave says: [ebuild R ] sci-mathematics/octave-2.1.73 USE="readline zlib -blas -debug -doc -emacs -hdf5 -mpi -static" 0 kB ... * Installed are: gfortran ... checking for i686-pc-linux-gnu-gfortran... i686-pc-linux-gnu-gfortran checking whether we are using the GNU Fortran 77 compiler... yes ... make.conf has: ... CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" FEATURES="ccache parallel-fetch" ... and no line containing string '77' or 'fortran'. Google hints: http://osdir.com/ml/gnu.octave.bugs/2005-10/msg00042.html http://scicomp.ewha.ac.kr/netlib/lapack/faq_julie.html#1.25 I hope I didn't ever set any more agressive optimizing option than CFLAGS=-O2.