Visual Studio 2017 support for MKL? Update 3 timeline?

[Oleg_S_1]

Hello,

Is it correct that the latest MKL Update 2 doesn't support MSVS 2017 yet? If so, is there any time estimate for when this might become available? Is it planned for an Update 3 or earlier/later or unknown at this point?

I think that many MKL users (companies), including myself, are holding the upgrade to VS2017 b/c of the MKL :)

Thanks, Oleg

[Jing_Xu]

We are working on the integration of MKL and MSVS 2017. In the future, MKL will support MSVS 2017.

[Mikhail_K_]

My guess is May

[Gennady_F_Intel]

Preliminary we are planning to add this into next version of MKL 2018 ( ERT ~ September this year). We will announce the MKL 2018 beta process within the next month.

[Oleg_S_1]

Thanks all for the prompt responses. Looking forward to the VS17 support!

Just to double-check one thing. I understand that there's no integration between MKL and Visual Studio 2017. Is it also true that the latest MKL libraries/dlls are not compatible with the latest Visual C++ in Visual Studio 2017 (toolset 141) - i.e. I cannot link MKL libraries manually as well - correct?

Thanks, Oleg

[Gennady_F_Intel]

>> I cannot link MKL libraries manually as well - correct? .  Oleg, You may explicitly declare the list of MKL's libraries you need to use and it will work from MVSC 2017 too. Please have a look at the KB Article describing how do this : https://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-compiling-and-linking-with-microsoft-visual-cc.  

pls let us know if any further problem.

[Oleg_S_1]

I managed to manually link MKL 2017 Update 2 to my existing code (which was retargeted to MSVC 141, run with Visual Studio 2017). All compiles and seem to run OK.

However, *some* MKL code that used to work for years (last updated MKL libs around the beginning of 2014) crashes and returns non-zero statuses.

One illustrative example is VSL Summary Statistics. Simple mean computation fails during the task creation (vsldSSNewTask) returning status -4001 (VSL_SS_ERROR_BAD_DIMEN). I've tried the code posted here to re-confirm the syntax and validity of arguments (https://software.intel.com/en-us/articles/overview-of-summary-statistics-ss-in-intel-mkl-v103?language=fr ) and it fails with -4001 as well.

Other crashes happen in cblas_ddot, cblas_dcopy, dgesdd, etc.. But, interestingly not all the calls to these functions (which work OK with earlier MKL version) error out, only some of them.

Before further investigation or the rollback to the old MKL, I thought I'd ask whether MKL libs in 2017 Update 2 are 1) backward compatible with previous MKL versions; and/or 2) compatible with MSVC 141? Any other thoughts or advice?

Thanks much,

Oleg 

[Gennady_F_Intel]

the answers are yes. Give us the case which we may compile and reproduce the failure on our side.

[Oleg_S_1]

Here're two small scenarios:

Setup:

• Visual Studio Enterprise 2017. Version 15.1 (26403.0) Release
• Platform toolset: Visual Studio 2017 (v141)
• MKL version: compilers_and_libraries_2017.2.187 / intel_x64_win
• Debug x64
• MKL libs linked: mkl_intel_ilp64.lib;mkl_intel_thread.lib;mkl_core.lib;libiomp5md.lib
• Using libiomp5md.dll from redist/ folder to load in run-time

Test Code:

#include "stdafx.h"

#include <iostream>
#include <vector>
#include <string>

#include "mkl.h"
#include "mkl_cblas.h"

void dcopyTest()
{
    int n = 3;
    std::vector<double> x(n, 1.0);
    std::vector<double> y(n);

    cblas_dcopy(n, x.data(), 1, y.data(), 1);
}


void meanTest()
{
    auto const N = 5;
    auto const DIM = 1;

    VSLSSTaskPtr task; /* SS task descriptor */
    double x = { 1.0, 2.0, 3.0, 4.0, 5.0 }; /* Array for dataset */
    double mean; /* Array for mean estimate */
    double* w = 0; /* Null pointer to array of weights, default weight equal to one will be used in the computation */
    MKL_INT p, n, xstorage;
    int status;

    /* Initialize variables used in the computation of mean */
    p = DIM;
    n = N;
    xstorage = VSL_SS_MATRIX_STORAGE_ROWS;
    mean = 0.0;

    /* Step 1 - Create task */
    status = vsldSSNewTask(&task, &p, &n, &xstorage, x, w, 0);
    std::cout << std::to_string(status) << std::endl; // !!!STATUS==-4001

    /* Step 2- Initialize task parameters */
    status = vsldSSEditTask(task, VSL_SS_ED_MEAN, &mean);

    /* Step 3 - Compute the mean estimate using SS one-pass method */
    status = vsldSSCompute(task, VSL_SS_MEAN, VSL_SS_METHOD_1PASS);

    /* Step 4 - deallocate task resources */
    status = vslSSDeleteTask(&task);
}

int main()
{
    //dcopyTest();
    meanTest();

    getchar();
    return 0;
}

//example from https://software.intel.com/en-us/articles/overview-of-summary-statistics-ss-in-intel-mkl-v103?language=fr

dcopyTest() throws "Access Violation..." Here's the call stack:

     mkl2017test.exe!mkl_blas_avx2_xdcopy()    Unknown
     mkl2017test.exe!mkl_blas_dcopy()    Unknown
     mkl2017test.exe!dcopy()    Unknown
     mkl2017test.exe!cblas_dcopy()    Unknown
>    mkl2017test.exe!dcopyTest() Line 17    C++
     mkl2017test.exe!main() Line 56    C++
     [External Code]    

meanTest() returns status=-4001 on  vsldSSNewTask and throws on the next line.

     mkl2017test.exe!mkl_vsl_sub_kernel_l9_vsldSSEditTask()    Unknown
>    mkl2017test.exe!meanTest() Line 42    C++
     mkl2017test.exe!main() Line 56    C++
     [External Code]    

Another observation: in Release x64, status==-4003 in meanTest()...

Please let me know if you need any additional information,

Thanks!

[Oleg_S_1]

Hm, I tried 32 bit and it worked OK. So I thought that the issue might be in the libs I link.. And it seems it was the problem indeed: linking against mkl_intel_ilp64.lib instead of mkl_intel_lp64.lib... Would you mind explaining why "i" version (which, as I understand, corresponds to a 64-bit integer interface layer) produce the issues above? Should I be defining MKL_ILP64​ in order to use 64-bit ints layer properly?

Sorry, I haven't discovered this before posting. Thanks for assistance!

[Oleg_S_1]

Sorry for multiple posts, but, unfortunately, I'm facing new problems. I'm getting massive memory leaks - which, after some reading, seem to be causing by dynamic link to libiomp.

Following the suggestions to use TBB for threading, I linked mkl_tbb_thread.lib and tbb.lib (removing libiomp and mkl_intel_thread). I get the following errors, indicating that mkl_tbb_thread is compiled for VS 2010?

Severity    Code    Description    Project    File    Line    Suppression State
Error    LNK2038    mismatch detected for '_MSC_VER': value '1600' doesn't match value '1900' in xxx.obj    xxx    xxx\mkl_tbb_thread.lib(vml_tbb_threading_templates.obj)    1    
Error    LNK2038    mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in xxx.obj    xxx    xxx\mkl_tbb_thread.lib(vml_tbb_threading_templates.obj)    1    

Even defining _ALLOW_MSC_VER_MISMATCH and _ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH didn't help.

Could you please advice with this? I'd greatly appreciate any help here.

Thanks

[Gennady_F_Intel]

mkl_intel_ilp64.lib -- please change by mkl_intel_lp64.lib

[Oleg_S_1]

Gennady - thanks, I resolved this issue ilp vs. lp in my earlier experiments. Unfortunately, it followed by other blocking problems, which I described above.

I don't have a strong preference for OMP vs. TBB, as I'm not very familiar with the differences. However, I see many mentions on the Web about MS stopping native support for it, the fact that you no longer ship static version, etc - and it makes me look towards TBB now. I'm sure when I learn the real differences between OMP and TBB, this desire will be even stronger.

All my libraries link to CRT statically (MT, MTd). I suppose that this might be related to the massive memory leaks when I use dynamic libiomp5md.lib and load its dll in the run-time. These leaks are untraceable - they just happen in random places and only in the routines that have MKL calls. I didn't have any of these leaks when linking libiomp5mt.lib statically with old MKL distribution. So I'm not sure if it's even possible and how to make dynamic OMP to work in my architecture.

Regarding TBB and this _MSC_VER mismatch. I've found a fairly recent thread about the exactly same problem - https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/629012. And it seems that it was fixed in 11.3 update 4. But, apparently, it's back - unless I miss something or doing something wrong.

So right now, I can't proceed and might have to revert to the old MKL libs due to the time pressure - which I really wouldn't like to avoid (plus some other future-looking reasons related to using DAAL and other libs.) So any advice would be greatly appreciated

Update: I hex-edited mkl_tbb_thread.lib and made it build. It runs now, but I'm getting the exactly same memory leaks.. It turned out that tbb lib is not static as well, which I assume again is the cause of all troubles. I know that making a shared DLL is a much better architecture and would probably resolve all the troubles, but, unfortunately, that's not an option at the moment given all the company's legacy code and libs. Do you know if anything can be done here or my only option is to go back to old MKL and static OMP?

Thanks

[Gennady_F_Intel]

Oleg,   

- In the case “….the massive memory leaks when I use dynamic libiomp5md.lib and load its dll in the run-time”   - Please try to call he mkl_disable_fast_mm() function after the last call of mkl’s functions!  See more details into MKL User’s Guide – “Avoiding mem leaks in Intel MKL).

- Regarding OpenMP and TBB-threading runtime:  1/ MKL supports TBB-Threading runtime but for not of all routines. in the case if you use ( as mentioned above ) summary statistic routines, then this functionality supports only OpenMP threading. See the list of TBB-threaded routines in RN or into this KB Article - https://software.intel.com/en-us/articles/using-intel-mkl-and-intel-tbb-in-the-same-application   

2/ OpenMP runtime will be faster in the case if you call only one application which linked with MKL at the same time on the same system. In the case if you make many independent calls of such applications at the same time on the same systems, then TBB threading layer will help to have better performance.

- Regarding statically linking with OpenMP runtime lib ( libiomp) – we don’t recommend to do this to prevent threading overhead problems which may causes performance and/or correctness problems.

-- Gennady

[Oleg_S_1]

Gennady, 

Thanks for your help! I was able to resolve most of the memory leaks when using TBB threading by calling mkl_free_buffers() after the last MKL calls. Will later try and see if this applies to OpenMP as well.

Thanks for the comments on TBB vs OpenMP - I'll study the materials, but from what you've said, it looks like OpenMP might better suit my particular application.

Oleg