«Самосожжение» Боба Колвелла
Кульминация, однако, случилась еще раньше. Боб Колвелл (один из самых уважаемых мной дизайнеров) проработал в «Интел» всего пять лет (19952000), но сумел оставить в истории компании яркий след. Он был одним из ведущих архитекторов линейки Pentium и, наверно, раньше всех осознал, что «гонка гигагерц» тупиковый путь. Однако беда была в том, что тогда частота уже превратилась из чисто физического (или инженерного) понятия в предмет новой религии. И обычными средствами набирающую ход лавину было уже не остановить
В одно прекрасное утро Бобу Колвеллу позвонил тогдашний CEO «Интел» Крейг Баррет. С Крейгом я встречался лично раз пять (больше только с нынешним CEO Пэтом Гелсингером), и он всегда производил впечатление человека исключительно здравомыслящего. Но, видимо, в том момент всеобщий экстаз захватил и его.
Боб, дружище, нельзя ли поднять частоту еще на 20 %? «поинтересовался» Крейг.
Это очень сложно, ответил Боб. И более того, контрпродуктивно.
Но тем не менее частота была поднята.
Следующий звонок был таким:
Боб, дорогой. Нельзя ли добавить еще процентов 15?
Это почти невозможно и бессмысленно.
Ну постарайтесь, вы же настоящие гении
И последний.
Боб, золотой мой, кровь из носа нужно еще 10 %.
I deliberately do not agree[3], ответил Боб, повесил трубку и написал заявление «по собственному желанию». Позже он описал это в своей замечательной книге The Pentium Chronicles: The People, Passion, and Politics Behind Intels Landmark Chips[4].
Дальнейшее развитие
Но «Интел» не был бы «Интелом», если бы так легко отказывался от своих убеждений. NetBurst вышел на рынок и столкнулся там с платформой AMD Opteron, которая мало того что имела существенно более короткий конвейер, так еще и обладала встроенным контроллером памяти. В то время как интеловские платформы все еще использовали технологию North Bridge. На меня самое большое впечатление произвел следующий эпизод. Мы как-то попробовали запустить Linpack на процессоре Irwindale. И не смогли получить более 70 % эффективности. Обычно неприхотливый HPL уперся в memory bandwidth. Возможно, мы что-то сделали не так, но шок был настолько велик, что мы очень быстро это занятие бросили.
Реальность рынка быстро оказала свое отрезвляющее воздействие. Intel начал стремительно терять долю рынку в пользу AMD. Однако ситуация, как ни странно, имела и положительные моменты для развития софтовой организации в «Интел» (и российской в частности). Контора осознала, что программатуру можно использовать для того чтобы прикрыть недостатки архитектуры. Нас бросили «на фронт», чтобы «распрямлять» коды (уменьшать количество ветвлений) и по возможности уменьшать зависимость от memory bandwidth. В «Интел» наступил (второй?) «золотой век софта». Затем в 2005 году, как глоток свежего воздуха, появился Merom, разработанный в Israel Design Center (IDC). Архитектура Core имела существенно более короткий конвейер и скорее являлась развитием идей P3. Но окончательно «смутное время» закончилось с выходом Nehalem серверного чипа с архитектурой Core и интегрированным контроллером памяти. Империя встала с колен и нанесла сокрушительный ответный удар.
Architecture and religion 2
Linpack как важнейшее из искусств
Второй важнейший «культ», который определял развитие серверной архитектуры на протяжении десятилетий, это «сакрализация» Linpack. Сам бенчмарк представлен Джеком Донгаррой аж в 1979 году. Но культовым статусом своим он обязан усилиям маркетологов из многих IT-компаний (Intel, AMD, IBM, Nvidia, Fujitsu и т. д.). Linpack имеет массу неоспоримых достоинств.
Это всего лишь ОДИН тест, в отличие от, скажем, SPEC CPU, где их 40 с хвостиком.
К тому же (в отличие от SPEC) он совершенно бесплатный.
Очень легко объяснить, что Linpack делает. Он решает систему линейных алгебраических уравнений с числами двойной точности. Используется метод (P) LU-разложения (Гаусса) с выбором ведущего элемента.
В качестве результата Linpack выдает ОДНО число измеренную производительность системы в (гига-, тера-, пета-, экза-) флопах. На основании Linpack строится мировой рейтинг суперкомпьютеров TOP-500 и российский TOP-50. Так же вычисляют эффективность (искушенные люди обращают на нее внимание) как отношение измеренной производительности к пиковой. Правда, в последнее время само понятие эффективности является несколько «размытым» из-за того, что в процессе исполнения теста тактовая частота может «плавать».
Linpack идеально параллелится (MPI, OpenMP и вообще что угодно) и векторизуется.
И, наконец, Linpack обеспечивает практически полную (> 90 %) загрузку вычислительных устройств. В то время как обычные приложения редко показывают больше 20.
И все же Linpack это всего лишь ОДИН (и к тому же весьма специфичный) тест, и переоценка его роли обходится очень дорого. Тем не менее история показывает, что зачастую так оно и происходило.
Гении Линпака
Несмотря на интенсивный promotion со стороны маркетинга, Linpack не приобрел бы и половины своей популярности, если бы не вклад многих талантливых инженеров. Вслед за Донгаррой, безусловно, надо упомянуть Kazushige Goto. Этот парень настоящий гений (вот только разговорный английский у него хромает), а его статья Anatomy of High-Performance Matrix Multiplication[5] давно стала «настольной книгой» для разработчиков библиотек. Я часто приходил к нему с разными вопросами по Линпаку: «Гото-сан, почему так?» И он обычно начинал свои объяснения фразой: «Ну вот представь, что ты Linpack. Как бы ты поступил на его месте?» Конечно, я ничего не представлял. Просто сидел и слушал с открытым ртом. Потому что для меня это какой-то запредельный уровень понимания. Велик вклад ребят из интеловских MKL (а Linpack это на 95 % dgemm) и MPI. А также их аналогов для других платформ. Ну и не забуду коллег из Intel Competitive Response Team, в которой я провел восемь лет (20052013). В нашу задачу входила поддержка больших тендеров в области High Performance Computing[6], а также сопровождение подачи заявок в рейтинг Top-500 Supercomputers для свежепостроенных кластеров на базе процессоров Intel.
Мерило тщеславия
Top-500 самый престижный мировой рейтинг суперкомпьютеров. Чтобы попасть туда, люди тратят десятки и сотни миллионов долларов. Нужно купить и собрать систему, которая может насчитывать десятки тысяч узлов и сотни тысяч интерконнектов. И когда все это сделано, остается последний (и очень ответственный) штрих измерить производительность системы с помощью теста Linpack и подать заявку. Задача эта отнюдь нетривиальная у нас была разработана многошаговая процедура для достижения максимального результата. Но надо понимать, что Linpack это не только Computer Science[7], это еще и игра вероятностей. Продолжительность теста зависит от многих факторов: производительности процессоров, количества памяти на узел, количества MPI-ранков и OMP-тредов (если используется гибридная схема параллелизации) и т. д. Таким образом, время прогона может варьироваться от часа до десяти (а то и больше). А за это время с системой из нескольких тысяч узлов может случиться все что угодно перегреться один из процессоров, отвалиться интерконнект, «cнести башню» драйверу и т. п. Поэтому мало все сделать правильно нужно, чтобы тебе еще и немного повезло. И ты не можешь предсказать, когда это случится. Для того чтобы получить хороший результат, может потребоваться несколько сотен экспериментальных и «боевых» прогонов. Поэтому за 34 недели до International Supercomputing (июнь) и US Supercomputing (ноябрь) у нас начиналась горячая пора. Работа велась посменно и не прекращалась круглые сутки.