Hi,
Hi Bjoern,
Is there anything else we (the Galaxy community) can do to help sort out the ATLAS installation problems?
Thanks for asking. I have indeed a few things I would like some comments.
Another choice might be to use OpenBLAS instead of ATLAS, e.g. http://stackoverflow.com/questions/11443302/compiling-numpy-with-openblas-in...
I have no experience with it. Does it also need to turn off CPU throttling? I would assume so, or how is it optimizing itself?
However, I think we build NumPy without using ATLAS or any BLAS library. That seems like the most pragmatic solution in the short term - which I think is what Dan tried here: http://testtoolshed.g2.bx.psu.edu/view/blankenberg/package_numpy_1_7
I can remove them if that is the consensus. A few points: - fixing the atlas issue can speed up numpy, scipy, R considerably (by 400% in some cases) - as far as I understand that performance gain is due to optimizing itself on specific hardware, for atlas there is no way around to disable CPU throttling (How about OpenBlas?) - it seems to be complicated to deactivate CPU throttling on OS-X - binary installation does not make sense in that case, because ATLAS is self optimizing - Distribution shipped ATLAS packages are not really faster Current state: - Atlas tries two different commands to deactivate CPU throttling. Afaik that only works on some Ubuntu versions, where no root privileges are necessary. - If atlas fails for some reason, numpy/R/scipy installation should not be affected (that's was at least the aim) Questions: - Is it worth the hassle for some speed improvements? pip install numpy, would be so easy? - If we want to support ATLAS, any better idea to how to implement it? Any Tool Shed feature that can help? -> interactive installation? - can we flag a tool dependency as optional? So it can fail? - Can anyone help with testing and fixing it? Any opinions/comments? Bjoern
Thanks,
Peter