Раз уж начали говорить про Xeon Phi, то стоит раскрыть одну важную особенность этих соп...
Раз уж начали говорить про Xeon Phi, то стоит раскрыть одну важную особенность этих сопроцессоров. Если в обычных серверных Xeon каждое ядро может обрабатывать до 2 потоков (при поддержке технологии Hyper-Threading), то в Xeon Phi Intel пошла дальше и дала каждому ядру сразу 4 аппаратных потока. Благодаря этому Knights Corner получил до 244 потоков на 61 ядре, а Knights Landing и Knights Mill до 288 потоков на 72 ядрах. Но для этого была веская причина. Intel хотела уместить на кристалле как можно больше ядер, поэтому каждое ядро было очень простым. В Knights Corner его основой стал глубоко переработанный Pentium (P54C), который исполнял инструкции строго по очереди. Если в такое ядро попадала команда, ждущая данные из памяти, все вставало: обойти её и заняться чем-то другим ядро не могло. Intel решила эту проблему так: если нельзя ускорить один поток, нужно дать ядру еще несколько. Ядро Knights Corner каждый такт по кругу брало инструкции из следующего потока, причем один поток не мог выдавать команды два такта подряд — при запуске одного потока ядро работало максимум на половину мощности. В Knights Landing ядра заменили на внеочередные Silvermont из линейки Atom, и один поток наконец мог полноценно загружать ядро. Но 4 потока сохранили, потому что каждому ядру теперь достались два 512-битных векторных блока, и прокормить их данными одним потоком было сложно. Но за 4 потока приходилось платить: 😎 4 потока делили один L1-кэш и вытесняли данные друг друга. Многие задачи на Knights Landing работали быстрее только на 1-2 потоках на ядро. 😎 Для полной загрузки чипа задачу нужно было разбить на 244-288 потоков, а масштабироваться так умел далеко не каждый код. 😎 Любой последовательный участок программы на медленном ядре с частотой около 1-1,5 ГГц тормозил всю задачу. 😎 Видеокарты держали в работе десятки тысяч потоков и легко переключались между ними. 4 потока на ядро терпели задержки гораздо скромнее. В итоге Intel обещала, что Xeon Phi запустит обычный x86-код, и формально так и было. Но чтобы он работал быстро, его приходилось оптимизировать под массовый параллелизм не меньше, чем под GPU. А раз уж переписывать код все равно нужно, интеграторы предпочитали именно GPU. Хотите узнать больше о Xeon Phi? Обязательно посмотрите наш обзор! 😅 Канал Serverflow в MAX: Подписаться