Fri 06 Apr 2012 04:45:40 PM UTC, comment #26:
With Nitzan's recent OpenBLAS libblas.dlls this is no more a problem.
The MSVC builds are also stable.
Closing this report.
|
Fri 06 Apr 2012 03:06:51 PM UTC, comment #25:
Ping! Is this still a problem with the latest 3.6.1 builds on MinGW?
|
Mon 05 Mar 2012 07:44:36 AM UTC, comment #24:
Hello Philip,
please recheck your installation because if you have found libblas.dll.altas3.9.19-2 in the 3.6.1 mingw binary - that shouldn't be there !
The only libblas dlls I have bundled are:
a. libblas.dll.ref - reference blas implementation, very slow but most stable
b. libblas.dll.libopenblas_dynamicarch-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, detects cpu architecture and selects respective lib
c. libblas.dll.libopenblas_dynamicarch_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, detects cpu architecture and selects respective lib
d. libblas.dll.libopenblas_nehalemp-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, tuned for nehalem cpu architecture
e. libblas.dll.libopenblas_nehalemp_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, tuned for nehalem cpu architecture
f. libblas.dll.libopenblas_core2p-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 2 threads, tuned for core2 cpu architecture
g. libblas.dll.libopenblas_core2p_nt4-r0.1alpha2.5-0-fda39c6 - Openblas based, up to 4 threads, tuned for core2 cpu architecture
h. libblas.dll.altas-3.8.4_ht-pentium - ATLAS based libblass, tuned for older ht-pentium (compiled by Tatsuro Matsuka)
i. libblas.dll.altas-3.8.4_corei5 - ATLAS based libblass, tuned for older core i5 cpu (compiled by Tatsuro Matsuka)
Last two are the atlas-3.8.4 you are asking for.
Nitzan
|
Sat 03 Mar 2012 09:52:57 PM UTC, comment #23:
The OpenBLAS dlls contained in the 3.6.1 MinGW binary are still unstable on my PCs.
The only ones that haven't crashed yet are
libblas.dll.refblas (on Pentium M & Core Duo)
and
libblas.dll.refblas + libblas.dll.libopenblas_dynamicarch-r0.1alpha2.5-0-fda39c6 (on Core Duo)
I used Tatsuro's test, see comment #1:
m = 10000; n = 32; temp = randn (m,n) + i*randn (m,n);
b = temp'* temp;
and:
graphics_toolkit fltk;
demo plotyy (usually segfaults on the second plot).
Where is atlas-3.8.4 dll? I'd love to try it.
In the 3.6.1 MinGW binary I can only find this one: libblas.dll.altas3.9.19-2
|
Sat 03 Mar 2012 08:23:18 PM UTC, comment #22:
I think that with Tatsuro's recent atlas-3.8.4 based dlls and with openblas based dlls which are used in octave-3.6.1 mingw build, this issue is solved.
Regards
Nitzan
|
Mon 13 Feb 2012 09:57:11 AM UTC, comment #21:
I have rebuild the OpenBLAS
The build reports are
The results were the mostly equaled to that were executed previously.
For my case, auto detection seems not to be effective.
|
Mon 13 Feb 2012 07:27:14 AM UTC, comment #20:
Hello Tatsuro
As far as I understand, the DYNAMIC_ARCH stores compiled versions for all architecture types in a single dll and upon initialization detects the host cpu architecture and select the proper one. It is possible that it doesn't properly detects your host cpu.
Your cpu (i5-2400) has 4 cores. Have you noticed "Max number of threads" printed by the make process when it finish building ? If it states that the maximal number of threads is 2, try to re-build with NUM_THREADS=4.
|
Mon 13 Feb 2012 04:18:50 AM UTC, comment #19:
I have tried dynamic arch build of OpenBLAS with DYNAMIC_ARCH=1
The performance test results are
On the other hand, simple build
make CC=i686-pc-mingw32-gcc FC=i686-pc-mingw32-gfortran TARGET=NEHALEM
The performance test results are
Simple build has rather higher performance than that of the dynamic architecture build for my case.
(My PC has a Core(TM)i5-2400CPU @3.1GHz, Perhaps Sandy bridge)
I think that the dynamic architecture is a better choice for the stability and convenience from the distribution point of view. However, the best ability can be available the CPU specific build.
|
Thu 09 Feb 2012 07:54:37 PM UTC, comment #18:
Regarding my previous post, the fntests for octave 3.6.0 were in-complete.
I have re-run the full fntests for Octave-mingw-3.4.3 for which I have the full building tree and have tried the OpenBLAS dll.
In relation to the original ATLAS dll (total 5 failures), for the OpenBLAS dll I have got additional 2 failures:
One for svds:
and one for dec2base
The svds failure may be acceptable but the dec2base failure should be explored.
|
Thu 09 Feb 2012 06:33:43 AM UTC, comment #17:
I didn't run "make check" but instead I have extracted the test sub-directory from
octave-3.6.0.tar.gz\octave-3.6.0.tar\octave-3.6.0\test
and run fntests. I hope it covers the same testing as "make check".
On my system (core i3) OpenBLAS passes the same tests as with ATLAS - 2 failures on test_system and some skipped tests.
The fntests.log:
|
Wed 08 Feb 2012 11:02:31 PM UTC, comment #16:
Because of unknown reason, using OpenBLAS at build stage give make check failures (octave crash!). Therefore I will continue to use the ATLAS for building octave. However, replacing libblas.dll by OpenBLAS gives only one more "make check" FAIL (test svds.m). However, the svds.m test FAIL is very delicate. It strongly dependent on the environments: https://savannah.gnu.org/bugs/?func=detailitem&item_id=29721
BTW, how about OpenBLAS old computer that uses Pentium-4. I have never tested.
Anyway libblas.dll can be replaceable so that we can prepare and provide libblas.dll even for the old CPU.
|
Wed 08 Feb 2012 08:29:38 PM UTC, comment #15:
Yes, the OpenBLAS license is completely acceptable for Octave, and I'm glad to see it being put to good use.
|
Wed 08 Feb 2012 08:03:24 PM UTC, comment #14:
I have successfully cross-compiled (cygwin to mingw) OpenBLAS for dynamic architecture. The created dll can be used on various platforms and suppose to automatically select the respective optimized code.
I have tried it on different machines (core, nehalem) with 2 and 4 cores and it give much better performance than the ATLAS3.9.19 dll (tuned by Tatsuro for core i5). I couldn't repoduce encounter the #34822 bug, at least with the reported test cases.
I think that this (OpenBLAS dynamic-architecture) dll may be suitable for the mingw binary distribution (at least as an alternative to Tatsuros re-compiled ATLAS 3.8).
I just wonder whether its licesnse (BSD ?) is compatible with octave license.
|
Sat 04 Feb 2012 12:35:53 AM UTC, comment #13:
I have recently successfully built ATLAS 3.8.4. This ATLAS seem to fix the issue. I will provide this binary for the Octave-3.6.1.
|
Fri 03 Feb 2012 03:48:05 PM UTC, comment #12:
Trying Nitzan's code from comment #1 makes my Octave-3.6.0 MinGW window disappear -> i.e., a hard crash.
|
Sat 28 Jan 2012 08:02:58 PM UTC, comment #11:
The question is different to answer. For Atals-3.9.19 for Cerelon-M and Ht-pentium I worked long ago. However, ATLAS-3.9.19 is rather old(Decemner 2009). So I tried ATLAS-3.8.4 (May 2011), which is rather new. And ATLAS 3.8.4 is stable release on a lot of ATLAS releases.
Build for 3.8.4 for corei5 seems to be good. And I also tried changing compiler to gcc-4.5.3 and 4.6.2. Combination gcc-4.5.3 and ATLAS 4.8.4 seems to be fine. I have to try the combination to older CPUs. However they are time consuming events so that I have not completed yet.
This is my guess at the moment. We cannot prepare one blas that works fine on all CPUs. We have to compromise on this point. Otherwise it is better prepare to some kinds of blas (ALTAS and openBLAS). It is also important the way the generating optimized blas for the users' CPU on the wiki.
|
Fri 27 Jan 2012 07:36:16 AM UTC, comment #10:
Hello Tatsuro,
Regarding the compilation of ALTALS-3.9.19 with gcc+gfortran-4.3.4, can you elaborate how the optimization can be controlled for different target cpus ?
|
Fri 27 Jan 2012 01:26:54 AM UTC, comment #9:
I have succeed to buils ATLAS 3.8.4. That is newer than ATLAS 3.9.19.
However, simple replacement of libblas.dll could not be made due to the DLL entry point error. One has to build octave with the ALTAS 3.8.4.
Now I have complied gcc-4.6.2 on the cygwin and could build this new altas.
However, with this new atlas, the number of make check error increased. The reason is not understandable.
I will look into further.
|
Mon 23 Jan 2012 07:18:36 AM UTC, comment #8:
I have upload a new BLAS (ATLAS 3.9.19 optimized for Core i5).
http://www.tatsuromatsuoka.com/octave/Eng/Win/
|
Mon 23 Jan 2012 07:06:33 AM UTC, comment #7:
For the ATLAS, I have not gotten successful result for the cross compiling. I have been used a tricky technique to build the ATLAS.
First I have built gcc + gfortran (4.3.4) on the cygwin without any cygwin specific patches.
With this gcc, I can build the ATLAS libraries which can be linked the MinGW gcc.
copy lib*.a /usr/local/atlas/lib to the appropriate directory.
Then
You can get libblas.dll and libblas.dll.a
The reason why I use the ATLAS 3.9.19 is a mere incident.
I have tried the recent version of the ATLAS but the builds have been in failure.
I will upload the libblas optimized for Core i5-2400 CPU @ 3.10 GHz on my web site.
I will continue to struggle with the ATLAS and the OpenBLAS.
The Matrix calculation seem to depend on the combination the BLAS and the CPU on the PC.
We may have to prepare sevral kind of BLAS packages for the END user.
|
Sun 22 Jan 2012 07:56:35 AM UTC, comment #6:
I have tested Tatsuro's compilation of 3.6.0/OctaveLibs/gplibs (gcc 462)
I am getting this crash with
a. Tatsuro's libblas.dll (from OctaveLibs.7z bin)
b. Tatsuro's libblas.dll.altas3.9.19-2 (from OctaveLibs.7z bin, renamed to libblas.dll) - this binary is almost identical to the original libblas.dll in OctaveLibs.7z bin !
I am not getting this crash with
c. libblas.dll.openblas_a546694 (from OctaveLibs.7z bin, renamed to libblas.dll)
d. libblas.dll cross compiled (by myself using cygwin) from openblas source
Tatsuro, can you give more details and references to the ATLAS-3.9.19 based libblas you have cross compiled which has passed this test ?
|
Sat 24 Dec 2011 10:59:00 PM UTC, comment #5:
I have tested on my PC at home using libblas from ATLAS-3.9.19.
This ATLAS blas was made by the used PC itself.
The test
did not cause error.
I think that the phenomena come from the combination of the blas and the CPU used.
|
Wed 16 Nov 2011 11:24:01 PM UTC, comment #4:
Sorry for not giving enough information.
I have uplaod libblas.dll in zip form:
http://www.tatsuromatsuoka.com/octave/Eng/Win/
OpenBlasdll.zip
I have forgotten to write important point
in section 3 of
http://wiki.octave.org/wiki.pl?action=browse&id=OctaveForWindows&revision=248
To make libblas.dll which is replaceable with libblas.dll in current octave 3.4 distribution, the following for example is required.
Hope this helps
|
Wed 16 Nov 2011 06:06:53 PM UTC, comment #3:
Tatsuro,
It seems that some details are missing from the end of your post.
Can you please provide more information regarding how you have cross compiled libblas.dll from openblas ?
I have tried to follow the procedure from section 3 of
http://wiki.octave.org/wiki.pl?action=browse&id=OctaveForWindows&revision=248
and for some reason I am getting 'The procedure entry point ilaenv_ could not be located in the dynamic link library libblas.dll' error when starting octave, I assume that there is a problem with dll I have built.
Is it possible that you will upload the dll that you have built to your site ?
Nitzan
|
Wed 16 Nov 2011 03:20:52 AM UTC, comment #2:
I have confirmed that
caused segfault.
However, I have replaced libblas.dll by produced by Openblas on my computer (core-i5, win 7 64bit).
Segfault did not occur.
I have not been successful result building the ATLAS on my computer.
I did
|
Mon 14 Nov 2011 07:44:42 PM UTC, comment #1:
On mingw 3.4.3 and 3.4.2, win7-x64, no packages loaded,
running the following code cause a segmentation violation:
The crash may happen also when running several time with smaller m:
On my system, the crash occurs on the second loop when ii=11.
|
Mon 14 Nov 2011 07:40:47 PM UTC, original submission:
On mingw 3.4.3 and 3.4.2, win7-x64, no packages loaded,
running the following code cause a segmentation violation:
|