13. Фрэн Аллен

13. Фрэн Аллен

В 1957 году Фрэн Аллен собиралась стать учителем математики, но поскольку ей нужны были деньги, чтобы выплатить кредиты на обучение в университете, она временно (как тогда казалось) устроилась программистом в исследовательский центр IBM. Началом ее деятельности стало преподавание ученым IBM недавно созданного языка Фортран.

Учителем Аллен так и не стала - она проработала в IBM 45 лет и занималась рядом проектов по созданию компиляторов, в том числе компиляторов для компьютера STRETCH-HARVEST и для грандиозного, но так никогда и не законченного суперкомпьютера ACS-1. Кроме того, она работала над собственным проектом PTRAN, в рамках которого были разработаны технологии автоматической параллелизации программ на Фортране и создана система промежуточного представления SSA (Static Single Assignment), которая сейчас широко используется как в статических, так и в динамических (ЛТ) компиляторах.

В 2002 году Аллен была удостоена премии Тьюринга “За новаторский вклад в теорию и практику технологий оптимизационных компиляторов”, став, таким образом, первой женщиной, получившей эту награду, за 40 лет существования премии. Кроме того, она стала первой женщиной, удостоенной звания действительного члена научного общества IBM - высшего почетного звания в компании для технического сотрудника. Кроме того, она является почетным членом научного общества Института инженеров электротехники и электроники (IEEE) и Ассоциации вычислительной техники (АСМ), а также членом Национальной академии инженерных наук, Американской академии искусств и наук и Американского философского общества.

На протяжении всей своей карьеры Аллен видела, как менялась роль женщины в сфере информационных технологий - от первых лет, когда компании, вроде IBM, нанимали именно женщин на новую и непонятную должность “программиста”, до последних десятилетий, когда в этой области стали преобладать мужчины.

В беседе мы обсудили особенности этих изменений, необходимость предоставления равных возможностей в сфере информационных технологий и пагубное влияние, которое язык Си оказал на компьютерные науки.

Сейбел: Как вы начали заниматься программированием? Я знаю, что в начале вы собирались стать учителем математики, но устроились на работу в IBM, потому что вам нужно было погасить кредиты на учебу.

Аллен: Для того чтобы получить лицензию учителя в штате Нью-Йорк, нужна была степень магистра. У меня были степень бакалавра по математике, вторая специальность - физика и двухлетний опыт преподавания. Затем я поступила в университет штата Мичиган, где углубилась в изучение математики. Для того чтобы получить степень магистра в университете Мичигана, нужна была вторая дополнительная специальность - и я выбрала вычислительные системы. Компьютерных наук тогда, в 1957 году, еще не было. Лишь 10 лет спустя они всерьез заявили о себе. Но в инженерной школе было несколько курсов.

Сейбел: Что вы там изучали?

Аллен: Там был компьютер IBM 650 - он весьма отличался от привычных нам сегодня компьютеров, и студенты учились на нем программировать. Это включало не только изучение всех свойств компьютера и написание кода - на ассемблере, естественно, - но и запуск своих программ на компьютере. Результат был абсолютно наглядным.

Сейбел: То есть вы набивали перфокарты, сами несли их к компьютеру и пропускали через него?

Аллен: Верно. А потом шли и исправляли. Это была машина с магнитным барабаном - барабан постоянно вращался, на нем и были записаны твои инструкции. Поэтому, чтобы все работало быстро, нужно было рассчитывать положение программ на барабане таким образом, чтобы при каждом новом обороте каждая новая программа располагалась на нужном месте.

Сейбел: А потом появились агенты по найму из IBM. Чем вас привлекла работа на IBM?

Аллен: Если честно, мне просто нужна была работа. У меня были долги, агент пришел прямо в кампус, и располагались они удачно - в штате Нью-Йорк. Так что я заполнила анкету, на самом-то деле толком не понимая, что за организация предлагает мне работу, что это за исследовательский центр IBM. Я тогда о них ничего не знала.

Несколько недель спустя мне позвонили - в то время я пыталась устроиться на работу в педагогический колледж в южном Иллинойсе. Я уже начинала отчаиваться - все никак не могла найти работу. Мне позвонили, когда я была в пути, и я согласилась - ровно ничего не зная о компании, и только заполняя бумаги выяснила, что речь идет об исследовательской лаборатории в Пафкипси.

Я устроилась туда и начала работать программистом. Компания IBM стремительно расширялась, их интересовала сфера информационных технологий, а поскольку не существовало никаких курсов по компьютерным наукам, то они нанимали людей отовсюду, откуда могли.

Сейбел: Чему вас там обучали?

Аллен: Насколько помню, это было своего рода обучение на ходу. Существовала определенная ориентация на нужды компании, но не могу припомнить, чтобы там были курсы по изучению программирования как таковые, что сейчас кажется немного странным. Кажется, были курсы, специфика которых зависела от подготовки того или иного сотрудника. Все проходило в очень неформальной обстановке.

Поскольку я была учителем математики, моим первым заданием стало обучение исследователей и других программистов языку Фортран. Я устроилась на работу в июле 1957 года, а Фортран был выпущен 15 апреля того же года. В моей же организации - исследовательском центре IBM - был выпущен указ, согласно которому к сентябрю все программы должны были писаться на Фортране. Это был их метод убедить собственных сотрудников - как и людей вне компании - использовать этот язык.

Сейбел: То есть речь идет об исследователях, работавших в IBM над собственными научными проектами?

Аллен: Да. У них был компьютер 704 - именно для работы на нем и был создан и оптимизирован Фортран. Они привыкли, что код на ассемблере можно было писать прямо на компьютере, то есть так же, как я делала в университете Мичигана, привыкли планировать время и запускать программы. Они не верили, что с помощью любого из высокоуровневых языков можно будет получать результаты, хотя бы сравнимые с получаемыми при программировании непосредственно самого компьютера.

Сейбел: И это был последний раз, когда ученые перешли на новый язык, - ведь они до сих пор используют Фортран, не так ли?

Аллен: Верно. Да, это был неудачный курс. Но в конце концов это был прекрасный опыт для всех нас, ведь Фортран был не только языком - в рамках этого проекта был разработан чрезвычайно передовой компилятор, который заложил структурные основы современных компиляторов.

Сейбел: Следующий ваш крупный проект, о котором я знаю, - это компьютер Stretch. Было ли что-нибудь в промежутке между этими двумя проектами?

Аллен: Да, были еще два проекта, над которыми я работала после Фортрана и перед компьютером Stretch. Один из них - разработка управляемой автоматической отладочной системы на ассемблере для компьютера 704. Мне очень нравилось работать над этим проектом.

Это была весьма незрелая операционная система. Мы ее делали втроем. Мы установили на компьютере несколько кнопок - тогда это можно было сделать, - одной из которых была аварийная кнопка. Когда казалось, что программа зависла, можно было просто нажать эту кнопку. Затем мы писали отладчик; одной из моих задач было написать на ассемблере программу, которая бы располагала двоичные данные по колонкам. Устройство считывания с перфокарт представляло данные в виде построчного двоичного кода, когда биты каждой инструкции располагаются в строке, но на ленте данные представлялись по-другому. Вот и требовалось организовать поколонное двоичное представление. Эту программу я храню до сих пор.

Среди прочего я с большим удовольствием вспоминаю чтение исходной программы - мне она показалась весьма изящной. Мне это запомнилось, потому что эта выдающаяся программа была написана не очень опытным на тот момент программистом - Роем Наттом. Она была прекрасна.

Сейбел: Что делает программу прекрасной?

Аллен: Она должна представлять собой простое прямолинейное решение поставленной задачи; при достаточно сложной структуре эта очевидность не вытекает непосредственно из поставленной задачи. Наверное, именно тогда я приобрела привычку учиться программированию и изучать новый язык посредством чтения и подробного изучения готовых программ,

Сейбел: Как вы читаете код? Предположим, собираясь изучить новый язык, вы находите готовую программу - и что с ней делаете?

Аллен: Ну, например, однажды один из моих сотрудников написал парсер. Это уже было в рамках проекта PTRAN. Мне хотелось понять его методы. Это, пожалуй, лучший парсер в мире (сейчас он есть в открытом доступе), действительно превосходный - он умеет исправлять ошибки на лету.

Мне хотелось понять его, поэтому я взяла и прочитала его. Я знала, что автором программы был прекрасный программист Филипп Чарльз. Для того чтобы понять новый язык или новую реализацию какой-либо весьма сложной задачи, я беру программу, написанную программистом, в чьей компетенции не сомневаюсь, и читаю ее.

Сейбел: Как вы изучаете фрагмент кода подобной программы? По шагам? Или просто читаете от начала и до конца, строя в уме структуру? Достаточно непростая задача.

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

Сейбел: Есть ли у вас любимые истории, связанные с устранением неполадок в программах?

Аллен: Было несколько интересных случаев. Один из них произошел во время моей работы над системой MAD. Оператор машины позвонил мне посреди ночи - программу, которая должна была быть запущена на всю ночь, никак не удавалось запустить. У нас был особый способ автоматического подсчета контрольной суммы для проверки корректности данных, ведь сами машины толком не отслеживали и не исправляли ошибки. Говоря по телефону, я не могла сообразить, в чем ошибка. Но чуть позже вдруг поняла: в написанной мною части системы, отвечавшей за подсчет контрольной суммы, не учитывалась одна конкретная ситуация. Даже если программа исполнялась корректно, она не могла преодолеть этот барьер - из-за того способа, которым я осуществляла подсчет контрольной суммы. Я перезвонила оператору, и мы устранили эту неполадку.

Другой случай - его я запомнила, поскольку была очень довольна собой тогда, - был связан с одним моим коллегой, который тоже работал над Stretch, предпочитая делать это по ночам. Однажды он пришел утром, а вида он был внушительного - гигантского роста, очень серьезный. И бросил мне на стол распечатку отладочной информации - дампа программы - огромную, толстую стопку. Указывает мне на один какой-то бит в распечатке и говорит: “Почему этот бит установлен?” Он переживал всю ночь. Как ни странно, я знала ответ на его вопрос. Это не было неполадкой - просто он не знал, что это, и решил, что именно этот бит был причиной ошибки.

Сейбел: Это случилось позже - вы говорили, что был еще один проект между MAD и Stretch.

Аллен: Да. Это был проект для одного ученого, который делал коммутационные схемы для аппаратного оборудования. Среди прочего он размещал схемы на том, что тогда считалось микросхемами. Мы разрабатывали математическое решение - было множество препятствий, конечно же, из-за физических размеров. Я работала над этим проектом в качестве программиста. Нас было двое, может быть, трое - все женщины.

Сейбел: А затем вы приступили к работе над проектом и весьма крупным - Stretch.

Аллен: Благодаря моему опыту работы с Фортраном и хорошему владению данным компилятором меня перевели из исследовательского центра IBM в очередной крупный проект компании - создание компьютера Stretch. Проект начался в 1955 году, а название Stretch появилось где-то в 1956 году; планировалось создать машину, которая работала бы в 100 раз быстрее любой другой машины, существовавшей тогда в мире: мы хотели создать абсолютно фантастический компьютер.

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

Сейбел: Из-за того, что работа с латентностью памяти стала бы слишком неподъемной задачей для программистов, писавших на ассемблере?

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

Это была чрезвычайно сложная машина - и программировать ее было сплошным удовольствием. Компилятор представлял собой очень трудную задачу. Весь проект был восхитительно сложным.

Поэтому меня и еще нескольких сотрудников перевели из исследовательского центра IBM в этот проект для разработки компилятора и непосредственно операционной системы. Компилятор по размаху соответствовал самой машине. Из-за того что ранее мне приходилось работать с оптимизатором Фортрана, здесь я работала над оптимизатором для Stretch, который позже назовут Stretch Harvest. Общий план компилятора был утвержден другим комитетом, но мы вчетвером отвечали за детали, включая интерфейсы компилятора, их спецификации и прочие его компоненты. У меня был оптимизатор, у кого-то парсер, распределитель регистров и интерфейс с программой ассемблера.

Сейбел: Как проект был организован с точки зрения функций, отведенных разным работникам?

Аллен: Три человека разрабатывали общий план компилятора - у нас будет парсер, у нас будет то, у нас будет это, а это мы поставим сюда. И были люди, отвечавшие за продукт целиком, то есть было несколько уровней, на которых осуществлялось принятие решений и руководство проектом.

Затем им понадобилось назначить ответственных за каждый из крупных компонентов. Поэтому они попросили нас четверых, причем трое были женщины, заняться этим и совместно начать разработку интерфейсов.

Сейбел: Были ли помимо вас программисты, занимавшиеся непосредственно реализацией проекта?

Аллен: Да. У меня была группа из 17 программистов.

Сейбел: Как происходил переход от этапа разработки к этапу написания кода? Вы вчетвером собрались и установили интерфейсы между компонентами системы. Это произошло до того, как ваши 17 программистов начали писать код, или процесс написания кода влиял и на общую концепцию в целом?

Аллен: Все происходило, по большому счету, само собой. Ограничения были установлены вышестоящим начальством. Главы отделов, вроде меня, отчитывались перед одним человеком - Джорджем Гровером, который, собственно, и разработал всю глобальную концепцию, особенности которой, в свою очередь, были продиктованы ограничениями у потребителей. Это была командная работа, часто вносились изменения и поправки - отчасти из-за того, что мы изобретали эту систему на ходу. Но был и срок сдачи проекта. Корпоративная субординация не так много значила, работа в команде была важнее.

Сейбел: Случалось ли, что код, написанный кем-то из ваших подчиненных, заставлял пересмотреть какие-либо решения более высокого уровня о взаимодействии компонентов системы?

Аллен: Да, иногда становилось понятно, что задуманный интерфейс не будет работать. Это была часть работы - следить за тем, как все получалось на практике. Мы встречались командой - вчетвером. Но большей частью каждый из нас работал над созданием доверенного ему компонента системы - в этом смысле была огромная свобода.

Разработка ПО как таковая появилась позже. В то время еще не существовало разработки ПО, не создавалось крупных процессов. В следующем проекте (компьютер 360, руководитель Фред Брукс), в котором я не была занята, с ПО были большие проблемы. Технически с 360 все пошло на лад где-то в 1963 году. И некоторые разработчики аппаратного обеспечения перестали заниматься компьютером: ничего не зная о ПО, они занялись им, поскольку оно пребывало в полном хаосе. Это был настоящий бардак.

После того как 360 был закончен, один специалист - не знаю, работал ли он над 360, - написал письмо боссам IBM, предлагая ввести некий ряд мер по улучшению разработки ПО Cleanroom. Он заявлял, что если следовать всем изложенным им предписаниям, то можно будет создавать идеальные программы. И из-за всего того, что руководство компании уже пережило, - по крайней мере, мне так кажется, - они на это купились.

Сейбел: Вы имеете в виду из-за того, что проект 360 был таким тяжелым?

Аллен: Именно. Таким образом, отдел разработки продукции IBM стал придерживаться процессов Cleanrooom - целого набора процессов. Например, постановкой целей и проектированием системы занимались разные группы. И проектировщики должны были продумать все до мельчайших деталей, чтобы программисты могли писать код в соответствии с разработанной концепцией. И эти группы не были открыты друг другу - вы просто делали все аккуратно и на выходе получали идеальное ПО.

Сейбел: Во время работы над проектом по созданию 360 Брукс отвечал и за программное, и за аппаратное обеспечение?

Аллен: Да, мне кажется, что он контролировал весь проект в целом. Но некоторых из глав ПО-отделов он заменил людьми с опытом создания аппаратного обеспечения. Разумный шаг, поскольку эти специалисты уже выработали прекрасную дисциплину вокруг создания “железа” - разработка микросхем, процесс тестирования и так далее. Это был более проверенный временем и традиционный метод разработки концепции. Мы - специалисты в ПО - все придумывали сами.

Сейбел: То есть вам кажется, что как минимум в рамках этого проекта внесенные ими в процесс разработки ПО изменения оказались спасительными?

Аллен: Этот шаг был абсолютно необходим, но разработчикам ПО было нелегко, когда все эти ребята, понятия не имевшие о ПО, пришли к ним и начали просто назначать проектные экспертизы, проектные спецификации и так далее.

Сейбел: Но все-таки эти изменения спасли проект. Это придало тем ребятам уверенности, и они сделали следующий шаг к процессу Cleanrooom - шаг, который оказался не слишком удачным?

Аллен: Мне кажется, да. Так все и было. Процесс Cleanrooom - “модель водопада” - во время представления руководству получил очень сильного защитника.

Сейбел: Этот защитник был из лагеря разработчиков аппаратного обеспечения?

Аллен: Нет, он был из разработчиков ПО. Но насколько я знаю, он не участвовал в проекте 360 и вряд ли хотел таким образом его спасти. И те из нас, кто уже имел кое-какой опыт работы в сфере ПО, были ошарашены некоторыми из произнесенных тогда заявлений. Но иногда громкие фразы говорят для того, чтобы что-то продать.

Сейбел: Вы когда-нибудь работали над проектом, в рамках которого применялся подобный процесс?

Аллен: О, да. И разочаровалась в нем, потому что на его ранних этапах проектировщик и программист не могли работать совместно. Одна из его проблем состояла - да и, пожалуй, состоит - в том, что жизненный цикл программы очень долог. В те времена для создания крупной программы требовались многие месяцы и даже годы. Менялась конъюнктура, менялись требования. И много значило мнение потребителя о том, что он хочет получить в результате.

Сейбел: И вы продвигали изменения по всей вертикали процесса? Или люди шли прямо к программистам: “В общем, мы поняли, заказчику нужен X”?

Аллен: Да. Никто не мог написать спецификации, которые соответствовали бы всем нормам и были бы полезны в отношении всех мелких деталей на протяжении всего жизненного цикла программы. В этом и заключалась проблема. Разумеется, сейчас мы работаем по другой схеме - просто сделай и выброси, что-то вроде того.

Сейбел: Ну, собственно, Брукс в своей знаменитой книге¹ и написал: “Планируйте выбросить первую версию - вам все равно придется это сделать”.

Ф. Брукс “Мифический человеко-месяц или Как создаются программные системы”. - СПб.: Символ-Плюс, 2000.

Аллен: Да. На самом деле, это правда - я в этом убеждена. Но зачастую это приводит, на мой взгляд, к тому, что мы не думаем перед тем, как начать делать программу.

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

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

Аллен: В каких-то случаях - формальные блок-схемы. Часто в ядре программы находились очень сложные фрагменты, и было необходимо составить подобную блок-схему. В остальном же речь о схемах второго типа - это был способ выработки решения задачи. Доска изрисовывалась целиком - и становилась своего рода архивом месяца или любого другого периода времени.

Сейбел: Итак, вы тогда возглавили крупный проект по созданию компилятора PTRAN; вы впервые стали работать с явным параллелизмом, а не со скрытым параллелизмом в конвейерах центрального процессора и так далее. Тогда это было в новинку - как для вас, так и для IBM.

Аллен: Это было новым веянием для IBM, но мы уже очень запаздывали. Огромная работа, открывшая реальную практическую выгоду в этом плане, началась в Иллинойсе в 1969 или в 1970 году.

Сейбел: Для какого языка предназначался компилятор PTRAN? Был ли это простой Фортран, без дополнительных конструкций для параллелизма?

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

Что касается PTRAN, то мы собирались использовать “пыльные колоды” (dusty decks), как мы их называли, то есть уже существующую базу кода, после чего автоматически задействовать предоставляемые железом параллельные компоненты.

Сейбел: То есть, по сути, речь шла о том, что сегодня мы называем симметричными мультипроцессорами?

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

Собственно, мы строили это на основе уже существовавших работ, в частности Дэйва Кука. Некоторые работы были из Нью-Йоркского университета. Мы наняли группу свежеиспеченных PhD из ряда мест, в которых уже к тому моменту был наработан определенный опыт. У нас было довольно много значительных результатов - и в практической, и в теоретической части; мы работали одновременно и над тем, и над другим. Я убеждена в том, что практика должна быть выражаемой в узнаваемых алгоритмах, в теории и способах представления решения задач, а алгоритмы должны применяться на практике, для того чтобы понять, насколько они ценны и как их применять. Я считаю, что в нашей области при работе над проектом лучше всего сочетать теорию и практику.

Сейбел: Во время работы над проектом PTRAN вы руководили командой. Вы тогда все еще писали код?

Аллен: Я не писала код, но была очень близка к этому. Например, когда работа по SSA-представлению была закончена, я не видела, каким образом оно может быть реализовано в какое-либо разумное время. То есть это был очень хороший алгоритм, но я не могла представить себе реализацию с разумными ограничениями по времени и по памяти. Соответственно это был для меня вызов. Мне нужно было видеть этот код. Он был необходим мне. Его следовало реализовать. Он не мог остаться на бумаге - только как очень хорошее, даже отличное исследование с графиками и ограничениями по сложности.

Если мы не можем реализовать его по-настоящему, то этот вызов останется. И проделанная работа будет не столь полезна, как мне хотелось. В конце концов один из моих подчиненных все запрограммировал. Я прочла программу целиком, изучила каждый фрагмент кода, проанализировала все использованные структуры данных. Это было потрясающе. Я сказала: “То что надо. Это работает”.

Сейбел: То есть вы просмотрели все фрагменты кода, которые должны были войти в систему?

Аллен: Да, да, да.

Сейбел: Вы также руководили всеми этими людьми? Или вы были просто главным техническим архитектором, а за руководство группой отвечал кто-то другой?

Аллен: Нет, я была научным руководителем группы. Было 10-12 основных сотрудников, и мы разделили всю работу таким образом, что каждый владел каким-то ее куском.

Сейбел: Как минимум начиная с выхода книги Джеральда Вайнберга “The Psychology of Computer Programming” (Психология программирования) не утихают споры, что лучше - когда кто-то один “владеет” кодом и соответственно отвечает за него или совместная работа, позволяющая избежать вещей, понятных только одному. Судя по всему вы решили, что оптимальным вариантом было разделить владение кодом?

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

В то время велась большая работа по анализу и трансформациям для параллелизма. Поэтому я пыталась сделать так, чтобы каждый специалист-теоретик написал какой-то фрагмент кода, выразил свои теоретические построения в коде как часть системы. А тех, кто занимался более практическими вещами, я старалась организовать так, чтобы они писали как можно доступнее для более широкого круга специалистов.

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

Аллен: В первые годы существования исследовательского центра не было разделения - руководящая должность вовсе не означала продвижения по карьерной лестнице, повышения оклада. Просто кому-то нужно было руководить разработкой вот этого отрезка работы, поэтому говорилось что-то вроде: “Не хочешь ли взяться за это?” или “Очевидно, этим должен руководить ты”. Это было техническое руководство - таких руководителей было немного. Но в исследовательском центре человек становится членом исследовательского центра (Research Staff Member, RSM) с момента прихода туда и практически до конца карьеры. Вот кем являемся мы с коллегами. Поэтому можно постоянно выдвигаться и уходить с руководящей должности - без какого-либо клейма.

Сейбел: Скорее всего, руководить доверят тому, кто хорошо с этим справляется. Как вы приобрели подобные навыки?

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

Сейбел: Одна из трудностей в техническом менеджменте, которым вы занимались, - уравновесить стремление самому направлять работу сотрудников и их желание думать самостоятельно.

Аллен: Как мне представляется, в рамках работы над проектом Stretch я получила ряд суровых уроков. Помню, однажды ко мне подошли несколько сотрудников проекта и сказали, что мы должны использовать списки и хеш-функции. Мы знали о списках, но хеширование было в новинку. И двое колллег говорят мне, что хотят использовать хеширование для таблицы символов. Я ответила: “Нет, мы не можем. Мы не знаем, как с этим работать”. Бла-бла-бла. В следующий понедельник я прихожу и вижу - они сделали это. Они снесли систему целиком и сделали ее заново, добавив туда хеширование. Это сработало, система начала работать намного быстрее. Это был важный урок для меня. Я должна быть более открытой для совершенно новых идей.

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

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

С серьезной проблемой такого рода я столкнулась, выполняя какой-то проект по договору субподряда. У меня была группа специалистов, прекрасно справлявшихся с созданием оптимизатора на основе нашей же работы, которую мы проделали для ПЛ/1 - громоздкого, очень прихотливого языка. Но кто-то из работников субподрядчика, недавно открыв для себя объектно-ориентированное программирование, решил применить его здесь по полной. Я не смогла ему помешать, даже несмотря на то, что отвечала за контракт, и проект был загублен. Грубо говоря, проблема была в том, что в ПЛ/1 множество указателей, и каждый указатель постоянно отслеживался; а чтобы отслеживать значение, то есть находить значение по указателю, требовалось 11 инструкций.

Сейбел: То есть в уже сгенерированном коде.

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

Сейбел: Какие продукты для IBM, в разработке которых вы принимали участие, имели сроки сдачи, в которые надо было уложиться?

Аллен: Безусловно, здесь нужно упомянуть проект Stretch. Кроме того, я участвовала в разработке продукта еще 2-3 раза, с еженедельными ревизиями кода незадолго до сдачи проекта. Я с большим уважением отношусь к этим процессам, считаю их очень важными для конечного результата и для команды, работающей над проектом. Хотя это может быть очень утомительным - каждую пятницу садиться читать код, слушая объяснения, почему сделано так-то и так-то, и находить ошибки других.

Сейбел: Это утомительно, но стоит того?

Аллен: Безусловно, стоит. Во время работы над проектом PTRAN, ближе к завершению, мы включали фрагменты кода в другие продукты, полдня уходило на объяснение ошибок в нашем коде, их коде, неважно, - и так каждую неделю, около 10 месяцев. Полпятницы уходило на это.

Сейбел: Работая в подобных условиях, вы ощущали, что у вас есть процесс, позволяющий достаточно точно рассчитать время, необходимое для создания определенного объема ПО?

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

Сейбел: На что вы обращали внимание, нанимая сотрудников?

Аллен: У меня было множество связей в университетах. В Нью-Йоркском университете был прекрасный факультет, где программистов учили писать компиляторы; эти ребята действительно хорошо писали компиляторы.

Сейбел: То есть можно нанять человека, рекомендованного вам профессором, которого знаешь и которому доверяешь. А если проводишь собеседование с тем, у кого нет солидной рекомендации, - как за несколько часов понять, станет человек хорошим программистом или нет?

Аллен: Я всегда начинала собеседование с претендентом на место в исследовательском центре IBM, пытаясь понять, что этого человека интересует в жизни. Для меня это был своего рода пороговый уровень. Было абсолютно не важно, имело ли это увлечение какое-то отношение к программированию или компьютерам. Если человек не может ни чем увлечься, то не будет выкладываться по полной, работая в группе.

Иногда приходится идти на большой риск. Однажды я серьезно рискнула, взяв на работу парня, хотя его научный руководитель написал мне, что тот страдает тяжелой формой дислексии. В IBM у него работа не заладилась, но после он основал собственную компанию, и я до сих пор обращаюсь к нему за советами, за рекомендациями по поводу технической реализации определенных идей. Он просто знает эти вещи. То есть то решение не было ошибкой. Оно было ошибкой для того проекта, но не в смысле его отношений со многими из нас.

Сейбел: В дальнейшем вы стали заниматься наставничеством - IBM даже присуждает премию лучшему наставнику, названную в вашу честь. Как сделать, чтобы неопытные программисты становились более квалифицированными программистами?

Аллен: Я и сейчас не очень-то понимаю, что такое наставничество. Главное - нужно посоветовать начинающему специалисту не занимать слишком рано руководящую должность, что весьма соблазнительно для тех, у кого есть соответствующие таланты. Для начала нужно заработать репутацию своей технической работой. Какая-то интересная научная работа, алгоритм, отлично написанный код - что угодно; сначала нужно заработать себе репутацию чем-то подобным. Это сослужит вам хорошую службу, если вы действительно хотите руководить проектами, понимая в деталях, что требуется для выполнения той или иной работы.

Сейбел: Возможно ли вообще быть хорошим руководителем, не имея выдающихся технических способностей, а просто умея хорошо координировать работу других?

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

Сейбел: Это, наверное, самое сложное. Как по-вашему, чем отличается по-настоящему хороший программист?

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

Кроме того, я опираюсь на мнение других. Я часто ошибаюсь, и бывает очень познавательным обнаружить, что думаешь о специалисте намного лучше, чем остальные участники коллектива. Если у вас хорошая группа, то прислушиваться к мнению ее участников - очень эффективный способ узнать, кто хорошо справляется со своей работой.

Сейбел: Можете ли вы сказать, когда последний раз программировали?

Аллен: О, довольно давно. Наверное, я прекратила писать код, когда появился язык Си. Это был серьезный удар. Мы так успешно работали над оптимизациями и трансформациями. Мы решали одну непростую задачу за другой. После появления Си на одной из конференций, посвященных компиляторам SIGPLAN, случился спор между Стивом Джонсоном из Bell Labs, который поддерживал Си, и моим сотрудником Биллом Харрисоном, участником одного из моих тогдашних проектов, который поддерживал автоматическую оптимизацию.

В частности, во время этого спора Стив говорил, что больше не нужно создавать оптимизаторы, потому что теперь обо всем позаботится сам программист. Что это, на самом деле, задача программиста. Стимулом к созданию языка Си послужили три проблемы, которые невозможно было разрешить в рамках высокоуровневых языков. Первая - управление прерываниями. Вторая - распределение ресурсов, возможность перехватить управление и передать его следующему процессу в очереди. Третья - распределение памяти. Ничего из этого нельзя было решить с помощью высокоуровневого языка. Что и стало поводом для появления Си.

Сейбел: Как вы считаете, с существованием языка Си можно было бы смириться, ограничив его применение ядром операционной системы?

Аллен: О, да. Это было бы прекрасно. Действительно, нечто подобное нужно, чтобы эксперты могли бы проводить действительно тонкую настройку без особых препятствий, ведь решение этих проблем действительно очень важно.

К 1960 году у нас было множество прекрасных языков: Лисп, APL, Фортран, Кобол, Алгол 60. Это языки более высокого уровня, чем Си. С момента появления Си мы серьезно деградировали. Си уничтожил нашу способность прогрессировать в автоматической оптимизации, автоматической параллелизации, автоматическом отображении языков высокого уровня в машинную архитектуру. Это одна из причин, по которым компиляторы, по сути, больше не изучаются в колледжах и университетах.

Сейбел: При том что курсы по созданию компиляторов определенно читаются?

Аллен: Не во многих университетах. Это ужасно. До сих пор проводятся конференции, создаются хорошие алгоритмы, проводятся хорошие исследования, но отдача, по моему мнению, абсолютно минимальна. Все из-за того, что языки вроде Си слишком уж локализуют решение проблем. Подобные языки - вот что уничтожает компьютерные науки как предмет.

Сейбел: Но большинство современных новейших языков - более высокого уровня, чем Си. Например, Java, C#, Python и Ruby.

Аллен: Да, но они все равно излишне локализуют решение. Суть в том, что они точно указывают местонахождение данных. Если вы посмотрите на упомянутые мною языки (Лисп, APL, Фортран, Кобол, Алгол 60), то они не указывали местонахождение данных и как их перемещать, где их размещать в компьютере. В конечном итоге ключевым является значение данных в любой момент.

Сейбел: Но лишь немногие языки, вроде Си или C++, по-прежнему используют указатели в чистом виде. В Java есть сборка мусора, и данные перемещаются. По-вашему, это тоже излишняя локализация?

Аллен: Да. Я убеждена, что есть возможность сделать с данными то же самое, что мы сделали с вычислениями в мире оптимизации. Мы не очень хорошо умеем управлять данными. У нас нет хороших методов автоматического управления данными - установления местонахождения данных, которые будут использоваться совместно.

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

Сейбел: Вся ваша профессиональная деятельность во многом была связана с высокопроизводительными вычислениями. Однако, скажем, к 2019 году у каждого ноутбука будет 1000 ядер. Будет ли это означать, что создание высокопроизводительных и пользовательских компьютеров станет одним и тем же? Или с высокопроизводительными вычислениями все всегда будет совсем не так, как везде?

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

Поможет решению этих задач и соревновательный элемент. Но использование этого множества ядер переводит проблему из области аппаратного обеспечения в сферу ПО, где, как мне кажется, мы не готовы ни к какому прогрессу. Использовать эти ядра - вот задача, которую нужно решать новым уровням языков. Нам нужно полностью исследовать эту проблему. Но для этого необходимо радикально новое мышление.

Думаю, за эти первые 50-60 лет (ENIAC появился в 1943 или 1944 году) мы создали не только превосходное, восхитительное - просто потрясающее - наследие, но и несколько вещей, от которых нужно избавляться. Чтобы их заменить, потребуется очень много времени, и, думаю, трудно предсказать, как все это будет развиваться. Но это развитие пойдет очень быстрыми темпами, если мы сможем применить новое мышление в нужных местах. Мы знаем, как проводить вычисления на большом объеме данных, но мы понятия не имеем, каким образом передать данные на вычислительные элементы компьютера.

Сейбел: Вы можете привести простой пример того, что понимаете под передачей данных на вычисление - в противоположность тому, что мы сегодня знаем, как делать?

Аллен: Для меня это означает собственноручно управлять данными. По сути, сегодня мы это делаем с помощью ссылок - они передаются посредством аппаратного обеспечения или фундаментальными операционными системами и системами поддержки. Зачастую эти ссылки располагаются на самом базовом уровне.

Сейбел: В том смысле, что возможен указатель внутрь структуры или массива?

Аллен: Да, на его элемент. После чего значение передается - в зависимости от протоколов аппаратного обеспечения или самой архитектуры - туда, где оно может быть использовано как часть вычислительного процесса.

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

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

Сейбел: В своей лекции после получения премии Тьюринга вы сказали что-то вроде: “Мы на распутье, и мы можем этого не заметить. Мы можем пойти не той дорогой и идти по ней достаточно долго”.

Аллен: Да.

Сейбел: А верная дорога, по-вашему, - это вернуться к работе над автоматической параллелизацией?

Аллен: Да, но мы должны заниматься этим с учетом известных сегодня высокоуровневых языков.

Сейбел: А неверная дорога - это поиск лучших путей явного использования параллелизма?

Аллен: Да, думаю, в конце концов мы таким образом лишь усугубили свои проблемы.

Но нам нужны языки более высокого уровня, и, конечно, есть языки, отражающие специфику конкретной предметной области, и есть действительно превосходные методы разработки.

Но мы должны захотеть использовать и эти наработки, и интеграцию систем, не забывая тот факт, что данные поступают отовсюду. Они больше не инкапсулированы внутри программы, кода. Сейчас мы видим немыслимо огромные массивы данных, которые стали доступными. Это цифровые и информационные данные, и они хранятся - и будут храниться - по всему миру, особенно если вы занимаетесь чем-то вроде биоинформатики. И нам нужно создать платформу, возможно, состоящую из множества частей, которая позволит соединить все эти вещи; для этого потребуются, вероятно, совсем другие вычислительные мощности. И рано или поздно нам придется решать проблемы удобства использования и цельности этих систем.

Сейбел: Вы говорите об удобстве для программиста или для конечных пользователей этих систем?

Аллен: Для пользователей. Это ресурс, гигантский ресурс. Также важна цельность корректности этих систем. Не так давно я работала над одним проектом по управлению рисками для Агенства национальной безопасности, и до меня вдруг дошло, что зачастую в высокопроизводительных вычислениях не нужны вычисления со всей возможной точностью. Не нужно использовать все данные, чтобы добиться прогресса в решении задачи. И поэтому в сфере изучения данных проводятся неплохие исследования, как мне кажется, с достаточно неплохими результатами, которые всех устраивают. Многоядерные компьютеры представляются мне прекрасной возможностью по-новому взглянуть на многое.

Сейбел: Кем вы себя ощущаете - ученым, инженером, художником или ремесленником?

Данный текст является ознакомительным фрагментом.