60
лентах, и большое время поиска на ленте не располагало к частой загрузке
программных сегментов. OS/360 располагалась на диске, как и ее непосредственные
предшественники — операционная система Stretch и дисковая операционная
системы 1410-7010. Ее создатели получили свободу легкого обращения к диску.
Первоначально это обернулось катастрофой для производительности.
При определении размеров памяти компонентов мы не установили одновременно
бюджетов доступа. Как и следовало ожидать, программист, выходивший за рамки
определенной ему памяти, разбивал программу на оверлеи. В результате и
суммарный размер увеличивался, и выполнение замедлялось. Хуже то, что наша
система административного контроля не смогла это обнаружить. Каждый
программист сообщал, сколько памяти он использовал, и так как он укладывался в
задание, никто не беспокоился.
К счастью, вскоре настал день, когда заработала система моделирования
технических характеристик OS/360. Первые результаты показали наличие серьезных
проблем. Моделирование компиляции с Fortran H на машине Model 65 с барабанами
дало результат пять операторов в минуту! Анализ показал, что все модели
управляющей программы делали множество обращений к диску. Даже интенсивно
используемые модули супервизора часто обращались к диску, и результат по звуку
весьма напоминал шелест перелистываемой книги.
Первая мораль ясна: планировать нужно как размер резидентной части, так и общий
размер. Помимо планирования этих размеров нужно планировать и количество
обращений к диску для обратной записи.
Второй урок был аналогичен. Ресурсы памяти устанавливались прежде, чем для
каждого модуля было определено точное распределение памяти для функций. В
результате каждый программист, не укладывавшийся в размеры, искал, что из его
кода можно выкинуть через забор в память соседу. Поэтому буфера управляющей
программы стали частью памяти пользователя. Что хуже, так же поступали все
управляющие блоки, и в результате были полностью скомпрометированы
безопасность и защита системы.
Поэтому второй вывод тоже совершенно ясен: при задании размера модуля нужно
точно определить, что он должен делать.
И третий, более серьезный урок, который нужно извлечь из этого опыта. Проект был
слишком велик, а общение между менеджерами недостаточным, чтобы
многочисленные участники могли почувствовать себя добывающими зачетные очки
для команды, а не создателями программных продуктов. Каждый оптимизировал
свой личный участок, чтобы решить поставленные задачи, и мало кто задумывался
над тем, как это отразится на заказчике. Потеря ориентации и связи представляют
собой главную опасность для больших проектов. В течение всей разработки
системные архитекторы должны поддерживать постоянную бдительность для
обеспечения постоянной целостности системы. Однако такая стратегия зависит от
позиции самих разработчиков. Едва ли не главнейшей функцией менеджера
программного проекта должно быть воспитание позиции заботы об общей системе,
ориентировки на пользователя.
Технологии сбережения памяти
Никакое распределение ресурсов памяти и контроль не сделают программу
маленькой. Для этого требуется изобретательность и мастерство.
Очевидно, что чем больше функций, тем больше требуется памяти при том же самом
быстродействии. Поэтому первой областью, где нужно приложить мастерство,
является нахождение компромисса между функциональностью и размером. Здесь мы
сразу сталкиваемся с важной стратегической проблемой. В какой мере этот выбор
можно предоставить пользователю? Можно разработать программу со многими
факультативными функциями, каждая из которых требует памяти. Можно
сконструировать генератор, просматривающий список опций и соответствующим
образом адаптирующий программу. Но цельная программа, соответствующая