Редкая профессия

Последняя часть тирады была блефом. Мы не могли себе представить, что в Москве найдется для нас работа, связанная с созданием компиляторов, а делать что-то еще крайне не хотелось (см. начало статьи). На самом деле компилятор занимал все наши мысли, только с ним мы связывали все наши дальнейшие перспективы, так что переключиться на что-то иное было почти невозможно. Понятия же "рабочего времени" для нас давно не существовало — рабочим было почти все время, свободное от сна и от принятия пищи.

Никакого содержательного ответа мы не получили. Вальтер выслушал нас молча, лишь иногда понимающе кивал. Потом спросил: "Какова примерно зарплата программиста в Москве?" Мы назвали сумму. Он последний раз кивнул и замолк. Разговор закончился.

Следующие дни мы обсуждали технические аспекты проекта. Казалось, он был доволен состоянием компилятора и тем, что в конце тоннеля, наконец, стал виден свет. К больному вопросу мы не возвращались. Его отношение к нашему демаршу так и осталась загадкой. То ли это не входило в его компетенцию, и давать какие-либо обещания он просто не имел права? Или что-то мы должны были понять сами, без каких-либо объяснений? Кое-что прояснилось позднее, но тогда было от чего впасть в недоумение. Как бы то ни было, мы попали в дурацкое положение. Получилось, будто между нами произошел следующий диалог:

— Будете платить? — Нет. — Ну ладно, тогда мы будем работать бесплатно.

Как отремонтировать подгнивший дом

Вскоре после того, как компилятор "задышал" и приобрел относительную стабильность, мы стали систематически проводить его профилирование. GNU'шная программа gprof выдавала длинные таблицы временных затрат отдельных функций, по этим таблицам мы рисовали огромные, на несколько листов, графы реальных взаимосвязей модулей, пытаясь найти резервы быстродействия. Первый же анализ показал, что около 40% времени тратится на операции со строками и библиотечные функции ввода-вывода. Сначала это показалось естественным — любая идентификация именованного объекта в программе предполагает сравнение имен. Поиск имени в таблицах — одна из базовых операций в любом компиляторе, и даже используя технику хеширования, избежать прямого литерального сравнения идентификаторов невозможно. Однако цифра показалась нам все же чрезмерно большой. Исправить положение без разрушения компилятора было крайне сложно, так как всевозможные операции с именами буквально пронизывали все модули. Это не являлось проектной ошибкой — полностью локализовать работу с именами невозможно, так как сама семантика языка определяет необходимость оперировать с именами практически на всех стадиях компиляции.

Известно, что у деревянного бревенчатого дома обычно первыми подгнивают нижние венцы, имеющие постоянный контакт с почвенными водами. Чтобы отремонтировать подгнивший дом, вовсе не обязательно раскатывать его по бревнышку. Делают так: определяют самый нижний здоровый венец, подводят под него домкраты (под каждый из четырех углов) и немного приподнимают ими весь дом. После этого заменяют отслужившие бревна новыми и опускают на них верхнюю часть.

Точно по такой же схеме обошелся с компилятором мой коллега. Он "вынул" из него старую схему хранения имен и заменил ее на усложненную, но более эффективную. Ключевой момент новой схемы состоял в обеспечении присутствия каждого имени в семантических таблицах в единственном экземпляре. Тогда вместо сравнения литеральных изображений имен достаточно было сравнивать указатели на эти представления. Алгоритмы модулей, использующих операции с именами, никак не изменились, однако в некоторых местах пришлось заменить тип IDENT, представляющий "старый" идентификатор в таблицах, заменить на xIDENT — прямой указатель на единственную копию данного имени. Эту операцию можно было бы сделать одной командой контекстной замены, но никакой редактор не смог бы разобраться, где именно следовало ее производить, а где — оставить по-старому… В очередной раз мы "руками" перещупали весь компилятор. После четырех дней непрерывного труда компилятор разогнался на 25% (наглядная стоимость литеральных сравнений строк в большой программе)!

Фрагмент модуля с усовершенствованной версией обработки имен с тех пор украшает комментарий:

/* Krotoff is a _very_ clever guy! */

Товарища не похвалишь, так и он тебя не похвалит.

Последнее прости

Последние месяцы мы работали, не получая от фирмы вообще ничего, кроме писем. Постепенно ситуация с отсрочками платежей начала проясняться. У фирмы возникли финансовые затруднения. В подробности нас не посвящали, но они были, похоже, достаточно серьезными. Компания применила радикальный, но, видимо, стандартный метод выживания в подобных условиях — разделение, при котором убыточные подразделения выделяются в самостоятельные (дочерние) фирмы.