В тот день была моя очередь, и я появился на работе в 8:30. Экстремально рано по своим меркам. В офисе было пусто график посещения в нашей развеселой лавочке был фривольный, и раньше 1011 обычно никто не появлялся. Застал я только Серегу Шальнова, который гонял Linpack в ночную смену на немецком кластере.
Чё как? осведомился я за текущий статус.
Ночной ран не выжил, мрачно откликнулся Шальнов. Сразу несколько узлов скопытились. Я полночи ковырялся, чтобы их вычислить и удалить из списка.
Потом мы наскоро прикинули «расклад» (параметры Np, P и Q) с учетом изменившегося количества узлов, и в этот момент у Сереги зазвонил телефон. Оказалось, что это Войтек, польский чувачок, который занимался технической поддержкой того кластера, на котором мы гоняли тест. Процесс его настолько захватил, что он приперся на работу даже раньше восьми по своему времени.
Серега, заряжай! прокричал Войтек так, что даже мне было слышно.
Ты куда торопишься? спросил Шальнов. Скорее в историю войти?
Дело не в этом. У нас тут похолодало. У меня в подсобке возле датацентра семь градусов. И если ты сейчас не запустишь Linpack (а тепла в процессе теста выделяется дай Бог), я тут сдохну от холода.
Серега положил трубу, посмотрел на меня уставшими, красными после бессонной ночи глазами и изрек:
Предназначение Линпака не в том, чтобы быть мерилом человеческого тщеславия. Предназначение Линпака в том, чтобы приближать тепловую смерть Вселенной
Linpack vs HPCC
Если речь зашла о разных «мерилках», то уместно будет упомянуть о HPCC. Мой товарищ Андрей Нарайкин активно продвигал этот набор бенчей как «альтернативу» Линпаку. Нет, разумеется, HPL в составе High Performance Computing Challenge (HPCC) тоже был. Но кроме этого там присутствовали Stream (вечный «антипод» Линпака), Random Access и FFT (плюс несколько дополнительных). Я тогда стебался в том духе, что «Излюбленное занятие джентльменов мериться размерами достоинства. А ты хочешь указать им на то, что у достоинства, помимо длины, есть еще и другие тактико-технические характеристики. Например, толщина, коэффициент расширения, угол стояния и т. п.» А теперь, спустя более 15 лет, я понимаю, насколько Андрюха был прав. Если бы джентльмены не зацикливались исключительно на длине достоинства, «Интел» сумел бы впоследствии избежать многих болезненных проблем.
Влияние на архитектуру
Колоссальное (при этом не всегда положительное). Я не знаю другого бенчмарка, который оказал бы сравнимое воздействие на историю вычислительной техники в области 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. Но увы, случилось так, как случилось
И снова о «гениях»
В момент краха Xeon Phi я был от этого уже довольно далеко. Последние годы в Intel (20162020) я провел, возглавляя команду VTune. И фокус моего внимания был сильно смещен в сторону uncore. Во-первых, хотелось какого-то разнообразия. Во-вторых, uncore-поляна, в отличие от core, была сильно менее изученной и «затоптанной». В-третьих, становилось понятно, что с увеличением числа ядер в процессоре роль core падает, а uncore растет. Центром «анкорной» мысли тогда была тусовка под названием IO-intensive workloads group[9]. Я еще в шутку называл ее «клубом любителей DPDK». Кроме самого DPDK, в игре были и другие прилаги базы данных, Hadoop, Ceph. Но всепроникающая сила Линпака в «Интеле» была такова, что он сумел меня достать и там. Проблемы наша группа обсуждала суровые. Вот есть core, uncore, шина и девайс и все это работает на разных частотах. Как сопрячь, буферизовать и синхронизировать? А как быть с RDMA? В общем, почти любой доклад на этой группе так или иначе превращался в «плач Ярославны». И если core-тусовка, периодически наступая на грабли, оставалась более или менее на позитиве, то наша лавочка напоминала сборище неисправимых нытиков.
Был там такой «обряд посвящения», стихийно сложившийся и оттого особенно смешной. Бывало, приходил к нам мальчик, только что закончивший Стенфорд, Беркли или другое уважаемое учебное заведение Объединённых Штатов Северной Америки. Первый раз он обычно сидел тихо, внимательно слушая наши стенания. Зато в следующий раз приходил одухотворенный.
Ребята, я понял, что надо сделать.
Ну и?
Надо понизить частоту ядра. Ведь оно все равно по большей части ждет ввода-вывода. И чем меньше оно намолотит тактов в этом процессе, тем лучше, в этот момент у ветеранов тусовки делались уксусно-кислые лица. Типа «ну вот, еще один юный гений»
Все это логично, правильно и было бы хорошо, если б не одно «но», в тот день была моя очередь «резать правду-матку».
Какое?
Знаешь, что сделает с нами маркетинг за недобор флопов на Линпаке? Он утопит нас в пруду. Всех в одном мешке, как котят. Даже не будет разбираться, чья идея была.
Правда? голос у паренька заметно дрожал.
Ага. Добро пожаловать в реальный мир.
На этом разговор закончился, но спустя некоторое время пожилой и уважаемый всеми индус, который председательствовал в группе, сделал мне замечание в личной беседе:
Зря ты так, Валер. Парнишка прям серьезно расстроился.
Да ладно, пусть привыкает. Здесь не Стенфорд.
И тут он меня ненавязчиво осадил:
Ну, ты сам-то вспомни, что сказал, когда первый раз к нам пришел
Architecture and religion 3
Главная вера
И все же важнейшей религией компании является сама x86 Instruction Set Architecture[10]. Intel изначально свято придерживался принципа backward compatibility[11] программы, написанные для предыдущих поколений процессора, работают на следующих без изменений (ну, разве что требуют эмулятора операционки). Без этого нельзя построить никакой экосистемы, ибо ее формирование процесс, занимающий многие годы. И именно благодаря последовательности Intel x86 ISA стала для компьютерного мира чем-то вроде христианства. Аналогию можно продолжить, сравнив разделение христианства на католическую и православную ветви Intel и AMD (или наоборот). Но мы этого делать не будем. Однако принцип backward compatibility требует, чтобы любое изменение ISA оставалось в ней навсегда. И, наверно, нам следовало относиться к архитектуре более бережно. Когда я был маленьким, а деревья большими, один умный человек (Ronak Singhal) говорил мне, что тут, дескать, не о чем печалиться. С каждым shrink (переходом на более совершенный процесс изготовления чипов) площадь, необходимая для поддержки legacy[12] инструкций, «сжимается» в два раза. Но вот когда Intel серьезно «застрял» на 10-нм техпроцессе, мои опасения вернулись с удвоенной силой.
Отчасти, впрочем, наши промахи можно объяснить тем, что x86 «закрытый клуб», в отличие от ARM и тем более RISCV. Ну, например, собирается ARM «выкатить» новую версию ISA. Он будет согласовывать ее со всеми основными вендорами Apple, Samsung, Qualcomm и т. д. Поэтому у него куда меньше шансов совершить какую-нибудь глупость. Intel, конечно, тоже советуется с основными партнерами Microsoft, Google, Amazon. Но основные решения все же принимаются внутри. Мне это почему-то представлялось так. На унылом севере, вдали от людского жилья, стоит темная башня. Лишь на последнем этаже ее горит свет. И там наверху собрались адепты тайного ордена В случае с «Интел» «орден» имеет вполне конкретное название ISA CPT. Именно там принимаются самые важные архитектурные решения. На этот митинг вхожи лишь ведущие технические лидеры компании Fellows, Senior Principal Engineers. Мне трудно всерьез назвать себя одним из адептов (так, скорее, младшим послушником). Но я всегда был юношей любопытным, и время от времени мне удавалось туда пролезть (восьмым) содокладчиком в какой-нибудь презентации или просто «вольным слушателем». Чаще все же приходилось довольствоваться информацией из вторых-третьих рук. И сегодня я немного расскажу вам о разного рода «ересях», которые зарождались и погибали внутри «Интел».
Гибель «Титаника»
Хотя Itanium нарекли «Титаником» сразу же после анонса архитектуры 4 октября 1999-го, он не был поначалу и вполовину так плох, как его реноме. Архитектура VLIW/EPIC смотрелась необычно по сравнению с CISC и манила новыми возможностями. Мою фантазию будоражили предикатное исполнение, вращающиеся регистры и explicit software pipelining[13]. К тому же IA-64 была in-order[14] архитектурой можно было точно предсказать, сколько будет обрабатываться один элемент достаточно длинного цикла при условии прогретых кэшей. Для кого как, а для меня эта «иллюзия контроля» почему-то всегда была важна. Тогда я еще плохо представлял себе важность software ecosystem[15] для успеха платформы. Да, понимал, что работа предстоит огромная, но шансы представлялись вполне себе неплохими.
Но все же Itanium, как и «Титаник», видимо, был проклят с самого начала. Дело в том, что против него играли как религия (not invented here[16]!), так и политика. А в средневековом государстве это необоримая сила. «Крестным отцом» Itanium был Mike Fister, тогдашний глава серверного подразделения Intel. И в начале 2000-х между ним и Полом Отеллини развернулась борьба за то, кто станет следующим CEO Intel после Kрейга Баррета. Борьбу эту Captain Itanic[17] проиграл и ушел в CEO в Cadence (который, безусловно, уважаемая компания, но все же не Intel). Также ко дну пошло его детище. А спасать было некому Отеллини Itanium не жаловал. Уж не знаю, вследствие «разборок» начала 2000-х или по каким-то другим причинам К тому же обнаружилась масса других проблем.
Индустрия как-то сразу не поверила в Itanium. Портирование софта шло без особого энтузиазма. А Intel не решился на большую ставку Itanium enabling strategy[18] всегда оставляла у меня ощущение какой-то недосказанности
Возможно, расчет был на x86 compatibility block[19], но именно он стал больным местом Itanium энергии потреблял больше, чем весь остальной процессор, и грелся, как сволочь. Бинарный транслятор также не выглядел панацеей: преобразование из CISC в VLIW является одним из самых сложных (хотя на «Эльбрусе» как-то работает).
Насколько увлекательным являлось написание микрокернелов для Itanium на ассемблере настолько кошмарным было портирование приложений. Компилятор является основным камнем преткновения для архитектуры VLIW/EPIC. Одно из немногих исключений, которое я знаю, опять же «Эльбрус». Но для того чтобы довести его компилятор до ума, потребовалось порядка 20 лет. «Интел» столько ждать не захотел
Ну и последнее Itanium всегда выпускался с отставанием на шаг по техпроцессу от x86. И в этом трудно не усмотреть наличие «доброй» политической воли.
IA-64 влачила жалкое существование до начала 20-х. И лишь в феврале 2019-го Linus Torvalds сказал: «Its dead, Jim[20]». Но можно было спокойно сделать это и на 10 лет раньше. И все же у меня осталось от Itanium ощущение «неспетой песни». Да, я не люблю VLIW (я тоже религиозен) и мне кажется, что рано или поздно мы бы все равно «уперлись» в его ограничения. Но все же стоило пытаться по-честному пройти этот путь
X-Files
Архитектура StrongArm (а впоследствии XScale) еще одно наследие, полученное Intel от DEC. Было тогда в компании подразделение Intel Communication Group[21]. Ваяло контроллеры для IO и сетевых устройств. И там неприхотливый и экономичный ARM пришелся весьма ко двору. Но именно в этот момент наступила эпоха handheld-девайсов (наладонников, как их тогда называли) предтечи современных смартфонов. Intel попробовал и оно как-то сразу полетело. BlackBerry, Dell, Compaq, Toshiba, Palm, Amazon Kindle вот далеко не полный список компаний, начавших производство продуктов на базе XScale. Воодушевившись, в 2004-м Intel выпустил SIMD-расширение ISA под названием Wireless MMX. И в отделе IPP (в котором я пребывал с 2002-го по 2005-й) закипела работа по оптимизации библиотек.