Opened 11 years ago

Closed 11 years ago

#518 closed discussion (fixed)

choosing cblas - when and how?

Reported by: Peter Owned by: Jari Häkkinen
Priority: major Milestone: yat 0.6
Component: build Version: trunk
Keywords: Cc:

Description (last modified by Peter)

Daughter tickets: #522 #523 #524 #525

This is not an issue as long as user and installer of yat is the same person. That is typically the case, but I open this ticket anyway as a note so I can let myself forget the whole thing.

I noticed that blas is not mentioned in libgsl.la, nor is blas mentioned in libgsl.so AFAICS with ldd libgsl.so. After some digging I was found this thread http://lists.gnu.org/archive/html/bug-gsl/2009-01/msg00029.html where Brian Gough explains that the reason is to let the end-user decide which cblas to be linked into the application.

Perhaps we should join this strategy?

It would imply that we ignore blas when building the library and only mention it in the tests and in yat-config.

If that step is taken it means, it's up the user to choose which blas to use and if he is using yat-config (directly or via one of the ac macros) he can choose to use the one that the installer chose. A way to the user override the default value is to make yat-config honor an env variable YAT_CBLAS_LIB. This is how gsl does this kind of thing and, for example, we set GSL_CBLAS_LIB in yat's configure.ac to override the default libgslcblas.

To go the whole way in flexibility regarding blas, perhaps we should also allow the installer to choose blas. As now that is not possible, but the order of choice is hard-coded into configure.ac. Adding this would depend on related tickets #349 and #435.

Change History (14)

comment:1 in reply to:  description ; Changed 11 years ago by Jari Häkkinen

Replying to peter:

This is not an issue as long as user and installer of yat is the same person. That is typically the case, but I open this ticket anyway as a note so I can let myself forget the whole thing.

I noticed that blas is not mentioned in libgsl.la, nor is blas mentioned in libgsl.so AFAICS with ldd libgsl.so.

You should use the 'nm' command:

nm /usr/local/lib/libgsl.a | grep blas

After some digging I was found this thread http://lists.gnu.org/archive/html/bug-gsl/2009-01/msg00029.html where Brian Gough explains that the reason is to let the end-user decide which cblas to be linked into the application.

Yes, but GSL provides a blas implementation as a part of the GSL package. It is a pre-requisite for GSL, you cannot compile gsl without blas.

Perhaps we should join this strategy?

We could, the current strategy now is to look for another blas than gslcblas; look for a cblas library, if it work be happy if not, try adding atlas with the cblas found, if this work be happy if not fall back on gslcblas.

The thinking is that if you have a cblas independent of atlas it is probably optimized by someone for the hardware. The second best thing is atlas tuned blas, and "worst" case is to fall back on the gsl implementation.

Back in the good old days blas was not something that came out-of-the-box. It was expensive software. Atlas came around and now any decent linux distro and macs use atlas to create a tuned blas matching the hardware.

If we decide to go for user selectable blas, I think we should retain the search order above, and make it possible for a user of yat to overide this by setting their favourite blas.

It would imply that we ignore blas when building the library and only mention it in the tests and in yat-config.

My previous comment means that I do not agree with this. We cannot even run all tests without blas.

If that step is taken it means, it's up the user to choose which blas to use and if he is using yat-config (directly or via one of the ac macros) he can choose to use the one that the installer chose. A way to the user override the default value is to make yat-config honor an env variable YAT_CBLAS_LIB. This is how gsl does this kind of thing and, for example, we set GSL_CBLAS_LIB in yat's configure.ac to override the default libgslcblas.

Avoid polluting the environement. I haven't noticed the GSL_CBLAS_LIB line in configure.ac before, it was added to fix ticket:385 but I think the resolution used is not the one that should have been used. I would like to reopen the ticket and resolve it without the GSL variable. It is even exported and added to the user environment.

To go the whole way in flexibility regarding blas, perhaps we should also allow the installer to choose blas. As now that is not possible, but the order of choice is hard-coded into configure.ac. Adding this would depend on related tickets #349 and #435.

I think we can add flexibility regarding blas but it should be done without polluting the environment and with a default scheme to make the best guess. Remember, the first time you compile a package you do not want to much things to think about. Users who are concerned with blas speed will pick up extra configuration requirement later on and recompile as needed.

comment:2 in reply to:  1 ; Changed 11 years ago by Peter

Replying to jari:

Replying to peter:

This is not an issue as long as user and installer of yat is the same person. That is typically the case, but I open this ticket anyway as a note so I can let myself forget the whole thing.

I noticed that blas is not mentioned in libgsl.la, nor is blas mentioned in libgsl.so AFAICS with ldd libgsl.so.

You should use the 'nm' command:

nm /usr/local/lib/libgsl.a | grep blas

But I was not looking for symbols. I wanted to see if any specific cblas library was mentioned. It is not. Of course there are symbols but they are neutral.

After some digging I was found this thread http://lists.gnu.org/archive/html/bug-gsl/2009-01/msg00029.html where Brian Gough explains that the reason is to let the end-user decide which cblas to be linked into the application.

Yes, but GSL provides a blas implementation as a part of the GSL package. It is a pre-requisite for GSL, you cannot compile gsl without blas.

Sure.

Perhaps we should join this strategy?

We could, the current strategy now is to look for another blas than gslcblas; look for a cblas library, if it work be happy if not, try adding atlas with the cblas found, if this work be happy if not fall back on gslcblas.

The thinking is that if you have a cblas independent of atlas it is probably optimized by someone for the hardware. The second best thing is atlas tuned blas, and "worst" case is to fall back on the gsl implementation.

Back in the good old days blas was not something that came out-of-the-box. It was expensive software. Atlas came around and now any decent linux distro and macs use atlas to create a tuned blas matching the hardware.

If we decide to go for user selectable blas, I think we should retain the search order above, and make it possible for a user of yat to overide this by setting their favourite blas.

Agreed. That is exactly what I tried to say. It is more important to have a sensible default search than allow flexibility, but I think we can have both.

It would imply that we ignore blas when building the library and only mention it in the tests and in yat-config.

My previous comment means that I do not agree with this. We cannot even run all tests without blas.

But I did say that we should mention blas when linking in the tests. They would not link otherwise. What I tried to say was to keep a sensible search but allow it to be overridden by installer. Use the found blas when linking the tests and set the info in yat-config.

If that step is taken it means, it's up the user to choose which blas to use and if he is using yat-config (directly or via one of the ac macros) he can choose to use the one that the installer chose. A way to the user override the default value is to make yat-config honor an env variable YAT_CBLAS_LIB. This is how gsl does this kind of thing and, for example, we set GSL_CBLAS_LIB in yat's configure.ac to override the default libgslcblas.

Avoid polluting the environement. I haven't noticed the GSL_CBLAS_LIB line in configure.ac before, it was added to fix ticket:385 but I think the resolution used is not the one that should have been used. I would like to reopen the ticket and resolve it without the GSL variable. It is even exported and added to the user environment.

I'm happy if you can improve it; do not reintroduce the issue though. Perhaps the export is not needed?

To go the whole way in flexibility regarding blas, perhaps we should also allow the installer to choose blas. As now that is not possible, but the order of choice is hard-coded into configure.ac. Adding this would depend on related tickets #349 and #435.

I think we can add flexibility regarding blas but it should be done without polluting the environment and with a default scheme to make the best guess. Remember, the first time you compile a package you do not want to much things to think about. Users who are concerned with blas speed will pick up extra configuration requirement later on and recompile as needed.

Agreed. Most important is that it works for the never-built-yat-before user. It should be possible to come up with "green" alternatives. For our own configure.ac with could have a configure flag (that is how acx_blas does it (#349)). For the yat-config and the ac macros it sjould also be possible. In yat-config we could have a --lib-withouth-cblas in same manner as GSL. For the macros, I would prefer if we could avoid adding arguments to them. Perhaps we could let the them listen to a shell variable YAT_CBLAS_LIB. The difference with my previous suggestion is that the macro code must take of this case instead of just let yat-config take care of. Would that make be an OK approach?

comment:3 in reply to:  2 ; Changed 11 years ago by Jari Häkkinen

Replying to peter:

I noticed that blas is not mentioned in libgsl.la, nor is blas mentioned in libgsl.so AFAICS with ldd libgsl.so.

You should use the 'nm' command:

nm /usr/local/lib/libgsl.a | grep blas

But I was not looking for symbols. I wanted to see if any specific cblas library was mentioned. It is not. Of course there are symbols but they are neutral.

But what were you expecting to find? The blas stuff is in libgslcblas? The reason for this is of course to make replaceable.

But I did say that we should mention blas when linking in the tests. They would not link otherwise. What I tried to say was to keep a sensible search but allow it to be overridden by installer. Use the found blas when linking the tests and set the info in yat-config.

Ok, but I would like to see the blas linkage still after running configure ... this will show the observant user how they need to use blas.

I'm happy if you can improve it; do not reintroduce the issue though. Perhaps the export is not needed?

So, I have reopened #385 and added it to milestone:0.6

I think we can add flexibility regarding blas but it should be done without polluting the environment and with a default scheme to make the best guess. Remember, the first time you compile a package you do not want to much things to think about. Users who are concerned with blas speed will pick up extra configuration requirement later on and recompile as needed.

Agreed. Most important is that it works for the never-built-yat-before user. It should be possible to come up with "green" alternatives. For our own configure.ac with could have a configure flag (that is how acx_blas does it (#349)). For the yat-config and the ac macros it sjould also be possible. In yat-config we could have a --lib-withouth-cblas in same manner as GSL. For the macros, I would prefer if we could avoid adding arguments to them. Perhaps we could let the them listen to a shell variable YAT_CBLAS_LIB. The difference with my previous suggestion is that the macro code must take of this case instead of just let yat-config take care of. Would that make be an OK approach?

Doesn't --lib-without-cblas in GSL mean that no cblas support should be built, i.e., do not create libgslcblas. We are not building any blas. I think which blas to use should be settable at configure time and then maybe overriden by an environment vairable set by user. yat-config should say one of these:

  1. the best guess
  2. the blas provides when configure'ing yat and compiling
  3. override with user set environment variable

Highest priority for higher number. The last step of course assumes that the user uses yat-config to set flags but if not he is on his own anyway.

comment:4 in reply to:  3 ; Changed 11 years ago by Peter

Replying to jari:

But what were you expecting to find? The blas stuff is in libgslcblas? The reason for this is of course to make replaceable.

Well expected to see something similar to what I see when I do ldd libyat.so.

But I did say that we should mention blas when linking in the tests. They would not link otherwise. What I tried to say was to keep a sensible search but allow it to be overridden by installer. Use the found blas when linking the tests and set the info in yat-config.

Ok, but I would like to see the blas linkage still after running configure ... this will show the observant user how they need to use blas.

You will see it when you run make check. I just wanna remove it from the library. We can add a page in docs: How to link with yat.

Doesn't --lib-without-cblas in GSL mean that no cblas support should be built, i.e., do not create libgslcblas.

Sorry, I meant the option gsl-config --libs-without-cblas, which returns -lgsl -lm on my system.

We are not building any blas. I think which blas to use should be settable at configure time and then maybe overriden by an environment vairable set by user. yat-config should say one of these:

  1. the best guess
  2. the blas provides when configure'ing yat and compiling
  3. override with user set environment variable

Highest priority for higher number. The last step of course assumes that the user uses yat-config to set flags but if not he is on his own anyway.

Seems to be what I was thinking.

comment:5 in reply to:  4 ; Changed 11 years ago by Jari Häkkinen

Replying to peter:

You will see it when you run make check. I just wanna remove it from the library. We can add a page in docs: How to link with yat.

I am a little bit old fashioned and would like it to be in the end of configure as

configure: 
configure:  Ready to compile the yat library
configure:  The following flags and libraries will be used:
configure:  +++++++++++++++++++++++++++++++++++++++++++++++
configure:   CPPFLAGS=
configure:   AM_CPPFLAGS=-I$(top_srcdir)  -DHAVE_INLINE=1 -DYAT_DEBUG=1  -I/usr/local/include/boost-1_36
configure:   CXXFLAGS=
configure:   AM_CXXFLAGS= -Wall -pedantic -g -O 
configure:   LDFLAGS=
configure:   AM_LDFLAGS=  -L/opt/local/lib
configure:   LIBS=-lgsl -lcblas 
configure:  +++++++++++++++++++++++++++++++++++++++++++++++
configure: 
configure:  Now type 'make && make check'.

This will hint to me how to compile against yat without reading docs. LIBS could be replace with BLASLIB or something similar ... or add it to a document. I am not going to fight for this.

So, now I understand ... you don't like blas in

signori:yat> otool -L /usr/local/lib/libyat.1.0.2.dylib 
/usr/local/lib/libyat.1.0.2.dylib:
	/usr/local/lib/libyat.1.dylib (compatibility version 2.0.0, current version 2.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)
	/opt/local/lib/libgsl.0.dylib (compatibility version 13.0.0, current version 13.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 218.0.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

This means that we have to understand why the reference is added to yat but not gsl, both are dependent of blas. I think the resolution is that the blas flags we use in yat should only be visible in binary creating makefiles, i.e., in test, nowhere else. (Without examining it, it seems like libtool, or whoever does it, picks up the dependency when creating yat-libs ... also the gsl dependency should be removed). This does not exclude detection in configure.ac and optionally displaying the findings in the end of configure.

Sorry, I meant the option gsl-config --libs-without-cblas, which returns -lgsl -lm on my system.

So, you'd like to something similar in yat-config? This gives four conditions, the three from above and then a fourth, give no blas linkage at all if --libs-without-cblas is given. This 4th case should have precedence?

comment:6 in reply to:  5 ; Changed 11 years ago by Peter

Replying to jari:

This means that we have to understand why the reference is added to yat but not gsl, both are dependent of blas. I think the resolution is that the blas flags we use in yat should only be visible in binary creating makefiles, i.e., in test, nowhere else. (Without examining it, it seems like libtool, or whoever does it, picks up the dependency when creating yat-libs ... also the gsl dependency should be removed). This does not exclude detection in configure.ac and optionally displaying the findings in the end of configure.

The reference is added because in configure.ac we set LIBS to be something like -lgsl -lcblas -lm. This variable is used both when creating programs and libraries. Have a look in, e.g., yat/utility/Makefile.

A solution might be to use LDADD (for programs) and LIBADD for libraries instead.

Sorry, I meant the option gsl-config --libs-without-cblas, which returns -lgsl -lm on my system.

So, you'd like to something similar in yat-config? This gives four conditions, the three from above and then a fourth, give no blas linkage at all if --libs-without-cblas is given. This 4th case should have precedence?

If you agree with having yat-config honor a blas environment variable, I don't see the need for having a --libs-without-cblas.

comment:7 in reply to:  6 ; Changed 11 years ago by Jari Häkkinen

Replying to peter:

The reference is added because in configure.ac we set LIBS to be something like -lgsl -lcblas -lm. This variable is used both when creating programs and libraries. Have a look in, e.g., yat/utility/Makefile.

A solution might be to use LDADD (for programs) and LIBADD for libraries instead.

Why is LIBS used in yat library creation? There is no need for LIBS in the yat/yat tree, only yat/test needs it. Libraries only need header files.

If you agree with having yat-config honor a blas environment variable, I don't see the need for having a --libs-without-cblas.

Well, I thought that one would like to do something like

LIBS = yat-config --libs-without-cblas -lmyblas

in a make file, i.e., no environment. I'd like a way of not using environment variables. If I want to accomplish the above effect I have to set an empty environment variable ... of course it could also be set to -lmyblas i suppose.

Do you feel strongly against supporting both?

comment:8 in reply to:  7 Changed 11 years ago by Peter

Replying to jari:

Why is LIBS used in yat library creation? There is no need for LIBS in the yat/yat tree, only yat/test needs it. Libraries only need header files.

Well that is how Automake creates the make rules and there is likely a good reason for that behavior. We could, of course, avoid setting LIBS if we so desire.

Do you feel strongly against supporting both?

No.

comment:9 Changed 11 years ago by Peter

(In [1892]) Removed dependency to cblas in libyat. There are three new make variables: YAT_LIBS, YAT_LIBS_WITHOUT_CLAS and YAT_CBLAS_LIB.

  • The variable YAT_LIBS is created as follows: First the LIBS provided

by user is saved (most often empty). Then when detecting libs, they are added to the variable LIBS and in the end of the configure run YAT_LIBS is created as the difference between LIBS and the original LIBS.

  • YAT_CLAS_LIB is detected as before.
  • YAT_LIBS_WITHOUT_CLAS is copied from YAT_LIBS but ignoring YAT_CLAS_LIB

I also changed the name of some variables to make the code clearer (I hope). The prefix INTERNAL_ is used for flags that should only be used when building yat and not needed for a user building against yat. Flags that should be propagated have no prefix, for example, CPPFLAGS.

In the end of configure these flags are used to create YAT_CPPFLAGS using the same mechanism as when creating YAT_LIBS.

In the last step variables such as AM_CPPFLAGS is created as the 'union' of YAT_CPPFLAGS and INTERNAL_CPPFLAGS and these are propagated to the Makefiles where they are used by Automake generated rules.

refs #518

comment:10 Changed 11 years ago by Peter

Description: modified (diff)
Milestone: yat 0.x+yat 0.6
Priority: trivialmajor

With r1892 and tickets #522 #523 #524 and #525, I think everything mentioned in this discussion will be fixed. So when those tickets are fixed I think we can close this one.

comment:11 Changed 11 years ago by Peter

(In [1914]) Using ACX_BLAS macro for blas detection. The behavior will likely be a bit different from before. The major difference is that there are no -m64 flags in the atlas tests, which implies you might need to add -m64 to LDFLAGS (and possibly CXXFLAGS) at configure time. It also implies that you might detect atlas on your 32bit machine, which previously was not possible. fixes #349

There is a new configure option: '--with-blas' that can be used to specify which blas should be used. fixes #524

refs #518

comment:12 Changed 11 years ago by Peter

On my Mac I get

 LIBS=-lcblas 
 YAT_LIBS=-lgsl -lcblas 

which must be wrong. Why would lcblas be in both LIBS and YAT_LIBS?

comment:13 Changed 11 years ago by Peter

(In [2009]) avoid polluting LIBS variable (with -lcblas) refs #518

comment:14 Changed 11 years ago by Peter

Resolution: fixed
Status: newclosed

(In [2021]) fixes #525 and #518

Added a variable YAT_LT_ADD in YAT_CHECK_LIB. Made YAT_LA_FILE also work with old (0.5) yat-config.

fixed a bug in _YAT_ACTION so $3 is executed and not $2 when appropriate.

Note: See TracTickets for help on using tickets.