Читать книгу Made at Intel: Сделано в Intel - - Страница 9

Колоссальное (при этом не всегда положительное). Я не знаю другого бенчмарка, который оказал бы сравнимое воздействие на историю вычислительной техники в области HPC. Вторым, наверно, идет SPEC CPU, но разрыв огромен (по вышеперечисленным причинам). По сути, SSE2-SSE4, AVX, AVX2, AVX-512 – это все про Линпак. Я здесь остановлюсь на трех кейсах, которые протекали при моем (прямом или косвенном) участии.

• FMA впервые в истории Intel x86 увидел свет в процессоре Haswell. Fused Multiply-Add – это настолько же естественно, как улыбка младенца. Если ты занимаешься умножением, то сложение можешь получить практически бесплатно. Для целых чисел это очевидно, для чисел с плавающей точкой (IEEE754) чуть сложнее, но ненамного. К тому же, по счастливому стечению обстоятельств, наши алгоритмы (например, Dot Product) устроены так, что количество сложений и умножений примерно одинаково. И когда инициативная группа ребят предложила FMA под лозунгом «Линпак – в двойку!», c ними практически никто не спорил. Не, ну а чего спорить, когда ты получаешь сплошные плюсы без каких-либо серьезных минусов.

• AVX-512. Cледующая попытка удвоения производительности была связана с расширением длины SIMD. И вот тут, как говорится, «нашла коса на камень». Возражения возникли моментально, и сколько мы копий тогда сломали, в 2010-2013-х (примерно), пером не описать…

a. Нет в природе столь длинных векторов, чтобы эта машинка давала какие-то преимущества.

b. Tail processing[8]. Чем длиннее SIMD, тем большей проблемой становится обработка «хвостов» циклов, не кратных 8 (16, 32 и т. п.) операндам. Частично проблема решается маскированием, но лишь частично.

c. Mы в очередной раз уродуем кодировку команд, вводя расширение EVEX.

d. Bytes/Flop. Это было мое основное возражение. Мы усугубляем извечную проблему баланса между загрузками и числодробильными операциями (отношение stream/linpack). И эту архитектуру становится все тяжелее программировать.

e. Непонятно, насколько хорошо можно реализовать всю эту концепцию с физической точки зрения. Как ни странно, в тот момент «люди с паяльниками» вели себя на удивление тихо. Типа «надо – сделаем». И, как оказалось, напрасно…

И все же сила заклинания «Линпак – в двойку!» оказалась достаточной, чтобы перевесить все эти соображения. AVX-512 появился в Xeon Phi и Хeon (начиная со SkyLake) и сразу столкнулся со сложностями. Выяснилось, что основную роль играет именно последнее возражение. Функционирование AVX-512 приводит к перегреву кристалла, и непонятно, как с этим бороться. Упрощенно ситуацию можно описать так. При задействовании AVX-512 в единицу времени срабатывает очень много транзисторов. И они рассеивают много энергии в виде тепла. И ладно бы нагревание происходило равномерно по площади кристалла. С этим можно бороться – поставить кулер помощнее, подвести жидкостное охлаждение и т. п. Но беда в том, что перегрев происходит локально, и это делает проблему куда более злобной. Поначалу Intel пошел по пути наименьшего сопротивления – просто начал сбрасывать частоту при задействовании AVX-512 (в экстремальном случае чуть ли не на гигагерц). Это серьезно подсаживало производительность системы, но на тот момент представлялось временной мерой. Другой путь состоял в том, чтобы «размазать горячие вычисления» по площади кристалла (ядра). Однако тут возникла другая проблема – с синхронизацией и собиранием результата «в кучу». И она оказалась сложнее, чем представлялось изначально. За восемь лет усилий лучшие умы в области электроники так и не смогли подобраться к решению. То, что «Интел» постепенно отказывается от AVX-512, служит косвенным доказательством. И все же хочу сказать пару слов в защиту наших тогдашних решений. Это сейчас представляется «научно доказанным фактом», что 256 бит – оптимальная длина SIMD. А 10 лет назад это было ни разу не очевидно. Наступать на грабли – удел пионеров.

Xeon Phi явился, наверно апогеем культа Linpack. AVX-512 хотя бы умирает (и не факт, что умрет) мучительной смертью, следуя пожеланиям обычно нордически-сдержанного Линуса Торвальдса. В то время как Xeon Phi так и не сумел толком оторваться от взлетной полосы. Он задумывался как ответ набиравшим силу GPGPU. Концепция была такая: давайте натыкаем кучу слабосильных (в Knights Corner использовалась архитектура Pentium), низкочастотных ядер с «православной» ISA и снабдим их зубодробительной длины SIMD. Все это неплохо работало ровно на одном бенчмарке (угадайте, каком). Как только Xeon Phi сталкивался с критическими участками однопоточного кода (а такими, например, являются огромных размеров «cвитчи» в MPI), он немедленно шел на дно (кстати, ISA тут ни при чем.) Всего этого можно было бы избежать, если б в качестве основного теста был взят не HPL, а хотя бы HPCC. Но увы, случилось так, как случилось…