Carl Kleffner wrote:
> MKL BLAS LAPACK has issues as well:
> href="http://software.intel.com/en-us/articles/intel-mkl-110-bug-fixes";>http://software.intel.com/en-us/articles/intel-mkl-110-bug-fixes
> .
> In case of OpenBLAS or GOTOBLAS what precisly is the problem you identify
> as showstopper?
Matthew Brett wrote:
> Put another way - does anyone know what bugs in gotoBLAS2 do arise for
> Windows / Intel builds?
http://www.openblas.net/Changelog.txt
There are some bug fixes for x86_64 here.
GotoBLAS (and GotoBLAS2) were the de facto BLAS on many HPC systems, and
are well proven. But
MKL BLAS LAPACK has issues as well:
http://software.intel.com/en-us/articles/intel-mkl-110-bug-fixes .
In case of OpenBLAS or GOTOBLAS what precisly is the problem you identify
as showstopper?
Regards
Carl
2014-04-06 20:59 GMT+02:00 Matthew Brett :
> Hi,
>
> On Sun, Apr 6, 2014 at 11:47 AM,
Hi,
On Sun, Apr 6, 2014 at 11:47 AM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> Julian - do you have any opinion on using gotoBLAS instead of OpenBLAS
>> for the Windows binaries?
>
> That is basically OpenBLAS too, except with more bugs and no AVX support.
I know that OpenBLAS is a fork
Matthew Brett wrote:
> Julian - do you have any opinion on using gotoBLAS instead of OpenBLAS
> for the Windows binaries?
That is basically OpenBLAS too, except with more bugs and no AVX support.
Sturla
___
NumPy-Discussion mailing list
NumPy-Discuss
Hi,
On Wed, Mar 26, 2014 at 11:34 AM, Julian Taylor
wrote:
> On 26.03.2014 16:27, Olivier Grisel wrote:
>> Hi Carl,
>>
>> I installed Python 2.7.6 64 bits on a windows server instance from
>> rackspace cloud and then ran get-pip.py and then could successfully
>> install the numpy and scipy wheel
2014-04-03 14:56 GMT+02:00 Julian Taylor :
> FYI, binaries linking openblas should add this patch in some way:
> https://github.com/numpy/numpy/pull/4580
>
> Cliffs: linking OpenBLAS prevents parallelization via threading or
> multiprocessing.
>
> just wasted a bunch of time figuring that out ... (
FYI, binaries linking openblas should add this patch in some way:
https://github.com/numpy/numpy/pull/4580
Cliffs: linking OpenBLAS prevents parallelization via threading or
multiprocessing.
just wasted a bunch of time figuring that out ... (though its well
documented in numerous stackoverflow
Hi,
On Wed, Mar 26, 2014 at 11:34 AM, Julian Taylor
wrote:
> On 26.03.2014 16:27, Olivier Grisel wrote:
>> Hi Carl,
>>
>> I installed Python 2.7.6 64 bits on a windows server instance from
>> rackspace cloud and then ran get-pip.py and then could successfully
>> install the numpy and scipy wheel
Nathaniel Smith wrote:
> I thought OpenBLAS is usually used with reference lapack?
It is.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
2014-03-28 22:55 GMT+01:00 Julian Taylor :
> On 28.03.2014 22:38, Olivier Grisel wrote:
>> 2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
>>> I thought OpenBLAS is usually used with reference lapack?
>>
>> I am no longer sure myself. Debian & thus Ubuntu seem to be only
>> packaging the BLAS part of
On 28.03.2014 22:38, Olivier Grisel wrote:
> 2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
>> I thought OpenBLAS is usually used with reference lapack?
>
> I am no longer sure myself. Debian & thus Ubuntu seem to be only
> packaging the BLAS part of OpenBLAS for the libblas.so symlink and
> uses th
2014-03-28 22:18 GMT+01:00 Nathaniel Smith :
> I thought OpenBLAS is usually used with reference lapack?
I am no longer sure myself. Debian & thus Ubuntu seem to be only
packaging the BLAS part of OpenBLAS for the libblas.so symlink and
uses the reference implementation of lapack for the liblapack
I thought OpenBLAS is usually used with reference lapack?
On 28 Mar 2014 22:16, "Matthew Brett" wrote:
> Hi,
>
> On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden
> wrote:
> > Nathaniel Smith wrote:
> >
> >> If the only problem with eigen turns out to be that we have to add a
> line
> >> of text t
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden wrote:
> Nathaniel Smith wrote:
>
>> If the only problem with eigen turns out to be that we have to add a line
>> of text to a file then I think we can probably manage this somehow.
>
> We would also have to compile Eigen-BLAS for various archit
Hi,
On Fri, Mar 28, 2014 at 12:57 PM, Robert Kern wrote:
> Of course, that's besides the point. Yes, pretty much everyone that likes
> the BSD license of numpy will be okay with the minimal burdens the MPL2 lays
> on them. The problem is that we need to properly communicate that license.
> The P
Nathaniel Smith wrote:
> If the only problem with eigen turns out to be that we have to add a line
> of text to a file then I think we can probably manage this somehow.
We would also have to compile Eigen-BLAS for various architectures and CPU
counts. It is not "adaptive" like MKL or OpenBLAS.
Yes, because they're distributing source. But *our* license file could
contain the text of the BSD, the text of the MPL, and the text "Eigen
source is available at http://eigen.org.";
If the only problem with eigen turns out to be that we have to add a line
of text to a file then I think we can pr
Of course, that's besides the point. Yes, pretty much everyone that likes
the BSD license of numpy will be okay with the minimal burdens the MPL2
lays on them. The problem is that we need to properly communicate that
license. The PyPI page is not adequate to that task, in my opinion. I have
no pro
On 28 March 2014 19:56, Sturla Molden wrote:
> Matthew Brett wrote:
>
> > Does anyone know how their performance compares to MKL or the
> > reference implementations?
>
> http://eigen.tuxfamily.org/index.php?title=Benchmark
Very, very funny and twisted approach to legend-ordering-in-a-plot
ap
No, the license does not contain a pointer to the Eigen sources, which is
required.
https://bitbucket.org/eigen/eigen/src/fabd880592ac3343713cc07e7287098afd0f18ca/COPYING.MPL2?at=default
On Mar 28, 2014 7:34 PM, "Nathaniel Smith" wrote:
> On 28 Mar 2014 20:26, "Robert Kern" wrote:
> >
> > It's
The BSD license alters the recipient's rights. BSD binaries can be
redistributed without pointing to the sources.
On Mar 28, 2014 7:33 PM, "Matthew Brett" wrote:
> Hi,
>
> On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern
> wrote:
> > It's only a problem in that the binary will not be BSD, and we do
On 28 Mar 2014 20:26, "Robert Kern" wrote:
>
> It's only a problem in that the binary will not be BSD, and we do need to
communicate that appropriately. It will contain a significant component
that is MPL2 licensed. The terms that force us to include the link to the
Eigen source that we used force
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern wrote:
> It's only a problem in that the binary will not be BSD, and we do need to
> communicate that appropriately. It will contain a significant component that
> is MPL2 licensed. The terms that force us to include the link to the Eigen
> source
Hi,
On Fri, Mar 28, 2014 at 11:56 AM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> Does anyone know how their performance compares to MKL or the
>> reference implementations?
>
> http://eigen.tuxfamily.org/index.php?title=Benchmark
I don't know how relevant these are to our case. If I under
It's only a problem in that the binary will not be BSD, and we do need to
communicate that appropriately. It will contain a significant component
that is MPL2 licensed. The terms that force us to include the link to the
Eigen source that we used forces downstream redistributors of the binary to
do
On Fri, Mar 28, 2014 at 8:01 PM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> So - is Eigen our best option for optimized blas / lapack binaries on
>> 64 bit Windows?
>
> Maybe not:
>
> http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
>
> With AVX the difference is possibly
Matthew Brett wrote:
> So - is Eigen our best option for optimized blas / lapack binaries on
> 64 bit Windows?
Maybe not:
http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
With AVX the difference is possibly even larger.
Sturla
__
Matthew Brett wrote:
> Does anyone know how their performance compares to MKL or the
> reference implementations?
http://eigen.tuxfamily.org/index.php?title=Benchmark
http://gcdart.blogspot.de/2013/06/fast-matrix-multiply-and-ml.html
Sturla
___
Nu
Hi,
On Fri, Mar 28, 2014 at 8:58 AM, Robert Kern wrote:
> On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden
> wrote:
>> Matthew Brett wrote:
>>
>>> I see it should be possible to build a full blas and partial lapack
>>> library with eigen [1] [2].
>>
>> Eigen has a licensing issue as well, unfort
On Fri, Mar 28, 2014 at 4:58 PM, Robert Kern wrote:
> On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden
> wrote:
>> Matthew Brett wrote:
>>
>>> I see it should be possible to build a full blas and partial lapack
>>> library with eigen [1] [2].
>>
>> Eigen has a licensing issue as well, unfortunate
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden wrote:
> Matthew Brett wrote:
>
>> I see it should be possible to build a full blas and partial lapack
>> library with eigen [1] [2].
>
> Eigen has a licensing issue as well, unfortunately, MPL2.
>
> E.g. it requires recipients to be informed of the
On 3/28/2014 10:54 AM, Sturla Molden wrote:
> Eigen has a licensing issue as well, unfortunately, MPL2.
>
> E.g. it requires recipients to be informed of the MPL requirements (cf.
> impossible with pip install numpy).
Eigen chose MPL2 with the intent that Eigen be usable by
"all projects".
http:/
On Fri, Mar 28, 2014 at 3:31 PM, Alan G Isaac wrote:
> On 3/28/2014 10:54 AM, Sturla Molden wrote:
>> Eigen has a licensing issue as well, unfortunately, MPL2.
>>
>> E.g. it requires recipients to be informed of the MPL requirements (cf.
>> impossible with pip install numpy).
>
> Eigen chose MPL2
Matthew Brett wrote:
> I see it should be possible to build a full blas and partial lapack
> library with eigen [1] [2].
Eigen has a licensing issue as well, unfortunately, MPL2.
E.g. it requires recipients to be informed of the MPL requirements (cf.
impossible with pip install numpy).
Sturl
Hi,
On Wed, Mar 26, 2014 at 1:41 PM, Nathaniel Smith wrote:
> On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
> wrote:
>> as for using openblas by default in binary builds, no.
>> pthread openblas build is now fork safe which is great but it is still
>> not reliable enough for a default.
>> E.g.
On Thu, Mar 27, 2014 at 9:59 AM, Olivier Grisel
wrote:
> 2014-03-27 14:55 GMT+01:00 :
>> On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
>> wrote:
>>> My understanding of Carl's effort is that the long term goal is to
>>> have official windows whl packages for both numpy and scipy published
>>>
2014-03-27 14:55 GMT+01:00 :
> On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
> wrote:
>> My understanding of Carl's effort is that the long term goal is to
>> have official windows whl packages for both numpy and scipy published
>> on PyPI with a builtin BLAS / LAPACK implementation so that use
On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
wrote:
> My understanding of Carl's effort is that the long term goal is to
> have official windows whl packages for both numpy and scipy published
> on PyPI with a builtin BLAS / LAPACK implementation so that users can
> do `pip install scipy` under
2014-03-26 16:27 GMT+01:00 Olivier Grisel :
> Hi Carl,
>
> I installed Python 2.7.6 64 bits on a windows server instance from
> rackspace cloud and then ran get-pip.py and then could successfully
> install the numpy and scipy wheel packages from your google drive
> folder. I tested dot products and
2014-03-26 22:31 GMT+01:00 Julian Taylor :
> On 26.03.2014 22:17, Olivier Grisel wrote:
>>
>> The problem with ATLAS is that you need to select the number of thread
>> at build time AFAIK. But we could set it to a reasonable default (e.g.
>> 4 threads) for the default windows package.
>>
>
> You ha
On 26.03.2014 22:17, Olivier Grisel wrote:
>
> The problem with ATLAS is that you need to select the number of thread
> at build time AFAIK. But we could set it to a reasonable default (e.g.
> 4 threads) for the default windows package.
>
You have to set the number of threads at build time with
My understanding of Carl's effort is that the long term goal is to
have official windows whl packages for both numpy and scipy published
on PyPI with a builtin BLAS / LAPACK implementation so that users can
do `pip install scipy` under windows and get something that just works
without have to insta
On 26.03.2014 21:41, Nathaniel Smith wrote:
> On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
> wrote:
>> as for using openblas by default in binary builds, no.
>> pthread openblas build is now fork safe which is great but it is still
>> not reliable enough for a default.
>> E.g. the current latest
On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
wrote:
> as for using openblas by default in binary builds, no.
> pthread openblas build is now fork safe which is great but it is still
> not reliable enough for a default.
> E.g. the current latest release 0.2.8 still has one crash bug on
> dgemv[1]
On 26.03.2014 16:27, Olivier Grisel wrote:
> Hi Carl,
>
> I installed Python 2.7.6 64 bits on a windows server instance from
> rackspace cloud and then ran get-pip.py and then could successfully
> install the numpy and scipy wheel packages from your google drive
> folder. I tested dot products and
Hi Carl,
I installed Python 2.7.6 64 bits on a windows server instance from
rackspace cloud and then ran get-pip.py and then could successfully
install the numpy and scipy wheel packages from your google drive
folder. I tested dot products and scipy.linalg.svd and they work as
expected.
Then I un
2014-02-20 23:56 GMT+01:00 Carl Kleffner :
> Hi,
>
> 2014-02-20 23:17 GMT+01:00 Olivier Grisel :
>
>> I had a quick look (without running the procedure) but I don't
>> understand some elements:
>>
>> - apparently you never tell in the numpy's site.cfg nor the scipy.cfg
>> to use the openblas lib no
Hi,
2014-02-20 23:17 GMT+01:00 Olivier Grisel :
> I had a quick look (without running the procedure) but I don't
> understand some elements:
>
> - apparently you never tell in the numpy's site.cfg nor the scipy.cfg
> to use the openblas lib nor set the
> library_dirs: how does numpy.distutils kno
I had a quick look (without running the procedure) but I don't
understand some elements:
- apparently you never tell in the numpy's site.cfg nor the scipy.cfg
to use the openblas lib nor set the
library_dirs: how does numpy.distutils know that it should dynlink
against numpy/core/libopenblas.dll
2014-02-20 16:01 GMT+01:00 Julian Taylor :
>
> this is probably caused by the memory warmup
> it can be disabled with NO_WARMUP=1 in some configuration file.
This was it, I now get:
>>> import os, psutil
>>> psutil.Process(os.getpid()).get_memory_info().rss / 1e6
20.324352
>>> %time import numpy
good point, I didn't used this option.
Carl
2014-02-20 16:01 GMT+01:00 Julian Taylor :
> On Thu, Feb 20, 2014 at 3:50 PM, Olivier Grisel
> wrote:
> > Thanks for sharing, this is all very interesting.
> >
> > Have you tried to have a look at the memory usage and import time of
> > numpy when li
looked at the taskmanager there is not much difference to numpy-MKL. I
didn't made any qualified measurements however.
Carl
2014-02-20 15:50 GMT+01:00 Olivier Grisel :
> Thanks for sharing, this is all very interesting.
>
> Have you tried to have a look at the memory usage and import time of
>
On Thu, Feb 20, 2014 at 3:50 PM, Olivier Grisel
wrote:
> Thanks for sharing, this is all very interesting.
>
> Have you tried to have a look at the memory usage and import time of
> numpy when linked against libopenblas.dll?
>
> --
this is probably caused by the memory warmup
it can be disabled w
Thanks for sharing, this is all very interesting.
Have you tried to have a look at the memory usage and import time of
numpy when linked against libopenblas.dll?
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.
Hi,
some days ago I put some preliminary mingw-w64 binaries and code based on
python2.7 on my google drive to discuss it with Matthew Brett. Maybe its
time for a broader discussion. IMHO it is ready for testing but not for
consumption.
url:
https://drive.google.com/folderview?id=0B4DmELLTwYmldUVp
FYI: to build scipy against OpenBLAS I used the following site.cfg at
the root of my scipy source folder:
[DEFAULT]
library_dirs = /opt/OpenBLAS-noomp/lib:/usr/local/lib
include_dirs = /opt/OpenBLAS-noomp/include:/usr/local/include
[blas_opt]
libraries = openblas
[lapack_opt]
libraries = openbla
2014-02-20 14:28 GMT+01:00 Sturla Molden :
> Will this mean NumPy, SciPy et al. can start using OpenBLAS in the
> "official" binary packages, e.g. on Windows and Mac OS X? ATLAS is slow and
> Accelerate conflicts with fork as well.
This what I would like to do personnally. Ideally as a distributio
Will this mean NumPy, SciPy et al. can start using OpenBLAS in the
"official" binary packages, e.g. on Windows and Mac OS X? ATLAS is slow and
Accelerate conflicts with fork as well.
Will dotblas be built against OpenBLAS? AFAIK, it is only buit against
ATLAS or MKL, not any other BLAS, but it sh
2014-02-20 11:32 GMT+01:00 Julian Taylor :
> On Thu, Feb 20, 2014 at 1:25 AM, Nathaniel Smith wrote:
>> Hey all,
>>
>> Just a heads up: thanks to the tireless work of Olivier Grisel, the OpenBLAS
>> development branch is now fork-safe when built with its default threading
>> support. (It is still
On Thu, Feb 20, 2014 at 1:25 AM, Nathaniel Smith wrote:
> Hey all,
>
> Just a heads up: thanks to the tireless work of Olivier Grisel, the OpenBLAS
> development branch is now fork-safe when built with its default threading
> support. (It is still not thread-safe when built using OMP for threading
Hey all,
Just a heads up: thanks to the tireless work of Olivier Grisel, the
OpenBLAS development branch is now fork-safe when built with its default
threading support. (It is still not thread-safe when built using OMP for
threading and gcc, but this is not the default.)
Gory details: https://git
62 matches
Mail list logo
