[GenABEL-dev] ACML and make check

[L.C. Karssen]

On 25-07-14 16:15, Frank, Alvaro Jesus wrote:
> I do not recommend using distributed libraries. Use self compiled libraries. It will not fail if done so. Yours may compile, but no one guarantees that OPENMP=1 was used in the compilation for it.
> 
> All errors pointed out were not present in series of 3 different environments. 3 machines, 3 libraries each. All different architectures. I corrected configure.ac anyway. The LAPACKE_sposv_work are from -static linking with unsuitable libraries. Therefore self-compilation. 
> 
> We could, just like with normal omicabel, supply static precompiled versions, with both AMD and a proper OpenBLAS OPENMP=1, DYNAMIC_ARCH=0, etc. Committed the changes anyway. There is no more static linking and the user is responsible for having the libraries available at run-time with sudo rights. 
> 
> I don't have an environment where this commit fails.

OK, thanks, I'll try that.

> 
> P.S: I still need to compile the test without having to abort it manually. Screen output in real time is still a requirement for me.

You could treat test_omicablenomm as a regular binary (at least for now)
instead of a test file, so it would get compile just like omicablenomm.


Lennart


> 
> -A Frank
> ________________________________________
> From: L.C. Karssen [lennart at karssen.org]
> Sent: Friday, July 25, 2014 3:59 PM
> To: Frank, Alvaro Jesus; genabel-devel at lists.r-forge.r-project.org
> Subject: Re: ACML and make check
> 
> Hi Alvaro,
> 
> On 25-07-14 13:00, Frank, Alvaro Jesus wrote:
>> Hi Lennart,
>>
>> I committed an ugly/nice hack to allow the usage of AMD's ACML library
>> with omicabelnomm. This was required due to the program having VERY bad
>> performance issues making it unusable on old Opteron systems prior to
>> the 6200 versions. This are all that have non AVX instructions. I might
>> have broken a few Jenkins warnings due to this, but those will be fixed
>> later.
>> Normal OMICABEL should be tested against ACML this too. Using MKL on the
>> Opteron System, with 10 traits and 400000 snps. the runtime takes over
>> 10 hours. This does not seem like a normal behavior.
>>
>> AMD ACMl also allows to use GPU without ANY change, the system just
>> needs to support OpenCL, which NVIDIA and AMD do. I have no access to an
>> Opteron/AMD system that has GPU so I cant test it yet.
> 
> That's cool! Unfortunately I don't have access to an AMD GPU either :-(.
> 
>>
>> The changes also allow for static linking now. So no need to have root
>> access. The howtocompile file reflects this now.
>>
>> I also have a very improtant request. Your change of make check will not
>> display the output of the testing program as it runs. I previosly
>> compiled the test file and manually called it, giving me a very quick
>> workflow to test the system. But now my 1 cmd do it all workflow is
>> broken, having to use make check to compile test.cpp and then having to
>> abort it manually to later re-call it manually to be able to see the
>> output in real time. Is there a way to change make check to allow for
>> real time output? I tried gooooogoling this, but failed with the most
>> common solutions.
>>
> 
> The default way of running tests has changed in a recent automake
> update. It now allows tests to be run in parallel (assuming more than
> one exists). That's why the screen output isn't printed to screen anymore.
> 
> The actual screen output of the test can be found in the file
> tests/test_omicabelnomm.log. So you can check that after the 'make
> check' run.
> 
> Of course, nothing prevents you from running 'tests/test_omicablenomm'
> after you've run './configure' followed by 'make'. 'make check' makes
> sense only if the exit status of the tests returns 0 or 1 for success or
> failure, respectively.
> 
>> A rewrite of Algorithm.cpp is coming next. it will break the
>> validity/give wrong results perhaps at first.
> 
> Actually, the current HEAD already gives me compile errors:
> 
> ++ -static -O3 -I../libs/include/ -I./libs/include/ -fopenmp
> -D_openblas_   -L./libs/lib/ -L../libs/lib/ -o omicabelnomm
> src/AIOwrapper.o src/Algorithm.o src/Utility.o src/main.o  -llapacke
> -lopenblas -lgfortran
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sgels_work.o):
> In function `LAPACKE_sgels_work':
> (.text+0x1a3): undefined reference to `sgels_'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sgels_work.o):
> In function `LAPACKE_sgels_work':
> (.text+0x28c): undefined reference to `sgels_'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sposv_work.o):
> In function `LAPACKE_sposv_work':
> (.text+0x151): undefined reference to `sposv_'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sposv_work.o):
> In function `LAPACKE_sposv_work':
> (.text+0x240): undefined reference to `sposv_'
> collect2: error: ld returned 1 exit status
> make: *** [omicabelnomm] Error 1
> 
> 
> Did your commit change anything in the lapack requirements?
> 
> 
> Thanks,
> 
> Lennart.
> 
> 
> 
>>
>> Thank You.
>>
>> Alvaro Frank
> 
> --
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> L.C. Karssen
> Utrecht
> The Netherlands
> 
> lennart at karssen.org
> http://blog.karssen.org
> GPG key ID: A88F554A
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> 

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20140725/ca0d6ff3/attachment-0001.sig>