Материал из Linuxformat.

Интервью LXF: Занимательная механика

Мы давно не пишем программы прямо в машинных кодах, а значит, кто-то должен писать программы, генерирующие код за нас. Александр Горшенев знает эту работу не понаслышке.

Традиционно, в программировании выделяют три задачи, решение которых остается своего рода уделом избранных: разработка ядра ОС, создание компиляторов, а также взлом и защита приложений. Что касается первого, Линус Торвальдс [Linus Torvalds] еще не засветился на страницах LXF; правда, мы успели (и не раз) переговорить с Эндрью Мортоном [Andrew Morton]. Хакеры (или как вы предпочитаете называть тех, кто занимается изысканиями в третьей области?) — по натуре народ скрытный и к публичной славе не стремящейся. Что осталось не охваченным? Правильно — компиляторы! Руководствуясь этой идеей, мы перехватили разработчика Sun Studio и сотрудника петербургского офиса Sun Microsystems Александра Горшенева вскоре после его выступления на конференции Sun Tech Days, посвященного высокопроизводительным приложениям.

Linux Format: Александр, в списке докладчиков Sun Tech Days вы представлены как «живой пример того, кто может вырасти из ребенка, у которого любимой игрушкой был программируемый микрокалькулятор»...

Александр Горшенев: Да, это была «Электроника Б3‑21».

LXF: А что было потом? Вы помните свою первую серьезную программу? Что она делала?

АГ: Нет, первую не помню, но помню седьмую. Это был паровоз на БК0010‑Ш. Он, знаете ли, ехал.

LXF: И как же вы перешли от паровозов к компиляторам?

АГ: Это было в самое безденежное время, в лихие девяностые... Точнее сказать, шел 1998 год – дефолт, все было не так чтобы совсем плохо, но еще и не хорошо. В то время на матмехе СПбГУ было отделение МЦСТ, которое курировала Sun Microsystems. Однажды они решили набрать группу для разработки компиляторов Sun Studio. Ну, и набрали – в том числе и меня.

LXF: А о компиляторах с каких языков идет речь?

АГ: Сейчас я работаю в группе кодогенерации для процессоров Intel, AMD, так что это не играет роли. А в 1998 году набирали в группу разработчиков компилятора C. Я трудился в ней пять лет, а потом стал плавно перемещаться вниз по стеку.

LXF: А вам приходилось работать только над компиляторами Sun Studio или еще какими-нибудь другими? Ну, скажем, GCC...

АГ: В моем положении принимать участие в создании сторонних компиляторов не очень хорошо: внесешь правку, а потом кто-нибудь скажет, что-де твоя запятая в Sun Studio проистекает непосредственно из GCC.

LXF: Да, я понимаю.

АГ: Кстати, о запятых. Компилятор С от Sun – наследник PCC (Portable C Compiler) Стивена Джонсона [Stephen C. Johnson], который был написан на смену самому первому С-компилятору Кернигана и Ритчи и достался нам вместе с AT&t Unix. Не так давно ребята из FreeBSD снова вытащили PCC на свет, чтобы использовать в своем проекте (GCC они, как известно, недолюбливают), ну и я пошел поглядеть, что он из себя представляет. Выяснилось, что структура очень похожа на то, что есть у нас. Так что в Sun Studio можно встретить запятые если не от Кернигана с Ритчи, то от других отцов-основателей, таких как Джонсон.

LXF: Часто приходится слышать мнение, что на нынешнем этапе развития технологий писать прикладные программы можно как угодно — компилятор все соптимизирует. Да и ассемблер представлять себе вовсе не обязательно. Что вы думаете по этому поводу?

АГ: Знаете, у нас есть поговорка: «доверяйте компилятору в простых вещах и помогайте ему в сложных». Один плюс два компилятор свернет в константу за вас; цикл, наоборот, развернет и инвариант из него достанет. Но есть вещи, в которых ему надо помогать: например, если сообщить дополнительную информацию вроде «один и тот же указатель никогда не может указывать сначала на int, а потом на float», он сможет применить это знание с пользой, но сам до него не догадается.

Что же касается ассемблера, то его знание, безусловно, помогает. Если речь идет о прикладном программировании на C или C++, то надо понимать, что эти языки ориентированы на конкретную архитектуру машины – я имею в виду не Intel, Sparc и иже с ними, а более общие вещи: что у машины есть регистры, их несколько штук, есть память... Если мы возьмем принципиально другой процессор – скажем, стековый или CUDA от Nvidia, где много-много маленьких ядрышек, то там и языки должны быть другими. Половина знания об архитектуре заключена в семантике языка. Ну и, конечно, всегда полезно понимать, что на самом деле происходит внутри вашей программы: передается ли параметр функции так или этак. Это не нужно в «совсем прикладных» программах, но если взять тот же MPlayer, то без ассемблерных вставок уже никуда

LXF: А какой компилятор, на ваш профессиональный взгляд, лучше подходит для каких задач? Периодически приходится слышать фразы вроде: «Вот пересоберем ее XYZ, и все будет летать» — хотелось бы понять, имеют ли они под собой основания.

АГ: Я могу говорить за мир Unix. На компиляторы (C и C++) можно смотреть с разных сторон – например, кто на каких платформах работает. Здесь есть явный лидер – GCC. Другая широкая группа – компиляторы Sun, Intel, SGI, изначально разработанные для собственных Unix-платформ, а затем портированные в Linux, где они все и встретились. Это было знаменательное событие: до тех пор никто не пробовал запустить их на одной машине. Такие встречи позволяют помериться силами по-честному.

Или, скажем, можно взять соответствие стандарту. Если у вас есть программа, написанная на GNU C (да, есть на свете такой язык), скажем, ядро Linux, то остальные компиляторы тоже могут ею «позаниматься», но с переменным успехом. В сфере высокопроизводительных вычислений ситуация будет третья. Там, кроме SunCC и ICC, есть еще «компиляторы на букву P»: PGI и PathScale.

LXF: Но собрать-то ядро Linux при помощи Sun Studio можно?

АГ: Ну, как вам сказать – это и при помощи GCC сделать не всегда получается: возьмите «не ту» версию компилятора, и увидите только кучу сообщений об ошибках. Без исправления таких «подводных камней» ядро Linux компиляторам Sun Studio не собрать; ну, а если исправить, так вы ведь сразу же скажете, мол, «с патчами не считается»? Когда мы только портировали Sun Studio в Linux, вопросы совместимости стояли весьма остро, но с каждым релизом ситуация улучшалась. В Sun Studio 12 Update 1 была проделана большая работа, чтобы достичь совместимости с GCC на уровне ассемблерных вставок – мы научились не только понимать их, но и агрессивно оптимизировать. Нашей тестовой площадкой служат FFmpeg и MPlayer: в них огромное количество встроенного ассемблера, и задачей наших разработчиков было обеспечить корректную сборку обоих проектов от начала и до конца.

LXF: Вы несколько раз упомянули портирование Sun Studio в Linux — а что вообще скрывается за этими словами? Насколько сложно перенести компилятор из одной Unix-системы в другую?

АГ: Трудности при портировании делятся на две категории: ожиданные и неожиданные. Последние делают жизнь интересной, но ужасной [смеется]. Начинать надо с какого-то «зернышка» – seed compiler, который генерирует родной код. Единственный такой компилятор для Linux – это GCC, то есть начинать процесс нужно со сборки наших исходных текстов в нем. При этом мы (и не только мы, а все, кто занимается портированием) сразу же сталкиваемся с рядом неприятных проблем: стандарт языка C отдает некоторые вещи на откуп реализации. Например, если знаковость перечисления (enum) не указана, разработчик компилятора может выбрать ее по своему усмотрению и задокументировать. Разумеется, каждый делает это по-разному. В итоге одному из наших товарищей пришлось изготовить специальную версию GCC, которая бы вела себя в этом смысле как компиляторы Sun, то есть (в данном примере) поддерживала ключ -fsigned-enum. Дальше, у нас есть оптимизирующий кодогенератор и не оптимизирующий. Первым делом был портирован последний – это сравнительно простая программа. В итоге у нас получился компилятор C, который «вытянул» остальной C-мир. Ну а потом мы долго-долго возились с C++. С тех пор я еще больше недолюбливаю C++.

LXF: Вот как? Кстати, а как обстоят дела с совместимостью компиляторов C++ из Sun Studio и GCC?

АГ: Смотря что вы имеете в виду. Подозреваю, что речь идет о двоичных интерфейсах (ABI) – здесь есть недоделки, но опять же Sun Studio 12 Update 1 обещает большие положительные сдвиги в данном направлении.

LXF: Остался последний вопрос, который мы, как сторонники свободного ПО, просто не имеем права не задать: а планируется ли открыть исходные тексты Sun Studio?

АГ: Если вас интересует короткий ответ, то процесс идет. В сущности, все упирается в права на интеллектуальную собственность: части кода Sun Studio были получены от AT&T и других компаний. Мы не можем просто взять и выложить исходные тексты где-нибудь на sun.com – необходимо удостовериться, что при этом не будут ущемлены права третьих лиц. Для Solaris, например, на такую проверку кода ушло несколько лет. Сколько потребуется Sun Studio – поживем, увидим.