Кульминация, однако, случилась еще раньше. Боб Колвелл (один из самых уважаемых мной дизайнеров) проработал в «Интел» всего пять лет (1995–2000), но сумел оставить в истории компании яркий след. Он был одним из ведущих архитекторов линейки Pentium и, наверно, раньше всех осознал, что «гонка гигагерц» – тупиковый путь. Однако беда была в том, что тогда частота уже превратилась из чисто физического (или инженерного) понятия в предмет новой религии. И обычными средствами набирающую ход лавину было уже не остановить…

В одно прекрасное утро Бобу Колвеллу позвонил тогдашний CEO «Интел» Крейг Баррет. С Крейгом я встречался лично раз пять (больше только с нынешним CEO Пэтом Гелсингером), и он всегда производил впечатление человека исключительно здравомыслящего. Но, видимо, в том момент всеобщий экстаз захватил и его.

– Боб, дружище, нельзя ли поднять частоту еще на 20 %? – «поинтересовался» Крейг.

– Это очень сложно, – ответил Боб. – И более того, контрпродуктивно.

Но тем не менее частота была поднята.

Следующий звонок был таким:

– Боб, дорогой. Нельзя ли добавить еще процентов 15?

– Это почти невозможно и бессмысленно.

– Ну постарайтесь, вы же настоящие гении…

И последний.

– Боб, золотой мой, кровь из носа нужно еще 10 %.

– I deliberately do not agree[3], – ответил Боб, повесил трубку и написал заявление «по собственному желанию». Позже он описал это в своей замечательной книге The Pentium Chronicles: The People, Passion, and Politics Behind Intel’s 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 и интегрированным контроллером памяти. Империя встала с колен и нанесла сокрушительный ответный удар.

Второй важнейший «культ», который определял развитие серверной архитектуры на протяжении десятилетий, – это «сакрализация» 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, в которой я провел восемь лет (2005–2013). В нашу задачу входила поддержка больших тендеров в области High Performance Computing[6], а также сопровождение подачи заявок в рейтинг Top-500 Supercomputers для свежепостроенных кластеров на базе процессоров Intel.

Top-500 – самый престижный мировой рейтинг суперкомпьютеров. Чтобы попасть туда, люди тратят десятки и сотни миллионов долларов. Нужно купить и собрать систему, которая может насчитывать десятки тысяч узлов и сотни тысяч интерконнектов. И когда все это сделано, остается последний (и очень ответственный) штрих – измерить производительность системы с помощью теста Linpack и подать заявку. Задача эта отнюдь нетривиальная – у нас была разработана многошаговая процедура для достижения максимального результата. Но надо понимать, что Linpack – это не только Computer Science[7], это еще и игра вероятностей. Продолжительность теста зависит от многих факторов: производительности процессоров, количества памяти на узел, количества MPI-ранков и OMP-тредов (если используется гибридная схема параллелизации) и т. д. Таким образом, время прогона может варьироваться от часа до десяти (а то и больше). А за это время с системой из нескольких тысяч узлов может случиться все что угодно – перегреться один из процессоров, отвалиться интерконнект, «cнести башню» драйверу и т. п. Поэтому мало все сделать правильно – нужно, чтобы тебе еще и немного повезло. И ты не можешь предсказать, когда это случится. Для того чтобы получить хороший результат, может потребоваться несколько сотен экспериментальных и «боевых» прогонов. Поэтому за 3–4 недели до International Supercomputing (июнь) и US Supercomputing (ноябрь) у нас начиналась горячая пора. Работа велась посменно и не прекращалась круглые сутки.