Я не эксперт по всем вопросам, связанным с архитектурой x86 (так что, надеюсь, кто-то более опытный может принять участие), но вот несколько ответов высокого уровня на ваши вопросы.
Я слышал, что ARM не поддерживает технологию Hyper-Threading [...]
Правильно, технология Hyper-Threading - это запатентованная функция проектирования микросхем Intel.Я не знаю аналогичной кремниевой технологии ARM.
[...] и поэтому мои 4-ядерные процессоры уже будут переключать контекст, чтобы не отставать от моих 6-ти потоков (и фоновых процессов).Какой вид снижения производительности следует ожидать от этого?[...]
Это не обязательно случай, хотя это вполне может произойти во многих сценариях.Это действительно зависит больше от того, какова природа ваших вычислений для каждого потока ... Вы просто делаете много здоровенных вычислений, или вы делаете много блокировок / ожидания на IO?В любом случае, это ухудшение произойдет на обеих архитектурах, и это скорее общая проблема планирования потоков.В мире многопоточного Intel каждое «физическое ядро» рассматривается ОС как два «логических ядра», которые совместно используют одни и те же ресурсы, но имеют свой собственный конвейер и наборы регистров.Статья в Википедии гласит:
Каждый логический процессор может быть индивидуально остановлен, прерван или направлен на выполнение указанного потока, независимо от другого логического процессора, имеющего то же физическое ядро. [7]
В отличие от традиционной двухпроцессорной конфигурации, в которой используются два отдельных физических процессора, логические процессоры в гиперпоточном ядре совместно используют ресурсы выполнения.Эти ресурсы включают в себя механизм выполнения, кэши и интерфейс системной шины; совместное использование ресурсов позволяет двум логическим процессорам работать более эффективно друг с другом и позволяет логическому процессору заимствовать ресурсы из остановленного логического ядра (при условии, что оба логическихядра связаны с тем же физическим ядром).Процессор останавливается, ожидая данных, которые он отправил, чтобы он мог завершить обработку текущего потока.Степень преимуществ, наблюдаемых при использовании гиперпоточного или многоядерного процессора, зависит от потребностей программного обеспечения и от того, насколько хорошо оно и операционная система написаны для эффективного управления процессором. [7]
Так что, если некоторые из ваших потоков постоянно блокируют ввод-вывод, то это может быть тем, где вы увидите больше улучшений в 6-поточном приложении в системе с 4 физическими ядрами (как для ARM, так и для ARM.intel x86), поскольку теоретически это - то, где гиперпоточность сияла бы ... поток, блокирующий IO или результат другого потока, может "спать", все еще позволяя другому потоку, работающему на том же ядре, работать без полной нагрузкипереключатель потока (эксперты, пожалуйста, позвоните мне и скажите, если я здесь не прав).
Но 4-ядерный ARM против 2-ядерного x86 ... при условии, что все остальные равны (что, очевидно, не так, в действительности тактовые частоты, иерархия кэша и т. Д. Имеют огромное влияние), тогда я думаю, чтодействительно зависит от характера потоков.Я мог бы предположить, что это падение производительности может произойти, если вы просто выполняете тонну вычислений с чисто CPU-привязкой (т. Е. Потокам никогда не нужно ждать чего-либо внешнего от ЦП).Но если вы делаете много блокирующих операций ввода-вывода в каждом потоке, вы можете продемонстрировать значительное ускорение, которое может составить до 3 или 4 потоков на логическое ядро.
Еще одна вещь, которую нужно иметь в виду, это кеш.При выполнении большого количества вычислений, связанных с процессором, у переключателя потоков есть возможность взорвать кэш, что вначале значительно замедляет доступ к памяти.Это произойдет в обеих архитектурах.Однако это не относится к памяти ввода / вывода.Но если вы не делаете много блокировок, то дополнительные издержки с многопоточностью просто замедлят работу по указанным выше причинам.
Я слышал, что должен ожидать, что эти переключатели контекста ARM будут менее эффективными, чем x86.Это правда?
Аппаратный переключатель контекста - это аппаратный переключатель контекста, вы помещаете все регистры в стек и переключаете некоторые биты, чтобы изменить состояние выполнения.Так что нет, я не верю, что в этом отношении "быстрее". Однако для одного физического ядра такие методы, как гиперпоточность, делают «переключение контекста» в смысле операционных систем (я думаю, что вы имеете в виду переключение между потоками) намного быстрее, поскольку инструкции обеих программ уже выполнялисьпараллельно на том же ядре.
Я ничего не знаю о GCD, поэтому не могу комментировать это.
В конце концов, я бы сказал, что ваш лучший способ - сравнить приложение на обеих архитектурах.Посмотрите, где ваши узкие места.Это в доступе к памяти?Поэтому сохранение кеша горячим является приоритетом.Я полагаю, что 1 поток на ядро всегда будет оптимальным для любого сценария, если вы можете использовать его.
Несколько хороших вещей для чтения по этому вопросу:
- https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
- https://lwn.net/Articles/250967/
- Оптимальное числопотоков на ядро
- Переключатель контекста потока Vs.переключение контекста процесса