К чему пришли на этот раз?

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

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

Самое известное из них - кардинальное повышение плотности транзисторов на единицу площади подложки. Даже при существующем подходе транзисторы уже можно исчислять миллиардами. Правда, пока только теоретически.

Размещение на одном кристалле миллиарда транзисторов открывает путь к новым уровням вычислительных возможностей. Имеется несколько различных вариантов реализации, выбор которых зависит от поставленной задачи. Если при проектировании поставлена цель добиться максимальной производительности, то предпочтительным вариантом является реализация процессора на каждом кристалле и их объединение в мультипроцессорную систему с общей памятью.

Как считает господин Y.N.Patt (www.infoart.ru /it/press/cwm/38_97/one.htm), основная проблема - как разделить функции, чтобы создать вычислительную систему наивысшей возможной производительности? Поскольку миллиард транзисторов - все-таки ограниченный ресурс, реализовать такую систему на одном кристалле невозможно. Следует решить, какие функциональные устройства не могут эффективно работать вследствие задержек сигналов в межкристальных соединениях. В противном случае нельзя достичь максимальной производительности.

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

Процессор на кристалле с приемлемыми характеристиками будет выдавать за один цикл максимум 16 - 32 команды (ширина выдачи), содержать станции резервирования, вмещающие 2 тыс. команд, и 24 - 48 конвейерных функциональных устройств высокой степени оптимизации. Предполагается, что эффективность подобных структур будет возрастать с увеличением числа транзисторов на кристалле. Видимо, транзисторы исчерпают свой ресурс раньше, чем функциональные возможности устройств, поддерживающих один поток команд. Итак, один миллиард транзисторов, один процессор, один кристалл.

Правда, пока это еще остается теорией, хотя и очень реальной. А вот показатели, хоть и не столь фантастичные, однако не менее значительные достигнуты уже сегодня. Точнее - два месяца назад.

На ежегодном собрании Ассоциации полупроводниковой промышленности (SIA) глава компании Lucent Microelectronics Кэртис Кроуфорд (Curtis Crawford) сообщил, что в самое ближайшее время возможно существенное повышение уровня интеграции микросхем. Согласно прогнозу Кроуфорда, через пять лет более 10 % продаж полупроводниковой продукции придется на долю глубоко интегрированных микросхем (system-on-a-chip). Традиционные чипы, такие, как микропроцессоры, модули памяти, различные устройства обработки цифровых сигналов и т. п., будут объединены в единую микросхему.

Повышение числа транзисторов на чипе позволит производителям интегрировать в одном кристалле кремния модемы, видеоплаты и другие устройства, ныне выпускающиеся в виде отдельных микросхем. Компания IBM, например, заявляет, что, используя новые, разработанные ею технологии можно изготовить микросхемы, содержащие 180 млн транзисторов. (Для сравнения: в нынешних процессорах Pentium II всего лишь 5,5 млн транзисторов.) Новый 3,3-вольтовый микроконтроллер оптимизирован под 0,35-микронный производственный процесс фирмы Toshiba. Устройство может обрабатывать как 16-, так и 32-разрядные системы команд, что позволяет проектировщикам системы в случае необходимости уменьшить объем внешней памяти, требующейся для хранения управляющего кода в 16-битной форме.

До недавнего времени системы на одном чипе воспринимались, скорее, как фантастика. Компании Cadence и Toshiba сделали первые конкретные шаги на пути реализации этой идеи в соответствии со стандартами VSI .

По мнению доктора Хандела Джонса (Handel Jones), руководителя аналитической фирмы International Business Strategies (IBS), в настоящее время ни одна фирма не в состоянии создать систему на одном чипе в одиночку. В связи с этим производители будут вынуждены углублять сотрудничество в данной области. Яркий пример тому - деятельность членов ассоциации VSI. Джонс считает, что через десять лет почти 50 % из прогнозируемых 480 млрд дол. продаж полупроводниковой продукции будет приходиться на микросхемы с интеграцией на уровне системы.

Если выразиться по военному, то накоплены резервы, достаточные для качественного прорыва. Что, собственно, мешает совершенствованию таких процессов, как распознавание реальной речи, рукописного текста, оптических символов (в просторечии - возможность "видеть")? Чрезмерная медлительность имеющихся платформ - вот что. Таким образом, повышение вычислительной мощности является как бы воротами в неизведанный мир. А уж желающих там во всей красе развернуться всегда было предостаточно.

Одним таким претендентом на роль некоронованного монарха является корпорация Microsoft. Как бы ее не называли пользователи, а все же именно ее "окна" лидируют по продажам среди всех видов операционных систем. Это напоминает отдающие ностальгией аналитические мудрствования отдельных "выдающихся специалистов" на тему "Десять лет назад существовали и продавались гораздо более перспективные платформы, чем IBM PC, и гораздо более качественные операционные системы, чем MS DOS Билла Гейтса. Что только роковая случайность и, несомненно, имевший место заговор некоторых злоумышленников повел все мировое человечество по кривой тропинке, приведшей в итоге к неофициальному альянсу Wintel".

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

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

В области программных кодов в текущем году достигнут тот базовый уровень, при котором слепо доверять компьютеру особо ответственные процессы еще нельзя, но в повседневной жизни им пользоваться уже можно. И более того - нужно. Этому, в частности, учит анализ причин катастрофы французской ракеты-носителя ARIANE 5. Почему именно ее? Да потому, что из всех наиболее известных аварий космической техники (надеюсь, объяснять, что именно эта область человеческой деятельности в наивысшей степени зависит от всякого рода компьютеров, не нужно никому) именно ARIANE 5 взорвался по причине дефекта в управляющей программе. На эту тему чрезвычайно полезно прочитать материал Р.Богатырева "Уроки аварии ракеты-носителя Ariane 5" (www.infoart.ru/it/press/cwm/38_97/ariane.htm).

30 октября 1997 г. с космодрома Куру (Kourou) во французской Гвиане успешно произведен пробный запуск ракеты-носителя Ariane 5. Казалось бы, данное событие не имеет никакого отношения к программным технологиям. Однако...

Разработка ракеты-носителя Ariane 5 началась еще в конце 1987 г. Но первый же старт летом 1996 г. привел к катастрофе; в результате почти на два года была приостановлена обширная Европейская космическая программа. И вот теперь, после скрупулезнейшего расследования причин катастрофы, после многочисленных переносов старта, после трех стадий верификации и тестирования программного обеспечения состоялся успешный запуск ракеты Ariane 5.

Авария произошла из-за одной-единственной ошибки в программном обеспечении, последствия же оказались очень серьезными. Это была, пожалуй, самая дорогая в истории ПО ошибка, ведь на реализацию проекта Ariane 5 затрачено 8 млрд дол., а стоимость находившихся на борту спутников серии Cluster составила 500 млн дол. К созданию этих спутников, предназначенных для изучения воздействия солнечной активности на магнитосферу Земли и связанных с ней глобальных климатических изменений, были привлечены более 500 ученых из разных стран. В течение десяти лет проектировалось оборудование, разрабатывались методики исследований. По своим масштабам катастрофа Ariane 5 сопоставима разве что с трагическим взрывом американского корабля Challenger, произошедшим 28 января 1986 г.

Итак, согласно материалам расследования, 4 июня 1996 г. полет 501, который осуществляли консорциум Arianespace и Европейское космическое агентство (European Space Agency), был прерван на 37-й секунде после старта: ракета Ariane 5 отклонилась от расчетной траектории, начала разрушаться и взорвалась в воздухе. Исследования показали, что вплоть до 36-й секунды все шло по плану, но затем друг за другом отказали и рабочая, и вспомогательная инерционные системы ориентации (Inertial Reference System, IRS). Каждая IRS-система имела свой собственный компьютер, с помощью которого на основе информации, поступающей от инерционной платформы, лазерных гироскопов и акселерометров, вычислялись углы и скорости. Данные из IRS по специальной шине передавались на бортовой компьютер, который отслеживал программу полета и через приводящие клапаны и гидравлические приводы управлял соплами двигателей и криогенной двигательной установкой Vulcain.

Для повышения надежности в систему была введена избыточность: параллельно работали две идентичные IRS с одинаковым программным и аппаратным обеспечением - одна активная, другая функционировала в холостом режиме и постоянно находилась в состоянии "боевой готовности". Как показали результаты изучения телеметрии, резкая смена траектории и изменение угла атаки были вызваны отклонениями сопел, которые в свою очередь инициировались командами бортового компьютера системы IRS. При обработке данных в основном компьютере возникло программное исключение (прерывание по нештатной ситуации). Переключения на резервный компьютер не произошло, поскольку он прервал свою работу во время предыдущего цикла съема данных по той же самой причине, что и основной. Источником возникновения исключения стала операция по преобразованию данных из 64-разрядного числа с плавающей запятой в 16-разрядное знаковое целое. Значение оказалось большим, чем позволяла разрядная сетка. В результате было возбуждено исключение Operand Error (ошибка операнда). К сожалению, в программном коде, написанном на языке Ada, обработки для данного исключения предусмотрено не было.

Итак, причина катастрофы - ошибка в программе. Но что же вызвало саму ошибку? Некомпетентность специалистов? Нет, все говорит за то, что процесс разработки организован и спланирован тщательно. Может быть, дело в некорректном управлении процессом разработки? Тоже нет. Конечно, при верификации были допущены просчеты, но все же причина оказалась чисто технической. Так в чем же дело? В языке программирования? Многие специалисты упрекают язык Ada за не очень удачный механизм обработки исключений (и вполне справедливо), но в данном случае он не причем. Далеко не все преобразования типов оказались под защитой обработчиков исключений. Тестирование на предмет выявления ошибки операндов привело к введению защиты для четырех из семи возможных переменных, относящихся к критическому фрагменту кода на языке Ada. К сожалению, ошибка проявилась как раз в одной из трех неконтролируемых переменных. Как программист это упустил? Дело в том, что, с его точки зрения, подобной ситуации быть просто не могло. Однако рассуждения разработчика были правильными для траектории Ariane 4, но траектория Ariane 5 имела совсем иные параметры.

Проблема возникла на стыке надежности и эффективности. Соблюдение всех правил контроля приводило к неизбежному росту накладных расходов, а потому программисты искали компромиссы. Конструкция узла IRS для Ariane 5 почти в точности совпадала с той, что использовалась в Ariane 4. Это касалось и программного обеспечения. После сбоя в инерционной системе IRS данные телеметрии продолжали поступать на бортовой компьютер, и он интерпретировал их как реальные параметры полета. При попытке программным образом обработать ошибочные данные значение горизонтальной скорости превысило предусмотренный диапазон представления, в результате чего и возникло исключение. В случае Ariane 4 такой ситуации возникнуть не могло. Однако носитель Ariane 5 имел совершенно иные скоростные характеристики.

Весь трагизм ситуации состоял в том, что вычисления, обеспечивающие выравнивание инерционной платформы, где и возникло исключение, во время полета вообще были не нужны! Они должны были отключиться за 9 секунд до старта. Требование продолжать вычисления для компенсации ухода инерционной платформы после старта было обязательным для Ariane 4, но не для Ariane 5 ! В итоге значение горизонтальной скорости оказалось выше, чем предполагали разработчики. Потому-то и возникло совершенно непредвиденное исключение.

17 лет назад Чарльз Хоар (Charles Hoare), известный английский ученый из Оксфордского университета, на церемонии вручения ему престижной премии Алана Тьюринга высказал тревогу по поводу индифферентного отношения людей к проблемам надежности. Объектом его критики был взятый на вооружение Министерством обороны США язык Ada. Справедливости ради надо сказать, что с 1980 г. данный язык претерпел определенные изменения, что нашло отражение в стандарте Ada 95. Но дело не в конкретном языке, а в отношении людей к возможным последствиям использования ненадежного ПО.

К сожалению, история нас так ничему и не учит. Ни один из общеизвестных языковых инструментов - Java, COBRA (IDL), ActiveX, Ada 95 - не обеспечивает того уровня надежности, которого все активнее требует реальная жизнь (в данном случае речь даже не идет о заказах военно-промышленного комплекса).

Последние годы уходящего века отмечены бурным развитием компонентного и распределенного программирования. Эффективность и совместимость превращаются в навязчивую идею. Мы всерьез не задумываемся над тем, насколько важна именно надежность. Атомные станции, космические корабли, системы ПРО - все это как-то очень далеко от наших повседневных забот. Создание JavaOS, Inferno, Nemesis, Portos, JV-Lite и других операционных сред для современных встроенных систем, работающих на основе микропроцессоров, положение ничуть не упростило.

Стали появляться бытовые приборы со сложной логикой поведения, интеллектуальные системы с "человеческим лицом". Адаптивные ситуационные системы, создаваемые, в частности, в парижской лаборатории фирмы Sony и умудряющиеся подстраиваться не только под изменение условий окружающей среды, но и под настроение человека, требуют иных принципов разработки. Количество возможных ситуаций не сопоставимо здесь с традиционным "дружественным интерфейсом" пользователя. Поведение таких систем должно быть рациональным и легко прогнозируемым, а этого можно добиться только за счет надежности. Надежность требует применения простых механизмов и максимально возможного отстранения человека от рискованных манипуляций с "пультом управления". Системы принятия решений, различные системы ответственного назначения (mission-critical systems) требуют более высокого уровня надежности, поскольку их роль в нашей жизни неуклонно возрастает. О серьезном отношении к этой проблеме говорит и недавнее объявление о совместном проекте Hewlett-Packard, Hitachi и NEC по созданию в рамках операционной системы HP-UX инфраструктуры исключений (exception infrastructure). Она на основе принципа самовосстановления будет оперативно выявлять, локализовывать и устранять неожиданные программные проблемы, которые могут порождаться в том числе и самим ядром HP-UX.

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

Уроки аварии Ariane 5 не прошли даром. Она стимулировала интерес промышленных кругов к передовым европейским исследованиям в области создания, верификации и тестирования систем повышенной надежности (safety-critical systems). Похоже, наступает эра активного применения формальных методов (formal methods), обеспечивающих контроль за соблюдением высочайшей степени целостности систем. Яркими примерами удачного внедрения этих методов могут служить проекты создания вычислительного узла для транспьютера Inmos T800, а также система обработки транзакций IBM CICS. Все большее внимание уделяется проблемам адаптивных архитектур, опирающихся на исключения. Они наиболее эффективны при управлении степенью реконфигурации и деградации сложных встроенных систем реального времени, предъявляющих повышенные требования к их надежности. Неизбежный пересмотр инструментария и методов разработки затрагивает основы индустрии программного обеспечения, включая сами языки программирования, исполняющие системы языков, базовые библиотеки модулей и классов, а также весь операционный контекст программных систем и компонентов.

Все эти космические страшилки я рассказываю отнюдь не садизма ради, а дабы проиллюстрировать изменения, незаметные на первый взгляд, но все-таки происходящие в мире настольных систем. Ведь наибольшее количество нареканий со всех сторон бедным "форточкам" приходится выдерживать именно из-за их зависаний и фатальных сбоев по причине аналогичных "непредвиденных" ошибок исходного кода. Но, как все передовое, абсолютно все новейшие достижения (если они имеют хоть малейшее применение в гражданском секторе) обязательно покидают "военную зону" и становятся основой самых обычный "мирных" продуктов. Таким образом, можно с уверенностью сказать, что найдено противоядие против самых застарелых и самых неприятных болезней вычислительной техники. Это тем более здорово, что потребность в надежных программах неизмеримо возросла с проникновением Интернет в офисы, на заводы, в конторы и квартиры.

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

С одной стороны, Netscape явно лидирует в разработке браузеров и решений на их основе, но довольно узкий круг продуктов не позволяет завоевывать смежные рынки, чем заставляет, выражаясь по-военному, штурмовать укрепления врага исключительно "в лоб" на довольно узком фронте. Однако следует признать, что пока атаки удаются виртуозно, о чем свидетельствует доля рынка в 68 %.

Александр Запольскис