- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I use MFIX for work, in that if I use mkl , linking is (older mkl version) "-L $MKLROOT/lib/em64t -lmkl_lapack -lmkl_em64t -lmkl_core -lvml -lguide -lpthread". If I don't use MKL at all (just ifort) then ifort compiles blas.F and executables are created using link "blas90.a dgtsv90.a".
My problem is using latest mkl 10.3.6. I used link line advisor, and linked as " -L$MKLROOT/lib/intel64 -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread".
But results of using latest MKL are controry to not using mkl ( sticking to just latest ifort ) and allow ifort to compile blas.F and use "blas90.a dgtsv90.a" . Am I linking right or doing mistake? Older mkl link involves -lmkl_lapack while latest link don't have any lapack. Is it safe to use blas95 and lapack95 instead of Blas90 and lapack90? I was planning to use link involving blas95 and lapack95. In any case results should match with not using mkl (just ifort) any nearer.
Ifort compiler flags used are ' -c -I. -w -w95 -i_dynamic -ip -convert big_endian -assume byterecl -O3 -axW -ip -fp-model precise -ftz '. As '-i_dynamic' flag is used I tried dynamic linking. What mkl link line you recomend? I want to use MKL as it saves nearly 3-5 hours of executable run time. But results should be any nearer.
Additionally, terminal output of
1). uname -a ---------------------------Linux prashant-Vostro1510 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
2) $MKLROOT-----------------------------bash: /opt/intel/composer_xe_2011_sp1.6.233/mkl: Is a directory
I use MFIX for work, in that if I use mkl , linking is (older mkl version) "-L $MKLROOT/lib/em64t -lmkl_lapack -lmkl_em64t -lmkl_core -lvml -lguide -lpthread". If I don't use MKL at all (just ifort) then ifort compiles blas.F and executables are created using link "blas90.a dgtsv90.a".
My problem is using latest mkl 10.3.6. I used link line advisor, and linked as " -L$MKLROOT/lib/intel64 -Wl,--start-group -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -openmp -lpthread".
But results of using latest MKL are controry to not using mkl ( sticking to just latest ifort ) and allow ifort to compile blas.F and use "blas90.a dgtsv90.a" . Am I linking right or doing mistake? Older mkl link involves -lmkl_lapack while latest link don't have any lapack. Is it safe to use blas95 and lapack95 instead of Blas90 and lapack90? I was planning to use link involving blas95 and lapack95. In any case results should match with not using mkl (just ifort) any nearer.
Ifort compiler flags used are ' -c -I. -w -w95 -i_dynamic -ip -convert big_endian -assume byterecl -O3 -axW -ip -fp-model precise -ftz '. As '-i_dynamic' flag is used I tried dynamic linking. What mkl link line you recomend? I want to use MKL as it saves nearly 3-5 hours of executable run time. But results should be any nearer.
Additionally, terminal output of
1). uname -a ---------------------------Linux prashant-Vostro1510 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
2) $MKLROOT-----------------------------bash: /opt/intel/composer_xe_2011_sp1.6.233/mkl: Is a directory
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You do not say where you got blas.f and dgtsv.f, and one would question which versions of the BLAS and LAPACK these were taken from.If these were taken from older versions of BLAS and LAPACK, they might not be identical with the current versions. Secondly, compiling for X87 and SSE2 can give somewhat different results. Thirdly, bugs in your sources or improper calls to BLAS/LAPACK can cause results to be in apparent disagreement.
> But results of using latest MKL are controry to not using mkl
What definition of 'contrary' do you go by? Please spell out what the differences are.
It is not necessary to use the MKL link line advisor when you are making simple calls to MKL and call only a few routines. It is enough to use the -mkl compiler option, and the compiler will take care of linking against the proper libraries. Try this and if it does not work then you can use the Link Line Advisor.
Only if your code calls BLAS and LAPACK using the LAPACK95 interfaces does it make sense to link with the blas95 and lapack95 libraries. These libraries are used in addition to, and not instead of, the other MKL libraries.
> But results of using latest MKL are
It is not necessary to use the MKL link line advisor when you are making simple calls to MKL and call only a few routines. It is enough to use the -mkl compiler option, and the compiler will take care of linking against the proper libraries. Try this and if it does not work then you can use the Link Line Advisor.
Only if your code calls BLAS and LAPACK using the LAPACK95 interfaces does it make sense to link with the blas95 and lapack95 libraries. These libraries are used in addition to, and not instead of, the other MKL libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I used '-mkl' and it worked like charm. But run-time of executable produced is onother concern . I need to use proper compiler and optimization flags. This suit has alot ordinary differential equations and complex mathematics. i.e. alot floating point calculations. I have core 2 duo processor. Please suggest proper flags.
Compiler flags I mentioned earlier, were from the software suit, may be older somewhat. Do I need to change in it ?
Thanks alot.
I used '-mkl' and it worked like charm. But run-time of executable produced is onother concern . I need to use proper compiler and optimization flags. This suit has alot ordinary differential equations and complex mathematics. i.e. alot floating point calculations. I have core 2 duo processor. Please suggest proper flags.
Compiler flags I mentioned earlier, were from the software suit, may be older somewhat. Do I need to change in it ?
Thanks alot.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In place of -fp-model precise, the options -assume byterecl,protect_parens -prec-div -prec-sqrt will invoke observance of parentheses and IEEE divide and sqrt, without disabling other optimizations.
You would not require the -ax option if you are compiling for only a single machine. The option for the original Core 2 Duo is -xSSSE3 (obsolete spelling -xT), while the option for recent Core 2 Duo is -xSSE4.1. Setting -xHost asks the compiler to choose the one which matches your CPU. You will find cases where the default -mSSE2 (same as -xW) or -mSSE3 are better. You need -mSSE3 or later option for vectorization of complex math.
You would not require the -ax option if you are compiling for only a single machine. The option for the original Core 2 Duo is -xSSSE3 (obsolete spelling -xT), while the option for recent Core 2 Duo is -xSSE4.1. Setting -xHost asks the compiler to choose the one which matches your CPU. You will find cases where the default -mSSE2 (same as -xW) or -mSSE3 are better. You need -mSSE3 or later option for vectorization of complex math.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page