[GenABEL-dev] ACML and make check

[L.C. Karssen]

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
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-------------- 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/e059f455/attachment.sig>