2015-02-02 2 views
0

Я пытаюсь использовать OpenMP для получения некоторой производительности для обработки звука в реальном времени. Я взял алгоритм вида:OpenMP «для» в обработке звука в реальном времени

preparation 
for (int I=0; I<1024; I++) 
    something quite demanding 
finalization 

Когда не распараллеливание, она занимает около 3% от CPU по счетчику системы. Теперь, если я распараллеливал основной цикл, OMP использовал 8 потоков (4 ядра i7 с гиперпотоком), потребление основного потока снизилось до 2%, поэтому ответ был на 33% быстрее, но счетчик производительности системы начал показывать 100% (! !) общая реакция системы, все ядра полностью загружены.

Это похоже на то, что потоки делали много «ничего не принимающего CPU» даже во время ожидания следующего запроса аудиоданных. Любые идеи, что это может быть? Тот факт, что ответ был на 33% быстрее, хорош, но, полагая, что в тот же момент может быть много подобных процессоров, 100% загрузка процессора просто не используется. Возможно, потоки OMP активно ожидали новых задач?

Я использую MSVC 2013.

+0

Возможно ли предоставить вам информацию (код) о том, как вы распараллеливаете этот цикл? –

ответ

0

Вы правильны, нити спиннинг (ожидание в барьере) для следующей итерации. Вы можете контролировать это поведение с помощью OMP_WAIT_POLICY, и уже возник вопрос о том, как это сделать для MSVC.

Я должен предупредить вас, что если вы измените политику на PASSIVE, другие потоки могут не спешить, чтобы выполнить работу, и это может привести к задержке или дрожанию для ваших вычислений. Если обработка работает на одном потоке приемлемо быстро, я бы продолжал использовать только один поток, чтобы гарантировать реальное время.

Смежные вопросы