Две работы
Общение с менеджментом иногда производит на меня сильное впечатление - в результате решил опубликовать свои воспоминания времен работы в коорпорации Интел.
Как-то уже писал про бюрократические традиции внутри корпорации Интел. Я не знаю почему, но мне всегда хотелось понять в работе какие конкретно цели перед тобой ставят, за что ты отвечаешь и к чему нужно стремится. Если ты работаешь над продуктом, то определяющим являются свойства продукта и его качество. Посыл о том, что главное это понравится руководителям, всегда вызывал во мне внутренний протест. Ну и соответственно мне нравились руководители, которые старались разобраться в полученном им деле. Не нравились карьеристы - стремящиеся просто быть исполнительными и ищущие все указания у высших начальников.
Ну и что-то захотелось вспомнить и рассказать историю времен работы в Интел.
Работа первая.
Уже после полного обюрокрачивания разработки компилятора Интел сложилась у нас прекрасная команда менеджеров, которая направляла развитие компиляторов. В компиляторах эти люди понимали мало, но в “лидерстве”, наверное, были доки и конечно понимали, что настоящие лидеры должны о себе заявлять и демонстрировать “достижения”. Демонстрировать, что компилятор Интел самый лучший у них получалось не всегда - были проблемы. Часто на каких-то группах тестов компилятор проигрывал конкурентам. Покупать его особо не хотели. Время компиляции было на порядок больше, стабильность оставляла желать лучшего а выигрыш в производительности не всем был нужен. Простые решения не работали - для лидерства в таком деле нужны свежие идеи, ну а свежие идеи требовали разбираться в сути науки о компиляторах, архитектуре процессоров и т.п - а это хлопотно. Разработки каких-то новых и отладка старых оптимизаций требует времени, а его всегда нет.
Вот как-то и задумались менеджеры, а как нам похвалить компилятор каким-то новым и неожиданным способом. Вспомнили, что есть на процессорах Интел векторные инструкции и решили, что в плане поддержки векторных инструкций компилятор Интел точно должен быть на голову выше конкурентов. Ну и разработали план сравнить “покрытие” векторных инструкций в icc, gcc и VS. А мне повезло. Я подчинялся напрямую одному из наших “лидеров” и мне поручили это делать. По хорошему вроде бы это должны делать люди из команды векторизации, но они слишком заняты были и ими в техническом плане руководил принципал-инженер, который не прорубил в чем фишка этой работы и видимо послал менеджеров лесом и не дал ресурсов.
Работа вроде понятная. Компилируешь какие-то приложения с различными опциями разными компиляторами и потом смотришь какие векторные инструкции появились в коде. Но поскольку идея была понятна всем, даже менеджерам, то детали постоянно изменялись. Нужно было составить таблички - компиляторы, сюиты, типы векторных операций и т.п. Одна и та-же операция с разными типами операндов может относиться к разным группам, поэтому требовался секретный дизасемблер, который это учитывал. Я так понимаю, что работал над вычислением нужных циферок я один, а детали и предварительные результаты обсуждались на недельных менеджерских митингах, где постоянно креативились новые идеи. У моего менеджера тоже были прекрасные идеи. Он, например, хотел бы что-бы приложение расчитывающее циферки покрытия инструкций было многопоточным и работало очень быстро. Типа “четыре часа это много - хорошо все бы расчитывалось за час .” Ну у нас-то компилятор меняется непрерывно - поэтому понятно, что такие требования выглядять обоснованно и режим реального времени рулит ;). Все шло в довольно бодром темпе и вот, наверное, после пары месяцев работы какой-то консенсус был достигнут, генерация новых идей была заморожена, таблички были построены. Понятно, что по использованию векторных инструкций наш компилятор всех рвал. Ну и смысл какой-то вроде в этой работе был. Типа смотрите, кроме интеловского компилятора никто не умеет использовать самые последние векторные инструкции процессора Интел, и даже в тех инструкциях, что внедрены много лет назад мы впереди планеты всей. Т.е. посыл ясный - хотите пользовать самые свежии новшества в железе от Интел - покупайте компиляторы Интел. Отошлите эти цифры в отдел маркетинга - может им пригодяться.
Но оказывается в процессе финального обсуждения подход был раскритикован - Microsoft наши коллеги (неправильно говорить что их компилятор почти не умеет делать векторизацию), в gcc векторизацию делают наши люди из Москвы и … Вообщем не надо стрелять себе в ногу. Вообщем 90% работы пошло в урну. Вице президенту был представлен слайд на котором утверждалось, что компилятор покрывает много инструкций из последнего AVX512 семейства - процентов 26% нашли, еще процентов 20 используются в библиотеках как ассемблерные вставки, процентов 20% не используется и тесты еще для большого кол-ва инструкций пока не нашли. Но найдем …
Вообщем это был самый офигенный квартал в моей жизни. Три месяца более-менее непрерывной работы ради бесмысленной таблички для вице-президента Била Сэвиджа (на фотке). Поскольку мой менеджер считал, что одним из основных плюсов разработчика является полная концентрация на приоритетной проблеме - то никакими другими проблемами заниматься было нельзя. Ну и по факту бесмысленная мышь родила огромного бесмысленного слона. Мы подписались на то, что найдем какие-то тесты, для которых компилятор генерит ненайденные пока инструкции. При этом забавно, что менеджер поджимал губы и считал, что я работу делаю плохо - не могу найти нужные тесты. Кто-то решил, что циферка должна быть больше 50%. Ну а 26% - это как-то неубедительно.
Дальше маразм начал крепчать. Если изначально для поиска использовали большие репрезентативные сюиты, то теперь решили прошерстить всю тестовую базу полностью. Всякие экспереминтальные тесты и т.п. НО нужный процент не натягивался ;). Инструкции, которые компилятор не генерил были спущены в команды векторизации и когогенерации, назначенны ответственные и т.п. Я пытался из описаний инструкций понять их природу и написать тесты, которые затем нужно было добавить в тестовые базы. В общем еще квартал работы уже с участием уже нескольких разработчиков, несколько тестов добавленных в тестовые базы, специальная экспериментальная опция, добавленная в компилятор и новые циферки были отправлены Билу Сэвиджу. Бил посвятил даже этому событию несколько слов на квартальном отчетном митинге. Типа вот компиляторная команда сдержала свое слово, провела много хорошей работы и цифры покрытия AVX512 инструкций такие. Зачем эта вся работа была нужна? Обратили на себя внимание вице президента? Продукт эта работа никак не улучшила. Ну и выводов тоже никаких из этих цифр сделано не было. Менеджеры попиарились и на этом все закончилось.
Вторая работа.
Присерно в это-же время поставили меня ответственным за баг производительности. На какой-то из embedded архитектур наш компилятор проигрывал на бенчмарке типа perlbench 7% gcc. perlbench - это компилятор языка perl. Т.е.огромная программа наполненная свичами, которые в плане производительности ведут себя совершенно непредсказуемо - чуть изменилась раскладка кода в памяти и производительность теста меняется. Ну и никто особо в этом не разбирался. В течении длительного времени приходилось мириться с тем, что в таких бенчмарках Интеловский компилятор никаких революционных оптимизаций предложить не может - несколько таких бенчмарок переодически начинали проигрывать конкурентам. Так вот в таком тесте тестировщик сделал ручную правку и утверждал, что эта правка дала 5% улучшения производительности. Я провозился какое-то время и показал, что если такую оптимизацию применить массово, то все становиться только хуже, а выбрать хорошие варианты невозможно. Но в процессе анализа вдруг всплыла проблема - важная информация терялась при понижении представления switch. Ну и пришлось решать инженерную проблему, как эту информацию протащить. Для протаскивания информации был прикручен STMT_ASSERT с помощью которого в компиляторе протягивались пользовательские прагмы. Обработка этого утверждения была добавлена в скалярные оптимизации, была подкручена его обработка еще в паре компонент, найден и исправлен баг в векторизаторе. Вообщем проделана объемная работа. На выходе получилось улучшение 1.5% производительности на perlbench, 0.75% еще на бенчмарке gobmk ну и несколько хороших результатов на менее важных тестах. Т.е. продукт был улучшен. Цифры на которых отслеживалось качество продукта тоже были улучшены. Ну и я до сих пор считаю, что это была одна из моих самых лучших работ за время работы в Интел. Гордый и довольный я расказал на 1:1 менеджеру про это достижение. Менеджер мне сказал примерно следующее: “Баг о проигрыше 7% - твое улучшение дало 1.5% - проблема не решена. Нужно было за две недели решить проблему - ты частичное решение делал 3 месяца. Это не достижение - это следствие твоей слабой профессиональной пригодности”. Вот как-то так.
Этот рассказ о двух работах - одна - работа на корзину, работа имитирующая активность, была оценена аж вице президентом, как хорошая. Другая работа, реально улучшившая выпускаемый продукт была обгажена на самом низком управленческом уравне, без какого-либо анализа деталей на базе каких-то непонятных критериев. Вот как-то так и работает бырократическая машина. Кстати говоря, все эти успешные менеджеры до сих пор продолжают работать в Интеле, имитируя бурную деятельность в компиляторе. Мне кажется, что большинство реальных разработчиков Интел давно разбежались. Имитаторы давно рулят имитаторами.