Hi,
On Wed, Mar 26, 2014 at 11:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com 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
Matthew Brett matthew.br...@gmail.com 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
Hi,
On Sun, Apr 6, 2014 at 11:47 AM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com 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
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 matthew.br...@gmail.com:
Hi,
On Sun, Apr
Matthew Brett matthew.br...@gmail.com 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
Carl Kleffner cmkleff...@gmail.com wrote:
MKL BLAS LAPACK has issues as well:
a
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/a
.
In case of OpenBLAS or GOTOBLAS what precisly is the problem you identify
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
2014-04-03 14:56 GMT+02:00 Julian Taylor jtaylor.deb...@googlemail.com:
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
Hi,
On Wed, Mar 26, 2014 at 11:34 AM, Julian Taylor
jtaylor.deb...@googlemail.com 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
Hi,
On Wed, Mar 26, 2014 at 1:41 PM, Nathaniel Smith n...@pobox.com wrote:
On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
jtaylor.deb...@googlemail.com 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
Matthew Brett matthew.br...@gmail.com 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
On Fri, Mar 28, 2014 at 3:31 PM, Alan G Isaac alan.is...@gmail.com 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
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.
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com 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
On Fri, Mar 28, 2014 at 4:58 PM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen [1]
Hi,
On Fri, Mar 28, 2014 at 8:58 AM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Mar 28, 2014 at 2:54 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Matthew Brett matthew.br...@gmail.com wrote:
I see it should be possible to build a full blas and partial lapack
library with eigen
Matthew Brett matthew.br...@gmail.com 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
Matthew Brett matthew.br...@gmail.com 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
On Fri, Mar 28, 2014 at 8:01 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com 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
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
Hi,
On Fri, Mar 28, 2014 at 11:56 AM, Sturla Molden sturla.mol...@gmail.com wrote:
Matthew Brett matthew.br...@gmail.com 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
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern robert.k...@gmail.com 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
On 28 Mar 2014 20:26, Robert Kern robert.k...@gmail.com 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
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 matthew.br...@gmail.com wrote:
Hi,
On Fri, Mar 28, 2014 at 12:26 PM, Robert Kern robert.k...@gmail.com
wrote:
It's only a problem in that
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 n...@pobox.com wrote:
On 28 Mar 2014 20:26, Robert Kern
On 28 March 2014 19:56, Sturla Molden wrote:
Matthew Brett matthew.br...@gmail.com 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
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
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
Nathaniel Smith n...@pobox.com 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
Hi,
On Fri, Mar 28, 2014 at 12:57 PM, Robert Kern robert.k...@gmail.com 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
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com 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
I thought OpenBLAS is usually used with reference lapack?
On 28 Mar 2014 22:16, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Fri, Mar 28, 2014 at 1:28 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Nathaniel Smith n...@pobox.com wrote:
If the only problem with eigen turns out
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
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
On 28.03.2014 22:38, Olivier Grisel wrote:
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
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
2014-03-28 22:55 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
On 28.03.2014 22:38, Olivier Grisel wrote:
2014-03-28 22:18 GMT+01:00 Nathaniel Smith n...@pobox.com:
I thought OpenBLAS is usually used with reference lapack?
I am no longer sure myself. Debian thus Ubuntu seem to be
Nathaniel Smith n...@pobox.com 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-26 16:27 GMT+01:00 Olivier Grisel olivier.gri...@ensta.org:
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
On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
olivier.gri...@ensta.org 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
2014-03-27 14:55 GMT+01:00 josef.p...@gmail.com:
On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
olivier.gri...@ensta.org 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
On Thu, Mar 27, 2014 at 9:59 AM, Olivier Grisel
olivier.gri...@ensta.org wrote:
2014-03-27 14:55 GMT+01:00 josef.p...@gmail.com:
On Wed, Mar 26, 2014 at 5:17 PM, Olivier Grisel
olivier.gri...@ensta.org wrote:
My understanding of Carl's effort is that the long term goal is to
have official
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
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
On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
jtaylor.deb...@googlemail.com 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
On 26.03.2014 21:41, Nathaniel Smith wrote:
On Wed, Mar 26, 2014 at 7:34 PM, Julian Taylor
jtaylor.deb...@googlemail.com 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.
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
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
2014-03-26 22:31 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
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
2014-02-20 23:56 GMT+01:00 Carl Kleffner cmkleff...@gmail.com:
Hi,
2014-02-20 23:17 GMT+01:00 Olivier Grisel olivier.gri...@ensta.org:
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
On Thu, Feb 20, 2014 at 1:25 AM, Nathaniel Smith n...@pobox.com 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
2014-02-20 11:32 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
On Thu, Feb 20, 2014 at 1:25 AM, Nathaniel Smith n...@pobox.com 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
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
2014-02-20 14:28 GMT+01:00 Sturla Molden sturla.mol...@gmail.com:
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.
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 =
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:
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
On Thu, Feb 20, 2014 at 3:50 PM, Olivier Grisel
olivier.gri...@ensta.org 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
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 olivier.gri...@ensta.org:
Thanks for sharing, this is all very interesting.
Have you tried to have a look at the memory usage
good point, I didn't used this option.
Carl
2014-02-20 16:01 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
On Thu, Feb 20, 2014 at 3:50 PM, Olivier Grisel
olivier.gri...@ensta.org wrote:
Thanks for sharing, this is all very interesting.
Have you tried to have a look at the
2014-02-20 16:01 GMT+01:00 Julian Taylor jtaylor.deb...@googlemail.com:
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
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
Hi,
2014-02-20 23:17 GMT+01:00 Olivier Grisel olivier.gri...@ensta.org:
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
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:
62 matches
Mail list logo
