Le 23/12/2012 18:13, Julien Puydt a écrit :
I was all for throwing atlas a few days ago ; I have since been in touch
with Clint Whaley (reporting upstream my issues with #10508 [1]), and he
has been extremely reactive and efficient. That has definitely softened
my point of view on the matter.
I
On a related note, does anybody know MAGMA (not the number theory system,
silly). The BLAS implementation, aka Matrix Algebra on GPU and Multicore
Architectures: http://icl.cs.utk.edu/magma/
On Sunday, December 23, 2012 4:56:15 PM UTC, William wrote:
> I was at a conference a week ago with a bu
I don't want to *only* support OpenBlas and hardcode that into build
scripts instead of ATLAS. For one, it doesn't support ARM (=not at all) or
AMD Bulldozer (=probably not that fast on the newest AMD chip). There are
also bugs, so I would rather implement a more flexible setup than jump ship
c
Le 23/12/2012 18:36, William Stein a écrit :
On Sun, Dec 23, 2012 at 9:13 AM, Julien Puydt mailto:julien.pu...@laposte.net>> wrote:
In any case, the question of atlas vs openblas can only be asked
when sage will be blas-implementation-agnostic ;
Why? That's like saying the question of g
Why do I have openblas installed on my mac (intel) then? Recent openblas
require clang though. Haven't managed to compile it with gcc. Overall I like
openblas, I even put it on a BlueGene/P.
Francois
On 24/12/2012, at 5:57, "William Stein"
mailto:wst...@gmail.com>> wrote:
On Sun, Dec 23, 20
On Sun, Dec 23, 2012 at 9:13 AM, Julien Puydt wrote:
> Le 23/12/2012 17:56, William Stein a écrit :
>
> I was at a conference a week ago with a bunch of applied mathematicians
>> who are extremely experienced in high performance *numerical* computing
>> (at least compared to me). One strongly sug
Le 23/12/2012 17:56, William Stein a écrit :
I was at a conference a week ago with a bunch of applied mathematicians
who are extremely experienced in high performance *numerical* computing
(at least compared to me). One strongly suggested we simply dump ATLAS
for OpenBLAS (https://github.com/xian
On Sun, Dec 23, 2012 at 4:23 AM, Volker Braun wrote:
> The handling of BLAS/LAPACK libraries suck, Sage basically hardcodes ATLAS
> or OSX accelerate into the build process. Matrix operations are one place
> where using ISA extensions and careful choice of blocking to match
> processor cache real
On Sunday, December 23, 2012 3:41:10 PM UTC, Snark wrote:
>
> Nothing forces you to change the blas from compile-time to run-time
But we want
A) compile and link to BLAS (from 3rd party packages and from our own
Python extension classes).
B) run Sage with a fast BLAS which will require extra l
Le 23/12/2012 16:26, Volker Braun a écrit :
I know of course that the runtime linker can resolve the symbol even if
you didn't specify them at compile time, otherwise the dlopen()/dlsym()
would never work. But in practice that means that you have to switch
your libblas.so symlink all the time. Wh
I know of course that the runtime linker can resolve the symbol even if you
didn't specify them at compile time, otherwise the dlopen()/dlsym() would
never work. But in practice that means that you have to switch your
libblas.so symlink all the time. Whenever you compile something you need
the
Le 23/12/2012 14:18, Volker Braun a écrit :
You can pull out the rug under your feet if you have a dumb blas library
that doesn't depend on anything. It gets a bit more tricky if you have
library versions and dependencies (e.g. ATLAS cblas depends on pthreads
and libatlas, which you nowadays have
You can pull out the rug under your feet if you have a dumb blas library
that doesn't depend on anything. It gets a bit more tricky if you have
library versions and dependencies (e.g. ATLAS cblas depends on pthreads and
libatlas, which you nowadays have to specify on the linker command line).
Le 23/12/2012 13:23, Volker Braun a écrit :
The handling of BLAS/LAPACK libraries suck, Sage basically hardcodes
ATLAS or OSX accelerate into the build process. Matrix operations are
one place where using ISA extensions and careful choice of blocking to
match processor cache really matters, but w
The handling of BLAS/LAPACK libraries suck, Sage basically hardcodes ATLAS
or OSX accelerate into the build process. Matrix operations are one place
where using ISA extensions and careful choice of blocking to match
processor cache really matters, but we have no mechanism to use a good
implemen
15 matches
Mail list logo
