Записки парасистемного программиста

До чего умна программа сортировки ОС ЕС! Хочешь — рабочие наборы данных размещай на магнитных лентах (МЛ), хочешь — на магнитных дисках (МД). Хочешь — делай их три, а хочешь — все шесть. Хочешь — дай ей 20K основной памяти, а хочешь — все 400. Короче говоря, у вас масса возможностей. Допустим, вам надо рассортировать набор данных из трех логических записей. Что ж, садитесь и пишите задание. Это не займет у вас и получаса. Только не торопитесь, проверьте как следует. Ведь вы помните, что все рабочие наборы данных — три или больше — должны быть размещены на устройствах одного типа. Или на мл, или на мд. И если это устройство — мд, то не забудьте, что этим наборам данных должны быть выделены непрерывные участки памяти прямого доступа. Иначе вам ваши три записи никогда не рассортировать. Hу вот, наконец, вы отладили свое задание, и оно начало выполняться. Теперь дело за ней, за сортировкой. Она-то уж свое дело знает. Прежде всего, она подумает, какой ей выбрать алгоритм, исходя из конкретных условий применения. У нее есть в запасе (о, мудрые создатели!) Несколько алгоритмов. Если от машинного времени, сэкономленного за счет правильного выбора алгоритма, отнять время, которое ушло на выбор этого алгоритма, то возможно получится положительная величина. Возможно даже, что эта разница в мировом масштабе применения настолько велика, что не выходя за поле положительных чисел, нам удасться отнять от нее машинное время, затраченное на разработку всего многообразия этих алгоритмов, исключая из этого числа любой, первый попавшийся. Hо оставим эту заботу коммерческим директорам. Нас больше волнует другое. Что нам делать, если: — Заранее неизвестно, сколько записей придется рассортировать. То ли 3, то ли 300 000. Эти величины вычисляются в том же задании. — В нашей тесной посудной лавке нет ни трех лишних надежных лентопротяжек, ни трех лишних непрерывных участков дисковой памяти из расчета на максимальный объем сортируемых данных. А ведь у нас мультипрограммный режим, и вероятно, что одновременно "захотят" выполняться две или больше сортировок, хотя и маловероятно, что во всех случаях сортироваться будет много данных. Увы, наш могучий слон будет бить посуду. Все его умные алгоритмы не расчитаны на тесноту. Оптимизируется только время сортировки, без учета ограничений на другие ресурсы. Если ресурсов мало, сортировка не будет выполнена, хотя бы и медленнее. Итак, перед СОД, использующей эту программу сортировки четыре альтернативы. 1. Разбить вычислительный процесс на следующие автоматические стадии: определение требуемых ресурсов для сортировки; генерация задания на сортировку; выполнение этого задания (и т. д. для каждого случая сортировки). 2. Отказаться от средств, критичных к объему дисковой памяти, в том числе и от этой программы сортировки. То есть, написать свою программу, которая "сама" возьмет столько ресурсов, сколько будет возможно, а затем будет сортировать данные столько времени, сколько нужно (быть может, даже целый час!). 3. Иметь всегда достаточное, а точнее, избыточное количество дисковой памяти и распределить память заранее для всех одновременно возможных сортировок, что называется, "от души". 4. Включить в состав СОД человека, который бы умел оценивать сверху предполагаемые размеры сортируемых данных и модифицировал соответствующие задания. Иногда, правда, после нескольких часов потерянного времени, ему бы пришлось чесать в затылке и говорить: — эх, промахнулся! Мне приходилось встречать системы, которые выбрали четвертую альтернативу, реже — третью. Hо никогда — избравшие первые две. А жаль. Большинство ошибок людей в хорошо организованных системах связано с распределением ресурсов.

4.5. Зерна и плевелы.