Impact Acquire SDK C
Applications using internal image processing algorithms use a lot of CPU time

Symptoms

When working with Impact Acquire versions greater than 2.40.0 it seems that a lot of CPU time is wasted for unknown reasons. When checking the current processes's threads it can be seen that a number of threads which equals to the number of CPUs in the system are running with very high CPU utilization. This is especially true when displaying images using ImpactControlCenter!

Cause

Since version 2.40.1 also the Linux version of Impact Acquire is compiled with OpenMP(https://en.wikipedia.org/wiki/OpenMP) support. However the way an OpenMP thread makes use of the CPUs processing power is implementation specific and therefore different results may be observed on different platforms. Most Linux distributions seem to use an OpenMP thread wait policy that is a mixture between active and passive when not specified otherwise. See the documentation of the libgomp library for details. Here it says:

If undefined, threads wait actively for a short time before waiting passively.

For more details read about the variable OMP_WAIT_POLICY in the OpenMP specification (e.g. here: https://www.openmp.org/).

Note
When set to active a CPU occupied by an OpenMP thread will try to actively wait for more work by spinning thus actively burning CPU time. This results in lower latency but in most cases encountered within an Impact Acquire application will simply degrade the system's performance!

Resolution

It is recommended that every OpenMP implementation honors certain environment variables that can be used to influence the behavior of the OpenMP runtime inside a process. Impact Acquire therefore will set

  • OMP_WAIT_POLICY to PASSIVE

when the first instance of a device manager gets initialized. This will (according to our observations) result in optimal performance when working with Impact Acquire! If this fails for any reason or is overwritten by anything else running in the same process at a bad moment the behavior described above might result from that!

Note
If for any reason setting the OMP_WAIT_POLICY to PASSIVE is NOT wanted and application can set the environment variable MVIMPACT_ACQUIRE_FAVOUR_SYSTEMS_OMP_WAIT_POLICY BEFORE initializing the mvDeviceManager library! ImpactControlCenter's OpenMP related behaviour can ONLY be influenced by setting environment variables BEFORE starting the application! The reason for that is the OpenMP runtime (libgomp) will evaluate the environment when loaded and since ImpactControlCenter is linked with libgomp setting the environment variable within ImpactControlCenter's code would be too late!