octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenBLAS discussion (was Re: [bug #34822] Mingw panics on a simple c


From: Tatsuro MATSUOKA
Subject: Re: OpenBLAS discussion (was Re: [bug #34822] Mingw panics on a simple complex product)
Date: Tue, 14 Feb 2012 10:19:07 +0900 (JST)

Hello

OpenBLAS build is finished before I leave the University.

With the patch without TARGET, OpenBLAS seem to detect this CPU as NEHALEM.
However, the results are performing test are the almost same as before,

n=2000; A=randn(n); B=randn(n);tic; C=A*B; t=toc, MFLOPS=2*n^3/t*1e-6
t =  0.96906
MFLOPS = 1.6511e+004
t =  0.97506
MFLOPS = 1.6409e+004
t =  0.96706
MFLOPS = 1.6545e+004
t =  1.0071
MFLOPS = 1.5888e+004
t =  0.99406
MFLOPS = 1.6096e+004
  
I think it is better to ask at OpenBLAS ML.  I will do it in the near future.

Regards

Tatsuro 
--- On Tue, 2012/2/14, Tatsuro MATSUOKA wrote:

> Hello
> 
> Nitzan and I have been talking about the OpenBLAS at the end part of bug 
> tracker id: #34822. (http://savannah.gnu.org/bugs/?34822)
> 
> OpenBLAS is a powerful bsd licensed free blas and can be used with Octave.
> From this reason, I have post a rely to the maintainers list with cc.
> 
> ******* Reply to the Nitzan 
> I have read https://github.com/xianyi/OpenBLAS/issues/69.
> 
> The commitment
> https://github.com/xianyi/OpenBLAS/commit/fe613de8e1b72b8225e81556511ac22ea1e2201d
> 
> has not been included in the recent tar ball of the source archive.
> I will manually modify the code using the above commitment.
> Today I do not have enough time. I will report the result tomorrow.
> Thank you very much for your investigation and giving me information.
> *************
> 
> Regards
> 
> Tatsuro
> --- On Tue, 2012/2/14, Nit Nit wrote:
> 
> > 
> > Hello Tatsuro,
> > 
> > I am writing this message directly to you and not to the bug tracker since 
> > I think that this response is not related to that bug.
> > 
> > Regarding your tests with OpenBlas on your i5 cpu, it seems that there was 
> > really a problem with auto-detection of Sandy-Bridge (as Nehalem) in the 
> > recent master branch but this problem has been just fixed TODAY by the 
> > OpenBlas author in the development branch.
> > 
> > See the discussion in https://github.com/xianyi/OpenBLAS/issues/69.
> > 
> > I do not have a sandy-bridge cpu so I can't test it but it seems that if 
> > you will apply the change in 
> > https://github.com/xianyi/OpenBLAS/commit/fe613de8e1b72b8225e81556511ac22ea1e2201d
> > (link taken from the discussion thread) and test it on your machine, it 
> > will help the author verifying the fix and we may really have a single 
> > libblas dll which may be optimized and auto-detects multiple architectures.
> > 
> > Please note - the issue is labeled as:
> > "refs #69. Auto-detect Intel Core i6/i7 (Sandy Bridge) CPU with Nehale…"
> > but it deals with sandy-bridge core i5/i7 (probably i6 is a tipo mistake) 
> > which include your i5-2400 machine.
> > 
> > Regards
> > Nitzan
> > 
> > On Mon, Feb 13, 2012 at 11:57 AM, Tatsuro MATSUOKA <address@hidden> wrote:
> > Follow-up Comment #21, bug #34822 (project octave):
> > 
> > I have rebuild the OpenBLAS
> > 
> > 
> > 
> > make CC=i686-pc-mingw32-gcc FC=i686-pc-mingw32-gfortran DYNAMIC_ARCH=1
> > TARGET=NEHALEM NUM_THREADS=4
> > 
> > 
> > The build reports are
> > 
> >  OpenBLAS build complete.
> > 
> >   OS               ... WINNT
> >   Architecture     ... x86
> >   BINARY           ... 32bit
> >   C compiler       ... GCC  (command line : i686-pc-mingw32-gcc)
> >   Fortran compiler ... GFORTRAN  (command line : i686-pc-mingw32-gfortran)
> >   Library Name     ... libopenblasp-r0.1alpha2.4.lib (Multi threaded; Max
> > num-threads is 4)
> > 
> > 
> > 
> > 
> > octave:1>  n=2000; A=randn(n); B=randn(n);tic; C=A*B; t=toc,
> > MFLOPS=2*n^3/t*1e-6
> > t =  0.96606
> > MFLOPS = 1.6562e+004
> > t =  1.0561
> > MFLOPS = 1.5151e+004
> > t =  0.97106
> > MFLOPS = 1.6477e+004
> > t =  1.1741
> > MFLOPS = 1.3628e+004
> > t =  0.95905
> > MFLOPS = 1.6683e+004
> > 
> > 
> > 
> > The results were the mostly equaled to that were executed previously.
> > 
> > For my case, auto detection seems not to be effective.
> > 
> > 
> > 
> >     _______________________________________________________
> > 
> > Reply to this item at:
> > 
> >   <http://savannah.gnu.org/bugs/?34822>
> > 
> > _______________________________________________
> >   Message sent via/by Savannah
> >   http://savannah.gnu.org/
> > 
> > 
> >
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]