Setting KMP_AFFINITY in VS2010 IDE Fortran

[Don_Ritchie]

I'm running Visual Fortran Composer XE 2011 for Windows in Visual Studio 2010 IDE with Windows 7 64-bit on a machine with the Intel i7 860 Processor and programming in Fortran with OpenMP. My Fortran apps are mostly console applications for quantum chemistry and/or linear algebra problems using both MKL and home-grown subroutines.

Precisely how do I set KMP_AFFINITY? I've tried !DEC$ KMP_AFFINITY=.... in the source code, and a number of other things, none of which work.

Is it possible that I might get some performance improvements by playing around with these settings? I have already tried the OMP commands to set number of threads, etc., etc., and turning off hyperthreading in the BIOS.

[TimP]

Environment variables in Windows command shell are set by the SET command, or by Fortran library subroutines such as putenv. If, like a majority of Fortran applications, yours runs best with 1 thread per core, but you wish to leave Hyperthreading enabled, you can do e.g. SET KMP_AFFINITY=compact,1,1 (several equivalent options are presented) SET OMP_NUM_THREADS= MKL, when it creates its own threads, follows such a procedure by default. Rather than taking wild guesses about how KMP_AFFINITY works, checking the compiler documentation would be preferable. On a dual socket machine, KMP_AFFINITY settings are usually required for full performance.

[Don_Ritchie]

I must be doing something dumb. The following gives Error #5082, Syntax error .... on build. program Matrix_ops_test use lapack95 USE OMP_LIB use blas95 Integer N,info,lwork Character (len=1) ans,uplo,jobz logical flag real(kind=8), allocatable :: A(:,:),D(:),Acopy(:,:),temp(:,:),U(:,:) real(kind=8), allocatable :: E(:),Ucopy(:,:),Dcopy(:),Ecopy(:) ,tau(:) real*8 t1,t2,t3,t4,num,diff,CkUnitary,vl,vu,abstol SET KMP_AFFINITY=compact,1,1 ans="y"

[IanH]

As TimP says, KMP_AFFINITY is an environment variable, not a Fortran program variable. Environment variables are an operating system concept, frequently used for programs run from the command line (the SET command that Tim refers to is a command for the Windows command prompt). The most well known example is probably the PATH environment variable. From within Visual Studio, you can set the environment variables that will be used when that program is run from within Visual Studio by right clicking on the project for the executable and selecting properties, then under the Debugging category change the Environment property. For your example you would set that property to [plain]KMP_AFFINITY=compact,1,1[/plain]. If you are running your program from outside of Visual Studio then you will need to make other arrangements. Child processes inherit the environment variables of their parent process - hence if you are using a command prompt and use the SET command to set an environment variable, any programs subsequently started from that command prompt will pick that variable up. In recent versions of Windows environment variables can also be set for any new processes started system wide (perhaps for a particular user) using Control Panel > System > Advanced system settings.

[Don_Ritchie]

IanH: Thanks. Your information does help a little, but it looks like a "can't get there from here" situation for my case, described in detail at the start of my first post. Let me try two further questions: If I follow your suggestion in the 2nd paragraph of your post (setting properties>Debugging category ...) does the setting stick when I build and run the "release" version? If I create a .dll in Fortrtan, then use it in a C# Windows Form app, is there any way to set KMP_AFFINITY other than with 'control panel'?

[Les_Neilson]

Don Take a look at the SETENVQQ function in the help This can be called from a Fortran program/routine to set environment variables - if you are not too concerned about software portability. Les

[Don_Ritchie]

Les: Thanks; SETENVQQ sounds like what I was looking for. Using the 'help' snippet + linking with libifport.lib LOGICAL(4) success success=.false. success = SETENVQQ("KMP_AFFINITY=compact,1,1") if (success) Print *,"KMP success" looks o.k. Unfortunately, it makes no appreciable differences in performance for me. Nor does turning off hyperthreading in the BIOS, nor does using call omp_set_num_threads(4) or (8). I think I've pursued this as far as I want to. Thanks again to all for the replies.

[IanH]

I suspect (I don't know for sure) that the environment variable needs to be set prior to the program starting. If that's the case, then calling SETENVQQ from within the program itself isn't going to have any effect. Perhaps I'm wrong, and the environment variable just needs to be set before the first !$OMP parallel construct is encountered. To be complete... property changes made to a project within Visual Studio are more or less configuration specific (configurations being the labels like "Debug" and "Release"). That is - if you want to have that environment variable property setting apply to the Release configuration, then make the property change to the Release configuration. The configuration that you are editing by default when you show the properties for a project is the "Active" configuration that is selected in the solution configuration drop down in the toolbar at the top of the Visual Studio window (technically the selection of a particular solution configuration then sets a matching set of project configurations, but unless you've been modifying that mapping, they can be considered one and the same). You can override the configuration to be edited from within the properties dialog using the Configuration drop down that is within the dialog itself. In addition that drop down also offers convenience selections such as "All Configurations" - as it reads - when selected any changes that you make apply to all configurations that currently exist for the project. But as I said before, environment settings made in this manner only apply if the program is being started from within Visual Studio. If you start the program from elsewhere then you'd need to make the environment changes elsewhere.

[Don_Ritchie]

Ian: I think I understand the 'project properties' settings within Visual Studio IDE and how they relate to 'debug' and 'release'. What I DON'T understand is the function of the 'debugger' settings for a 'release' configuration. Anyway... I tried your suggestion of putting the KMP_AFFINITY in there. As with everything else I've tried related to this, there is no significant effect on performance. Thanks for your comments, though.

[IanH]

Ok... apologies for the misunderstanding. The environment settings are just as applicable (they are also applicable to "start without debugging" runs). Visual Studio follows the same process to launch an executable, regardless of whether it is a Debug build or Release build, differences are due to either the Visual Studio command used (Start with Debugging/Start without Debugging) or variation in properties between configurations.