Фредерик П. Брукс
| Вид материала | Документы |
| Данные OS/360 Данные Корбато Глава 9. Два в одном Размер программы как стоимость Управление размером |
- Французский писатель, журналист и критик Фредерик Бегбедер, 1495.8kb.
- Фредерик Коплстон История философии. XX век Номер страницы указан в конце страницы, 2537.19kb.
- Gold Circle Films представляют фильм компании Integrated Films. О фильме история США, 1307.29kb.
- Брукс Кубик "Тренинг Динозавров. Забытые секреты силы и развития тела", 3174.72kb.
- 2. Во всем мире родоначальником научных основ организации производства признан: ◙ Фредерик, 992.99kb.
- Фредерик Бегбедер, 2049.29kb.
- Фредерик Бегбедер. 99 франков, 2045.96kb.
- Фредерик К. Хэтфилд всестороннее руководство по развитию силы , 4595.97kb.
- Фредерик Бегбедер. 99 Франков, 2399.26kb.
- Практикум по гештальттерапии петербург, 5899.47kb.
Данные OS/360
Опыт OS/360 подтверждает данные Харра, хотя данные по OS/360 не стольподробны. В группах разработки управляющей программы производительностьсоставила 600-800 отлаженных команд в год на человека. В группах разработкитрансляторов производительность достигла 2000-3000 отлаженных команд в годна человека. При этом учитывается планирование, тестирование компонентов,системное тестирование и некоторые затраты на поддержку. Насколько я могусудить, эти данные согласуются с результатами Харра.
Рис. 8.3 Предсказанная и фактическая скорость программирования
Рис. 8.4 Предсказанная и фактическая скорость отладки
Данные Арона, Харра и OS/360 дружно подтверждают резкие различия впроизводительности в зависимости от сложности и трудности самой задачи. Вработе оценивания сложности я придерживаюсь той линии, что компиляторы втроехуже обычных пакетных прикладных программ, а операционные системы втрое хужекомпиляторов.9
Данные Корбато
Данные Харра и OS/360 относятся к программированию на языкеассемблера. Есть немного публикаций относительно производительностисистемного программирования с использованием языков высокого уровня. Корбато(Corbato) из проекта MAC Массачусетского технологического института сообщаето средней производительности 1200 строк отлаженных операторов PL/I начеловека в год при разработке операционной системы MULTICS (от 1 до 2миллионов слов).10
Это число очень вдохновляет. Как у других проектов, MULTICS включает всебя управляющие программы и языковые трансляторы. Результатом такжеявляется системный продукт, отлаженный и документированный. Данные кажутсясравнимыми в отношении видов исполненной работы. А производительностьповышается до средней величины между управляющими программами итрансляторами в других проектах.
Но Корбато указывает количество строк за год на человека, а не слов!Каждому оператору в его системе соответствует от трех до пяти слов кода,написанного вручную! Из этого можно сделать два важных вывода:
- Производительность, измеренная в элементарных операциях, оказываетсяпостоянной, что кажется разумным, если учитывать, сколько времени нужнодумать над оператором, и сколько ошибок может в нем быть.11
- При использовании подходящего языка высокого уровняпроизводительность можно повысить в пять раз.12
Глава 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. Ее создатели получили свободу легкогообращения к диску. Первоначально это обернулось катастрофой дляпроизводительности.
При определении размеров памяти компонентов мы не установилиодновременно бюджетов доступа. Как и следовало ожидать, программист,выходивший за рамки определенной ему памяти, разбивал программу на оверлеи.В результате и суммарный размер увеличивался, и выполнение замедлялось. Хужето, что наша система административного контроля не смогла это обнаружить.Каждый программист сообщал, сколько памяти он использовал, и так как онукладывался в задание, никто не беспокоился.
К счастью, вскоре настал день, когда заработала система моделированиятехнических характеристик OS/360. Первые результаты показали наличиесерьезных проблем. Моделирование компиляции с Fortran H на машине Model 65 сбарабанами дало результат пять операторов в минуту! Анализ показал, что всемодели управляющей программы делали множество обращений к диску. Дажеинтенсивно используемые модули супервизора часто обращались к диску, ирезультат по звуку весьма напоминал шелест перелистываемой книги.
Первая мораль ясна: планировать нужно как размер резидентной части, таки общий размер. Помимо планирования этих размеров нужно планировать иколичество обращений к диску для обратной записи.
Второй урок был аналогичен. Ресурсы памяти устанавливались прежде, чемдля каждого модуля было определено точное распределение памяти для функций.В результате каждый программист, не укладывавшийся в размеры, искал, что изего кода можно выкинуть через забор в память соседу. Поэтому буферауправляющей программы стали частью памяти пользователя. Что хуже, так жепоступали все управляющие блоки, и в результате были полностьюскомпрометированы безопасность и защита системы.
Поэтому второй вывод тоже совершенно ясен: при задании размера модулянужно точно определить, что он должен делать.
И третий, более серьезный урок, который нужно извлечь из этого опыта.Проект был слишком велик, а общение между менеджерами недостаточным, чтобымногочисленные участники могли почувствовать себя добывающими зачетные очкидля команды, а не создателями программных продуктов. Каждый оптимизировалсвой личный участок, чтобы решить поставленные задачи, и мало ктозадумывался над тем, как это отразится на заказчике. Потеря ориентации исвязи представляют собой главную опасность для больших проектов. В течениевсей разработки системные архитекторы должны поддерживать постояннуюбдительность для обеспечения постоянной целостности системы. Однако такаястратегия зависит от позиции самих разработчиков. Едва ли не главнейшейфункцией менеджера программного проекта должно быть воспитание позициизаботы об общей системе, ориентировки на пользователя.