OpenMP, используемый компилятором Intel, поддерживает переменную окружения KMP_BLOCKTIME (docs), которая, как я полагаю, контролирует время ожидания ожидания (спин-блокировки), которое потоки будут тратить на ожидание новой работы (связанный документ утверждает, что это значение по умолчанию составляет 200 мс).Как можно контролировать время отпирания Microsoft OpenMP?
OpenMP, используемый компилятором Gnu, поддерживает переменную окружения GOMP_SPINCOUNT (docs), которая, как я считаю, также контролирует эквивалентную реализацию реализации библиотеки (хотя, по-видимому, она выражается как счетчик итераций, а не время).
Мой вопрос: Какой контроль (ы) (если есть) Microsoft предоставляет для управления этим параметром в OpenMP, используемом компилятором Microsoft? (Это меня интересует в настоящее время.)
(Мне хорошо известно, что если бы параллелизм моей программы был полностью основан на OpenMP, было бы мало поводов для беспокойства по этому поводу, но мой интерес вызван некоторыми vtune-следами от большая сложная система, которая также делает значительное использование TBB.)
Не выглядит хорошо, т.е. нет решения для VS: [см. это сообщение SO] (http://stackoverflow.com/questions/4738045/openmp-huge-performance-differences-between-visual-c- 2008-и-2010) и [эта социальная почта MSDN] (http://social.msdn.microsoft.com/Forums/ja-JP/528479c8-fb70-4b05-83ce-7a552fd49895/performance-problem-using-openmp- с-visual-c-2010? forum = parallelcppnative), указывающий как таковой. –
Спасибо за ссылки; «не исправишь» от MS - ой! Рад видеть, что это не только я. Я действительно добился успеха в контроле OMP ожидания Gnu, используя более стандартную OMP_WAIT_POLICY, но независимо от версии OpenMP, входящей в нее, MS не поддерживает ее http://msdn.microsoft.com/en-us/library/6sfk977f%28v= vs.100% 29 (или в 2012/2013). – timday
'OMP_WAIT_POLICY' был добавлен в OpenMP 3.0. Реализация Microsoft OpenMP 2.0, даже с последним и самым большим компилятором MSVC. –