2 Сводка по четырём важнейшим программным проектам, осуществлённым в ESS
Производительность разбивается на два класса: для управляющих программ составляет около 600 слов на человека за год, для трансляторов — около 2200. Обратите внимание, что все четыре программы приблизительно одного размера, различие состоит в размере рабочих групп, продолжительности работы и количестве модулей. Что является причиной, а что — следствием? Была ли сложность причиной того, что для управляющих программ требовалось больше людей? Или же большее число модулей и человеко-месяцев обусловлено большим числом людей, привлечённых к работе? Была ли большая продолжительность выполнения вызвана сложностью проблем или многочисленностью занятых людей? Трудно сказать с уверенностью. Конечно, управляющие программы были более сложными. Если оставить в стороне эти неопределённости, то цифры описывают реальную производительность при создании больших систем, и потому представляют ценность.
На рисунках 8.3 и 8.4 показаны некоторые интересные данные о фактической скорости программирования и отладки в сравнении с прогнозом.
Данные OS /360
Опыт OS/360 подтверждает данные Харра, хотя данные по OS/360 не столь подробны. В группах разработки управляющей программы производительность составила 600-800 отлаженных команд в год на человека. В группах разработки трансляторов производительность достигла 2000-3000 отлаженных команд в год на человека. При этом учитывается планирование, тестирование компонентов, системное тестирование и некоторые затраты на поддержку. Насколько я могу судить, эти данные согласуются с результатами Харра.
Рис. 8.3 Предсказанная и фактическая скорость программирования
Рис. 8.4 Предсказанная и фактическая скорость отладки
Данные Арона, Харра и OS/360 дружно подтверждают резкие различия в производительности в зависимости от сложности и трудности самой задачи. В работе оценивания сложности я придерживаюсь той линии, что компиляторы втрое хуже обычных пакетных прикладных программ, а операционные системы втрое хуже компиляторов. [35]
Данные Корбато
Данные Харра и OS/360 относятся к программированию на языке ассемблера. Есть немного публикаций относительно производительности системного программирования с использованием языков высокого уровня. Корбато (Corbato) из проекта MAC Массачусетского технологического института сообщает о средней производительности 1200 строк отлаженных операторов PL/I на человека в год при разработке операционной системы MULTICS (от 1 до 2 миллионов слов). [36]
Это число очень вдохновляет. Как у других проектов, MULTICS включает в себя управляющие программы и языковые трансляторы. Результатом также является системный продукт, отлаженный и документированный. Данные кажутся сравнимыми в отношении видов исполненной работы. А производительность повышается до средней величины между управляющими программами и трансляторами в других проектах.
Но Корбато указывает количествострокза год на человека, а неслов ! Каждому оператору в его системе соответствует от трех до пяти слов кода, написанного вручную! Из этого можно сделать два важных вывода:
• Производительность, измеренная в элементарных операциях, оказывается постоянной, что кажется разумным, если учитывать, сколько времени нужно думать над оператором, и сколько ошибок может в нём быть. [37]
• При использовании подходящего языка высокого уровня производительность можно повысить в пять раз. [38]
Глава 9
Два в одном
Автору стоит присмотреться к Ною и… поучиться на примере Ковчега, как в очень маленькое пространство втиснуть очень много.
СИДНЕЙ СМИТ, «ЭДИНБУРГСКОЕ РЕВЮ»
Размер программы как стоимость
Какова стоимость программы? Если не считать времени выполнения, то помять, занимаемая программой, составляет главные издержки.
Это верно даже для собственных разработок, когда пользователь платит автору существенно меньше, чем стоит разработка. Возьмём интерактивную систему IBM APL. Плата за её использование составляет $400 в месяц. При работе она требует не меньше 160 Кбайт памяти. У машины Model 165 ежемесячная аренда 1 Кбайта памяти стоит около $12. Если пользоваться программой круглосуточно, то месячная плата составит $400 за пользование программой и $1920 за память. Если пользоваться системой APL лишь четыре часа в день, то месячная плата составит $400 за пользование программой и $320 за использование памяти.
Нередко можно встретить человека, выражающего ужас по поводу того, что в машине, имеющей 2 Мбайт памяти, под операционную систему может быть отведено 400 Кбайт. Это столь же глупо, как ругать Боинг-747 за то, что он стоит 27 миллионов долларов. Надо же спросить: «А что она делает?» Какую, собственно, простоту в использовании и производительность (посредством эффективного использования системы) получаешь за потраченные деньги? Нельзя ли вложенные в аренду памяти $4800 в месяц израсходовать с большей пользой — на другие аппаратные средства, программистов, прикладные программы?
Проектировщик системы отводит часть всех аппаратных ресурсов программам, резидентно находящимся в памяти, если считает, что пользователю это нужнее, чем сумматоры, диски и т.д. Нельзя критиковать программную систему за размеркак таковой , и в то же время последовательно пропагандировать тесную интеграцию проектирования аппаратного и программного обеспечения.
Поскольку размер определяет значительную долю того, во что обходится пользователю системный программный продукт, изготовитель должен планировать размер, контролировать его и разрабатывать технологии, уменьшающие размер, подобно тому, как изготовитель аппаратной части планирует количество деталей, контролирует его и разрабатывает методы сокращения количества деталей. Как и для всякой цены, плох не большой размер как таковой, а размер, не вызываемый необходимостью.
Управление размером
Для менеджера проекта управление размером является отчасти технической, отчасти административной задачей. Чтобы устанавливать размеры предлагаемых систем, необходимо изучать пользователей и используемые ими приложения. Затем системы должны разлагаться на компоненты, для которых определяются проектные размеры. Поскольку варьировать соотношением скорости и размера можно лишь достаточно большими скачками, планирование размера является непростым делом, требующим знания возможных компромиссов для каждой части. Опытный менеджер сделает себе также «заначку», которую можно будет использовать в процессе работы.
Все же при работе над OS/360 пришлось извлечь несколько горьких уроков, несмотря на то, что все описанные меры были приняты.
Прежде всего, недостаточно установить размер памяти, нужно взвесить размер со всех сторон. Большинство прежних операционных систем размещалось на магнитных лентах, и большое время поиска на ленте не располагало к частой загрузке программных сегментов. OS/360 располагалась на диске, как и её непосредственные предшественники — операционная система Stretch и дисковая операционная системы 1410-7010. Её создатели получили свободу лёгкого обращения к диску. Первоначально это обернулось катастрофой для производительности.
При определении размеров памяти компонентов мы не установили одновременно бюджетов доступа. Как и следовало ожидать, программист, выходивший за рамки определённой ему памяти, разбивал программу на оверлеи. В результате и суммарный размер увеличивался, и выполнение замедлялось. Хуже то, что наша система административного контроля не смогла это обнаружить.