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

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

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

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

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

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

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

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

Теоретически большие системы команд можно использовать более эффективно, это относится и к стадии разработки. Не надо только думать, что это всегда так.

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

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

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

Из того, что машина А выигрывает у машины В, нельзя делать вывод о том, что ее аппаратура работает быстрее. Плохое программное обеспечение могло свести на нет все хорошее, что имеется в машине В.

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

Рис. 3.2. Пропускная способность системы и МКС как средства оценки производительности вычислительной машины.