Блог

Мне было интересно выполнить проект по распознаванию лиц (чтобы использовать набор инструкций SIMD). Но в течение первого семестра текущего года я кое-что узнал о потоках, и мне было интересно, смогу ли я их объединить.

Когда мне следует избегать комбинирования инструкций многопоточности и SIMD? Когда стоит это делать?

Сохранение регистров x87 / MMX / XMM / YMM может занять довольно много времени и вызвать значительную перегрузку кэша. Обычно сохранение и восстановление состояния FP выполняется ленивым способом: при переключении контекста ядро запоминает текущий поток как «владельца» состояния FP и устанавливает флаг TS в CR0 и — это приведет к блокировке ядра всякий раз, когда поток пытается выполнить FP insn. Состояние FP старого потока и состояние FP текущего выполняющегося потока сохраняются и восстанавливаются, соответственно, в это время.

Теперь, если в течение длительных периодов времени (несколько или много переключений контекста) ни один другой поток, кроме вашего, не использует FP insns — отложенная политика не приведет к сохранению / восстановлению состояния FP вообще, и вы не получите снижения производительности.

Поскольку мы, очевидно, говорим о многопроцессорной системе, потоки, которые выполняют ваш алгоритм параллельно, не будут конфликтовать друг с другом, потому что они должны выполняться на своем собственном CPU / core / HT и иметь частный набор регистров.

tl; dr

Вас не должны беспокоить накладные расходы на сохранение и восстановление регистров FP.

Как вы думаете, почему возникла бы проблема? Регистры SIMD будут заменены, как и любые другие регистры процессора, когда происходит смена потока.

С многопоточностью и SIMD нет никаких новых проблем, о которых стоило бы беспокоиться. Пока вы выполняете SIMD правильно и эффективно, вам не о чем беспокоиться.

Это означает, что SIMD имеет свои собственные проблемы с реализацией, как и многопоточность. Но их объединение не сделает ни то, ни другое более сложным.