Specifying the location of ATLAS/etc.
David Warde-Farley
I've checked out the most recent theano snapshot and have tried to run
the nosetests, however I notice that it isn't finding my (custom-
built) ATLAS libraries in an odd location (/opt/sw/ATLAS). Setting
LD_LIBRARY_PATH, or LDFLAGS hasn't helped, and putting the relevant -L
in the blas.ldflags setting in .theanorc only yields an error message
about how that is not allowed (d'oh! ;).
Any hints on how to tell theano where to find ATLAS? I should note
that NumPy already knows where it is and uses it quite successfully.
Thanks,
David
Frédéric Bastien
We don't use LD_LIBRARY_PATH or LDFLAGS to pass parameter to theano. For the full documentation see: http://deeplearning.net/software/theano/library/config.html
The fast answer is to put the environement variable:
THEANO_FLAGS=blas.ldflags="ALL_PARAMETER NEEDEDE TO COMPILE WITH YOUR BLAS"
Here we use: THEANO_FLAGS=blas.ldflags="-lgoto -lgfortran"
The full documentation tell how to put that into a configuration file if you prefer that way.
If that don't work, can you give us the error message?
thanks
Fred
James Bergstra
> Hi,
>
> We don't use LD_LIBRARY_PATH or LDFLAGS to pass parameter to theano. For the
> full documentation see:
> http://deeplearning.net/software/theano/library/config.html
>
> The fast answer is to put the environement variable:
>
> THEANO_FLAGS=blas.ldflags="ALL_PARAMETER NEEDEDE TO COMPILE WITH YOUR BLAS"
> Here we use: THEANO_FLAGS=blas.ldflags="-lgoto -lgfortran"
>
> The full documentation tell how to put that into a configuration file if you
> prefer that way.
The passing of -L flags to blas.ldflags is not implemented (yet).
I expect it to work for you if you add the /opt/sw/ATLAS to you
LD_LIBRARY_PATH, because in that case it should take the -l options
from numpy and compile correctly.
If that fails, please email the list because it's a bug (well... it's
basically already a bug that -L options are not allowed...). In that
case I would also be curious what happens when you add that directory
to LD_LIBRARY_PATH *and* add the small-l flags to blas.ldflags.
Sorry there are still some wrinkles around the libpaths with blas...
but your feedback would be appreciated.
Olivier Delalleau
> The passing of -L flags to blas.ldflags is not implemented (yet).
>
> I expect it to work for you if you add the /opt/sw/ATLAS to you
> LD_LIBRARY_PATH, because in that case it should take the -l options
> from numpy and compile correctly.
Just a note: I may be wrong, but as far as I know gcc uses
LIBRARY_PATH to figure out where to find libraries (besides the -L
option), so that would be the place to add it for the link to work.
LD_LIBRARY_PATH is what is used at runtime.
--
Olivier
David Warde-Farley
On Mar 12, 10:50 am, James Bergstra <james.bergs...@gmail.com> wrote:
>
> I expect it to work for you if you add the /opt/sw/ATLAS to you
> LD_LIBRARY_PATH, because in that case it should take the -l options
> from numpy and compile correctly.
>
> If that fails, please email the list because it's a bug (well... it's
> basically already a bug that -L options are not allowed...). In that
> case I would also be curious what happens when you add that directory
> to LD_LIBRARY_PATH *and* add the small-l flags to blas.ldflags.
Sadly that does seem to be the case. I still get the same errors. Is
it a problem that I only have the static libraries?
dwf@mirage:~$ ls /opt/sw/ATLAS/lib
libatlas.a libcblas.a libf77blas.a liblapack.a libptcblas.a
libptf77blas.a
> Sorry there are still some wrinkles around the libpaths with blas...
> but your feedback would be appreciated.
No problem, I'm happy to help straighten them out if I can.
David
James Bergstra
> Hi James,
>
> On Mar 12, 10:50 am, James Bergstra <james.bergs...@gmail.com> wrote:
>>
>> I expect it to work for you if you add the /opt/sw/ATLAS to you
>> LD_LIBRARY_PATH, because in that case it should take the -l options
>> from numpy and compile correctly.
>>
>> If that fails, please email the list because it's a bug (well... it's
>> basically already a bug that -L options are not allowed...). In that
>> case I would also be curious what happens when you add that directory
>> to LD_LIBRARY_PATH *and* add the small-l flags to blas.ldflags.
>
> Sadly that does seem to be the case. I still get the same errors. Is
> it a problem that I only have the static libraries?
A-ha. I'm a little shaky on that sort of stuff, but I think that
might be a problem.
Theano tries to compile and load those [dynamic] modules. Is that in
any way compatible with static libs?
David Warde-Farley
On Mar 12, 11:29 am, Olivier Delalleau <olivier.delall...@gmail.com>
wrote:
Okay, so something is definitely different between using LIBRARY_PATH
and not using it, namely I just get 'E' in the nosetests output but it
doesn't spit out generated code like it does when I run it without
LIBRARY_PATH. Using LIBRARY_PATH I get errors like:
======================================================================
ERROR: test_size_changes
(theano.compile.tests.test_builders.T_OpFromGraph)
----------------------------------------------------------------------
...
...
ImportError: /home/dwf/.theano/compiledir_Linux-2.6.31-20-generic-
x86_64-with-Ubuntu-9.10-karmic-/tmpOvaDLu/
307958ac90fd17f9948dc4775cda0bcf.so: undefined symbol: ATL_dgemm
Without it,
I get
./usr/bin/ld: cannot find -latlas
collect2: ld returned 1 exit status
and the aforementioned code dump.
any ideas?
David
Frédéric Bastien
Fred
James Bergstra
did not compile (and link)
When you see an import error, it means that loading the [successfully
compiled] .so file failed.
In your case, I'm suspicious of the static libs not being available to
the dlopen'd module.
There may be workarounds like using LD_PRELOAD, but I'm totally guessing.
On Fri, Mar 12, 2010 at 2:22 PM, David Warde-Farley <d...@cs.toronto.edu> wrote:
>
>
David Warde-Farley
Yeah, it should be fine. The ATLAS routines should get linked in and
included in the object code of every dynamic library built against
them... I think.
I'll try recompiling ATLAS (I've been meaning to do that recently
anyway, to upgrade since we isolated a bug in ATLAS 3.9.17). I'll
build the dynamic versions too and see what I come up with.
David
James Bergstra
>
>
> On Mar 12, 2:19 pm, James Bergstra <james.bergs...@gmail.com> wrote:
>> On Fri, Mar 12, 2010 at 2:10 PM, David Warde-Farley <d...@cs.toronto.edu> wrote:
>
>> A-ha. I'm a little shaky on that sort of stuff, but I think that
>> might be a problem.
>>
>> Theano tries to compile and load those [dynamic] modules. Is that in
>> any way compatible with static libs?
>
> Yeah, it should be fine. The ATLAS routines should get linked in and
> included in the object code of every dynamic library built against
> them... I think.
Doesn't the static lib at least need to be compiled with PIC ?
David Warde-Farley
> Doesn't the static lib at least need to be compiled with PIC ?
Yep, my ATLAS is compiled with -fPIC however.
David
Olivier Delalleau
> Okay, so something is definitely different between using LIBRARY_PATH
> and not using it, namely I just get 'E' in the nosetests output but it
> doesn't spit out generated code like it does when I run it without
> LIBRARY_PATH. Using LIBRARY_PATH I get errors like:
>
> x86_64-with-Ubuntu-9.10-karmic-/tmpOvaDLu/
> 307958ac90fd17f9948dc4775cda0bcf.so: undefined symbol: ATL_dgemm
>
> Without it,
>
> I get
>
> ./usr/bin/ld: cannot find -latlas
> collect2: ld returned 1 exit status
So the first one is better because at least it found libatlas. But
there are undefined references which means you need to add some more -
lsomething on the command line. I'm not sure what you need but try to
add more libraries found in the ATLAS lib dir.
--
Olivier
David Warde-Farley
> o the first one is better because at least it found libatlas. But
> there are undefined references which means you need to add some more -
> lsomething on the command line. I'm not sure what you need but try to
> add more libraries found in the ATLAS lib dir.
No luck with any combination of -lptcblas, -lptf77blas, -lcblas, -
lf77blas... I think I'll just try recompiling ATLAS dynamically.
David
Olivier Delalleau
Good luck on that :) It turns out I just had a similar issue (not
Theano-related) and I gave up with ATLAS, now trying to get it to link
with MKL....
--
Olivier
David Warde-Farley
> In your case, I'm suspicious of the static libs not being available to
> the dlopen'd module.
For the record, building ATLAS with --dylibs solved it (combined with
your earlier suggestion of LIBRARY_PATH). Apparently theano doesn't
like linking against static ATLAS, for whatever reason. :)
Thanks,
David
James Bergstra
- print a warning at some point if some blas.ldflags token ends with .a ?
- add something to the documentation about static libs?
- do nothing and wait?
Yoshua Bengio
On 13-Mar-10, at 6:24 PM, James Bergstra wrote:
> any thoughts from anyone on how to improve theano with this
> information?
> - print a warning at some point if some blas.ldflags token ends
> with .a ?
> - add something to the documentation about static libs?
Both!
> - do nothing and wait?
No!
-- Yoshua
David Warde-Farley
> - print a warning at some point if some blas.ldflags token ends
> with .a ?
Only if the corresponding .so doesn't exist -- ATLAS will typically
build/include both unless you explicitly disable static libs.
David
James Bergstra
Yep. Only after I implemented this did I realize that when you say
-latlas, the token has no info about static vs. dynamic. I added a
note to installation docs, but that's it.
Olivier Delalleau
> any thoughts from anyone on how to improve theano with this information?
> - print a warning at some point if some blas.ldflags token ends with .a ?
> - add something to the documentation about static libs?
> - do nothing and wait?
Besides that, I think it'd be nice to have some test that ensure BLAS
is working properly. It seems like it is one major issue people are
facing when installing Theano (and it's typically one with PLearn
too ;)), because of the many different BLAS libraries floating around.
It would be cool if there was a test you could run which, on failure,
would hopefully give you some hints as to what may be not working
properly for you (this is wishful thinking since we are unlikely to
ever be able to cover all situations, but if we could get the most
common ones, that would be already quite helpful).
--
Olivier
James Bergstra
Brilliant. Not a nose-test, but a little diagnostic program with
mailing-list-friendly output... I like the idea, and I think we
should consider one for the GPU too.
Dumitru Erhan
Besides that, I think it'd be nice to have some test that ensure BLAS
is working properly. It seems like it is one major issue people are
facing when installing Theano (and it's typically one with PLearn
too ;)), because of the many different BLAS libraries floating around.
It would be cool if there was a test you could run which, on failure,
would hopefully give you some hints as to what may be not working
properly for you (this is wishful thinking since we are unlikely to
ever be able to cover all situations, but if we could get the most
common ones, that would be already quite helpful).
Would it be a good idea to point users to the numpy/scipy installation instructions? Good reasons:
(1) they have a pretty good configuration system that has been tested by many thousands of people before.
(2) theano takes its ldflags from numpy by default.
It's in the users' interest to have a properly configured numpy and once that is done (they have some diagnostic messages in the configuration), their theano BLAS configuration should be done as well.
Dumitru
--
http://dumitru.ca, +1-514-432-8435
Dumitru Erhan
Brilliant. Not a nose-test, but a little diagnostic program with
mailing-list-friendly output... I like the idea, and I think we
should consider one for the GPU too.
PS: Should we simply run whatever configuration tests numpy runs when it installs and make it mailing-list friendly?
Dumitru
--
http://dumitru.ca, +1-514-432-8435
Olivier Delalleau
> On Mon, Mar 15, 2010 at 11:30, James Bergstra <james.bergs...@gmail.com>wrote:
>
>
>
> > Brilliant. Not a nose-test, but a little diagnostic program with
> > mailing-list-friendly output... I like the idea, and I think we
> > should consider one for the GPU too.
>
> PS: Should we simply run whatever configuration tests numpy runs when it
> installs and make it mailing-list friendly?
I have little experience with numpy stuff, but yes, it sounds like a
good idea to me if it works well. I just remember, a rather long time
ago, trying to install numpy with BLAS and eventually giving up,
installing it without it. Could have been my fault though, been a
while ;)
--
Olivier
David Warde-Farley
> PS: Should we simply run whatever configuration tests numpy runs
> when it
> installs and make it mailing-list friendly?
The thing I usually ask people for on the NumPy/SciPy mailing list is
the output of numpy.show_config().
A theano.show_config() could spit out this plus theano specifics? :)
David