KMP_AFFINITY=none

[tfield98]

Referring to:http://software.intel.com/en-us/articles/bogus-openmp-kmp_affinity-warnings-on-non-intel-processor-hosts

Is the only impact of setting KMP_AFFINITY=none that it disables any explcit binding by a developer of OpenMP threads to physical processing units?

Can I safely set this without affecting IPP functionaly other than this binding or does this environment variable affect other internal IPP processing?

Thanks.

[Thomas_Jensen1]

I cannot directly answer your question. However, I can say that KMP_AFFINITY=none does not take away the bogus warning (Windows Command Prompt window with warnings) on non-Genuine Intel processors, but KMP_AFFINITY=disabled does (Since IPP Composer 7 Update 7).

In short, this is what all developers of IPP code must do, if OpenMP is used and if the bogus warning (Windows Command Prompt window with warnings) must be supressed:

1. Determine if CPU = Genuine Intel processor.
2. If not so, set KMP_AFFINITY=disabled in the global or local environment.
3. If so, implement Intel processor multiple core optimal threaded performance tuning by setting KMP_AFFINITY to appropiate values (global or local environment).

It appears to me that this cannot be implemented with IPP code. To determine if CPU = Genuine Intel processor, you can use support functions in IPP, but you cannot use IPP without first having set KMP_AFFINITY (chicken and egg problem?).

In my case, I cannot implement it since I have put IPP code in a custom dll, and I cannot load this dll to use cpu support functions without triggering the bogus warning (Windows Command Prompt window with warnings) on non-Genuine Intel processors. Thus, I'm forced to disable KMP_AFFINITY on all processors, possible lowering the highest possible performance for Genuine Intel processors.

Intel, please fix this issue soon.

[tfield98]

Thanks, Thomas, for the reply. Actually, KMP_AFFINITY=none has worked on the AMD machines on which I tried it.

And, since we're not using OpenMP, we set =none on all machines.

If you can find some way to detect the chip type at the time your software is installed, the rest is straight-forward:

An environment variable like KMP_AFFINITY is just a registry value here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

It can be set programatically like any registry variable. But changes here don't take effect until after a reboot, or you do a SendMessage (with Timeout if you wish) of WM_SETTINGCHANGE.

Because this is HKEY_LOCAL_MACHINE, to avoid UAC hassles (as well as your chick-egg problem) have your installer set the key. Most installers will allow you to set the key as well as do theWM_SETTINGCHANGE. (Inno for example, does thethe broadcast using ChangesEnvironment directive: link.)

The WM_SETTINGSCHANGE isn't mandatory if you don't mind your users having to reboot.

To detect the processor type, maybe you could examine the registry key PROCESSOR_IDENTIFIER in the same registry location. Perhaps if the registry data: link or linkare a good starting place.

Maybe you end up writing a custom dll for your installer that sets =disable in the registry and then does the WM_SETTINGSCHANGE (don't use the timeout broadcast - you want to be sure it's done before the next step). Then, you can safely call the IPP support routine to determine the processor type. If it's an Intel chip, delete the registry entry and broadcast again.)

I haven't spent much time on this, so my ignorance may be showing, but I don't think you're as stuck as you say.

Let me know if you have other questions about this.

But I agree with you:

Intel, please fix this issue soon. It's a shameful bug that never should have gotton out the door. I wasted a day on this totally avoidable problem.

[SergeyKostrov]

Quoting tfield98

...An environment variable like KMP_AFFINITY is just a registry value here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

It can be set programatically like any registry variable. But changes here don't take effect until after a reboot...

Please take a look at another very simple way to set some environment variable programmatically. That was discussed
about two days ago. A link to a thread is:

http://software.intel.com/en-us/forums/showthread.php?t=105209&o=a&s=lr

and a Post #2 has an example.

What I can see that the 'KMP_AFFINITY problem' is hot and many developersare havingproblems.

Best regards,
Sergey

[Thomas_Jensen1]

Sergey, your contribution totally disregards my text.
Programatically setting a value in the Windows Environment is not an issue for me; I know well how to do that.

If you reread my text, please take a note of what I call my chicken and egg problem.
Or, must I repeat my text here?

If I haven't expressed my problem clearly, please indicate that fact.

[tfield98]

Thomas,

Yes, I'd like to hear Sergy's response, too.

But, to summarize my writeup because I got a little long-winded:

1. Set the KMP_AFFINITY=disabled during installation. (Because there's some talk that "none" doesn't work in newer builds)

2. Start your application or (a small dll in your installer)

3. Detect the processor type using IPP

4. If Intel chip, delete the KMP_AFFINITY key. The next time your app starts, it will use the Intel capabilities.

Inelegant? Very much so. Should it work? Yes, IMO.

Or, figure out how to do step 3 without IPP.

Anyway, hopefully Intel will fix this bug. (Although I a developer using a 3rd party library that uses IPP, so even if Intel fixes this in IPP, I've got to wait for my developer to release another version of his library...

[TimP]

If you use dynamic link for the OpenMP library, the entire KMP_AFFINITY thing will be updated simply by updating your .so. It would be a bad idea to have OpenMP linked statically into a library, as it could conflict with any OpenMP usage outside that library.
KMP_AFFINITY=none is intended to leave control of thread placement up to the OS kernel facilities, so you can use taskset et al. (if on linux) or let the kernel scheduler look for open resources. One of the reasons for "none" is to allow multiple application instances to run together without KMP_AFFINITY causing them to contend for specific cores (if you didn't take care to set complementary allocations for each job).

[tfield98]

TomP:

I'm a Windows developer using a graphics library that is bundled with IPP, so I have no idea what OpenMP is or what .so is. My library vendor wasn't sure whether KMP_AFFINITY=none would degrade performance on an Intel machine. Is there a simple description of the functionality that get disabled by "none" that I can him if he's using?

[Ying_H_Intel]

Add some information tothe threads,

1) foralmost all of IPP user, itdoesn't need to setthe KMP_AFFINITY for no-intel processors.

2) for who have seen the warning ( for example,you haveexplicitly call ippAffinity function in your code), please set environment variable KMP_AFFINITY= 'disable'

3) Regarding None vs. Disable.
Thomas is correct.I heard from Patrick, hehave confirmedthat none does not suppress warnings 71 & 72, only disabled does. So use KMP_AFFINITY= 'disable' if you run into the warning.

Thanks
Ying