Джозеф Фокс - Программное обеспечение и его разработка

Сравнение двух характеристик: пропускной способности и МКС.МКС является мерой внутренней скорости вычислительной аппаратуры, т. е. ЦП и памяти. С помощью МКС определяется время, потребное на выполнение команд, в него не входит время работы магнитофонов, каналов, программного обеспечения.

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

Профессионалы, работающие с вычислительными машинами, должны быть осторожны, чтобы не путать эти два понятия. Рассматривать МКС как время решения просто НЕВЕРНО, так как 16-разрядная машина в 1.2 МКС может обладать значительно более высокой пропускной способностью, чем 8-разрядная машина в 1.2 МКС, предполагая, конечно, что ввод/вывод и программное обеспечение остаются без изменения.

Время ожидания решения.Существует и другая характеристика вычислительных систем — время ожидания решения.

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

Уменьшение времени ожидания, т. е. достижение желаемого результата, может привести к снижению пропускной способности, что нежелательно. Пакетная обработка увеличивает пропускную способность, но заодно увеличивает и время ожидания.

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

«Отсутствие» ожидания достигается в большинстве систем разделением времени. Пользователь, сидящий за пультом устройства ввода/вывода, вводит приказы и данные. Вычислительная машина, обслуживающая сотни таких пользователей, достаточно быстро работает, чтобы при переключении с одного пользователя на другой им казалось, что в их распоряжении находится вся машина целиком. Машине приходится все время «изворачиваться»: ввести данные для пользователя № 10; обработать программу программиста № 47; отпечатать для девятого, вывести данные для № 197; № 177 хочет продолжить свою работу, и т. д., и т. п. Эти увертки не являются настоящей работой и составляют только накладные расходы.

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

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

Моей группой в отделении федеральных систем в IBM была успешно запрограммирована система диспетчерской службы нью-йоркской полиции (телефон вызова полиции 911), которая называлась «SPRINT». Мы просто измучились, так как корпорация не смогла отбиться от требования гарантировать время ответа не более 3 с. Нам надо было обслуживать 96 диспетчерских (телевизионных) пунктов, на которых находились полицейские. Модель IBM/50, которая нами использовалась, обслуживала такое множество экранов с большим трудом. Чтобы достичь этих трех секунд, нашим программистам приходилось творить чудеса. Из 2 млн. долларов, затраченных на всю разработку, на это ушло более 200 тыс. Разработчики программного обеспечения понимали, что предсказать время ответа для такой сложной системы заранее невозможно. Они отказались подписывать контракт, в котором были оговорены эти три секунды. Но руководство настояло на своем.

Такие «дополнительные пробежки» обычны для разработчиков программного обеспечения. Если системе не хватает ресурсов ЦП или памяти, разработчикам приходится работать с большей нагрузкой и намного дольше — и как следствие растет стоимость обеспечения. Им приходится отыскивать пути обхода слабых мест аппаратуры. Иногда приходится и переделывать программы.

Система команд и их влияние на производительность.Машина Тьюринга имела всего шесть команд. Она могла выполнять любые задания, но такой ограниченный набор используемых команд сильно затрудняет работу программиста. Одно из важных экономических решений, которое принимает каждый производитель электронных машин, это — сколько различных команд должна распознавать и выполнять машина, которую он строит. Множество распознаваемых вычислительной машиной команд будет служить ее «репертуаром» и называться системой команд (СК).

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

Невозможно ответить на вопрос о том, на какой машине (большой, с богатым выбором команд, или маленькой, с ограниченным набором) легче программировать. Как и для многих других вопросов из области вычислительной техники, ответ «зависит» от множества деталей. Маленькую, простую задачу может оказаться легче программировать на маленькой машине с небольшим набором команд. Большие, сложные задачи, возможно, легче решать на машине с «богатым» словарем. К тому же все зависит от того, на машинах какого типа привыкли работать программисты. Однажды в Хьюстоне нам пришлось с помощью группы, имевшей огромный опыт работы на большой машине IBM 360 модели 75, разрабатывать обеспечение для маленькой IBM системы 7. Это было ужасно! Они не понимали ограничений этой машины, неправильно подходили к решению задачи, использовали неверные методы. Они ухлопали целый год — и чертову уйму денег, — прежде чем разобрались, в чем дело. А это были хорошие опытные разработчики.

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