MAGMA_ILP64
Posted: Sun May 15, 2016 7:44 am
Hi, I am (trying) building magma 2.0, my environment is Cuda 7.5, VS2013, Intel16 for MKL and Fortran, your CMAKE files. Having done this before, the build process has gone reasonably smoothly, with minimal changes. Because I start everything in the cmd window provided by intel that sets all the paths CMAKE goes very smoothly. The link line it suggests is the lp64 version of MKL.
My goal is to integrate magma with heavy number crunching code that uses the gesvd etc. and currently calls the versions implemented in the ILP64 part of MKL so I need to build both versions. Looking carefully, I think I need to do two things
1) change the link line suggested in the configured Cmake GUI to include the ilp library instead of the lp library and paste it back into the GUI.
2) set MKL_ILP64 and MAGMA_ILP64 which I do by adding add_definitions( -DMKL_ILP64 ) and add_definitions( -DMAGMA_ILP64 ) as the second and third lines of the CMakeLists.txt file
The sln seems to have taken everything on board. I run it from inside the same intel command shell I used when I ran CMake. All builds and runs.
However, there are huge numbers of warnings of 64->32 bit conversions from magma_int_t to int etc. produced by the compiler. Are these safe? Can I safely ignore them. I am assuming that I cannot ignore them and that on big jobs I will see a crash or bad data - but in this case what does one do? Is there another setting that I need to get right?
I refuse to tolerate these warnings in any code I write and wrap any such conversions (which are sometimes forced by external api's) with SafeInt<> to keep code robust and inform if there are overflow issues.
The magma code is a great idea. Thanks!
Terry
PS I said I would upload the version of run_tests.py that works in windows. I am sorry that I have not done this. I would just say one needs three things
1) run it from inside that same INTEL command line 2013 x64 environment mentioned above
2) edit run_tests.py, and in the (near the end) subroutine run that tests for the existence of the programme - add a + ".exe" after the name before the code tests for it. The current test fails to find the files because of this.
3) run_tests.py should be executed from the folder with the test executables in it.
The tests then run for me.
Terry
My goal is to integrate magma with heavy number crunching code that uses the gesvd etc. and currently calls the versions implemented in the ILP64 part of MKL so I need to build both versions. Looking carefully, I think I need to do two things
1) change the link line suggested in the configured Cmake GUI to include the ilp library instead of the lp library and paste it back into the GUI.
2) set MKL_ILP64 and MAGMA_ILP64 which I do by adding add_definitions( -DMKL_ILP64 ) and add_definitions( -DMAGMA_ILP64 ) as the second and third lines of the CMakeLists.txt file
The sln seems to have taken everything on board. I run it from inside the same intel command shell I used when I ran CMake. All builds and runs.
However, there are huge numbers of warnings of 64->32 bit conversions from magma_int_t to int etc. produced by the compiler. Are these safe? Can I safely ignore them. I am assuming that I cannot ignore them and that on big jobs I will see a crash or bad data - but in this case what does one do? Is there another setting that I need to get right?
I refuse to tolerate these warnings in any code I write and wrap any such conversions (which are sometimes forced by external api's) with SafeInt<> to keep code robust and inform if there are overflow issues.
The magma code is a great idea. Thanks!
Terry
PS I said I would upload the version of run_tests.py that works in windows. I am sorry that I have not done this. I would just say one needs three things
1) run it from inside that same INTEL command line 2013 x64 environment mentioned above
2) edit run_tests.py, and in the (near the end) subroutine run that tests for the existence of the programme - add a + ".exe" after the name before the code tests for it. The current test fails to find the files because of this.
3) run_tests.py should be executed from the folder with the test executables in it.
The tests then run for me.
Terry