Re:VTUNE not inheriting MS VS IDE Release Mode

jimdempseyatthecove · ‎01-03-2021

Windows 10 Pro, Intel Parallel Studio 2020.4, MS VS 2019

When launching MS VS via Icon
Building Release build app with MKL threaded
Start Without Debugging

Program runs (finds mkl_intel_thread.dll)

Then when attempting to VTune without changing anything in MS VS

Program fails (unable to find mkl_intel_thread.dll)

The work around:

Launch Intel Parallel Studio intel64 cmd prompt

devenv mySolution.sln

It would be nice if VTune would inherit the environment as does the debug/run does.

Jim Dempsey

RaeesaM_Intel · ‎01-03-2021

Hi Jim,

Thank you for the suggestion.

Could you please share the application and steps to reproduce so that we can inform the engineering team regarding this issue .

Raeesa

jimdempseyatthecove · ‎01-04-2021

Attached is a .zip file of a "cleaned" development folder "TestHEEVRK VTune Issue". Inside:

"MS VS 2019 Help About.txt" (the Help | About of MS VS 2019)
Non_Intel_Environment.txt (the default Environment variables)

TestHEEVRK.sln (the solution file you should open using MS VS 2019)

*** Note, this system had clean install of Intel Parallel Studio XE 2020u4 Cluster Edition
*** I did not separately install any of the Intel Redistributables ***

     OMP_PLACES={0:64}
     KMP_AFFINITY=
     KMP_HW_SYBSET=
     The above are settings for my KNL system 4 Processor Groups, each with 64 hardware threads.
      **** change OMP_PLACES to {0:nn} where nn is the number of logical processors in the 1st(only)
      processor group on your system
Right-Click on Project TestHEEVRK | Project Only | Build
Assure TestHEEVRK is startup project (it was on last use)
Click VTune button
Take Sample (software) using configuration as sent

On my system this errors with mkl_intel_thread.dll missing when the program reaches the point of calling MKL.

Note, if after Release build if you click on Debug | Start Without Debugging the program locates the .dll.

I suspect VTune is not applying the additional PATH environment of the IDE. It does assume the command line arguments and current directory.

I suspect that if one were to install the Intel Redistributals seperately, That then the mkl_intel_thread.dll would be in PATH *** but not necessarily the version as used under development ****

Jim Dempsey

------------------------------------------------------------------

Side note not related to issue:

This is a benchmark program/suite for use on Windows intended to run permutations of OpenMP together with MKL. The project is not complete (not all features are in).

Attached also is an unfinished Word document containing additional information about the benchmark.

The intended "Quick Use" info

Unzip into a test folder.
Launch Intel Parallel Studio x64 Command Prompt Environment
CD to test installation folder

BuildAll
RunTest

The BuildAll is run once per system.
The RunTest has command line options to select the tests performed. Default is all tests.
All tests on KNL 7210 takes about 5 hours and 30 minutes. Default tests NUMA nodes, Sockets, L2s, cores, HTs using augmented OMP_PLACES or KMP_AFFINITY.

The VTune run (when working) runs 1 step of the permutations run by RunTest.bat

Jim Dempsey

Daria_R_Intel · ‎01-18-2021

Hi Jim,

Thanks for the reported issue.

I managed to build the "TestHEEVRK" solution. It appeared that VTune Visual Studio Integration doesn't take Environment variables from the project settings. (I mean this env variables: " OMP_PLACES={0:64}...".) The fix for the issue is created and will be added to the future VTune releases.

Could you please add info about what type of analysis do you run in VTune VS integration?

Could you please add info about where the error with missing mkl_intel_thread.dll appears? I cannot observe it. But I do observe that under VTune (Hotspots analysis type) the TestHEEVRK workload finishes execution early. This results in empty VTune result. This issue is under investigation now.

As an addition may be you can add the VTune result here on which the issue with mkl_intel_thread.dll is reproduced?

Daria_R_Intel · ‎01-22-2021

Hi Jim,

I've investigated deeply the issue with missing with mkl_intel_thread.dll. Fortran Visual Studio integration extension sets runtime environment variable to MKL libraries. There is no way for VTune VS extension to retrieve the environment. The workaround is to set environment to MKL libraries manually in VTune Configure Analysis tab:

The fix for retrieving environment from project settings will be included in future VTune release. So ways of workaround will be available.

There may be more information about the issue from Parallel Studio team (you may forward the issue to the corresponding community section).

RaeesaM_Intel · ‎01-05-2021

Hi,

Thank you for sharing necessary files and details. We will inform the concerned team and work on this .

Regards,

Raeesa

RaeesaM_Intel · ‎01-08-2021

Hi,

We are forwarding this case to the engineering team .

Raeesa

jimdempseyatthecove · ‎01-08-2021

There is a related thread here.

In that thread, there is an attache stripped down reproducer. CAF_MKL_ISSUE

This illustrates an MKL pinning issue when using a "vanilla" flavored configuration.

On my system (64 cores, 256 threads) on Windows, the sample test program has no MKL issues when using 1 to 4 images. When using more images, MKL reports a warning about being unable to pin some of its OpenMP threads.

I suspect that this will not show up on systems with one ProcessorGroup.
IOW test on system with more than one ProcessorGroup.

Jim Dempsey

Johny_P_Intel · ‎05-07-2021

Jim,

This issue has been fixed in the latest release of VTune Profiler (version 2021.3.0)

If you do not want to upgrade to the latest version, you can use the workaround by setting the env variables manually in the Configure Analysis tab in VTune.

Hope this resolved your issues.

Regards,

Johny

Johny_P_Intel · ‎05-11-2021

As we did not hear from you, we assume that this issue has been resolved and we will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only