AS/400 в XXI веке

VLIW в Рочестере

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

Наша группа сосредоточила свое внимание на высокопроизводительных вычислениях и параллельной обработке, в основном, применительно к System/38. Мы были убеждены, что когда-нибудь создадим модели System/38 очень высокой производительности, и хотели быть готовы к этому. Исследование процессоров возглавлял Рой Хоффман. Его идея состояла в следующем: добавить к System/38 процессоры, специально предназначенные для приложений, с которыми эта система справлялась не очень хорошо. Одним из сопроцессоров, которые мы присоединили к System/38, был высокопроизводительный процессор операций с плавающей точкой. После этого мы решили пойти дальше и построить System/38 с производительностью суперкомпьютера. В наши намерения входило добиться на своем прототипе большей производительности приложений, интенсивно использующих плавающую точку, чем на System/390 с ее векторными возможностями. Достичь поставленной цели мы собирались с помощью сопроцессора фирмы FPS (Floating Point Systems).

В 1975 году FPS выпустила АР120В — первенец семейства матричных процессоров FPS, использовавшийся, в основном, для обработки сигналов. Матричные процессоры работают с упорядоченными наборами данных, обычно, векторами или матрицами. В 1980 году FPS выпустила FPS164 на основе архитектуры АР, предназначенный для сложных научных расчетов. FPS164 был полностью 64разрядным процессором. Он мог с успехом соревноваться с любыми суперкомпьютерами того времени, включая Cray.

Процессор FPS не был автономным, а подключался к управляющей вычислительной системе. Мы купили его и подключили к System/38, а параллельно стали разыскивать коммерческие приложения, которым требовались высокопроизводительные вычисления с плавающей точкой. Мы хотели показать, что вычисления такого типа применимы не только к научным расчетам. Наиболее обещающими были приложения для банков и работы с ценными бумагами.

У FPS были планы — создать с помощью новых технологий такие версии FPS164, которые работали бы вместе с System/38 в нормальных условиях офиса. Но именно тогда проект Fort Knox был прекращен, и мы сосредоточили все свои силы на Silverlake. Увы, проект использования с System/38 новых сопроцессоров нам не довелось довести до конца. Однако он коечему научил нас, и этот опыт пригодился при работе над сопроцессорами для AS/400.

Системы FPS были одними из первых с длинным словом команды, содержавшим по несколько операций на команду. В машине имелось 10 функциональных узлов, и каждому из них требовалась на каждом цикле собственная подкоманда. В длинном слове команды были отдельные подкоманды для каждого узла. Одна команда могла полностью обработать вектор.

Вместо оптимизирующего компилятора для создания длинных слов команд применялись библиотеки языка ассемблера. Основной компьютер обрабатывал логику программы и вызывал процедуры с длинными командами для исполнения на машине FPS. Данный тип программирования схож с микрокодом с длинным словом типа HMC, использовавшегося в System/38. Хотя в командах НМС было не так много битов, как длинном слове команды FPS, но каждая команда НМС запускала несколько функций процессора System/38. Одно время мы рассматривали возможности использовать в НМС некоторые приемы для распределения команд по функциональным узлам.

Примерно в то же самое время, группа исследователей Йельского университета (Yale University) предложила создать машину с очень длинной командой (512 бита), которую они назвали VLIW. Коммерческий проект попыталась осуществить фирма Multiflow Computers, но, в конечном счете, потерпела неудачу изза недостатка финансирования. В 1993 HP лицензировала у более не существующей компании пакет ее патентов.

Интерес к машинам VLIW в Рочестере сохранялся и в конце 80х годов, главным образом, благодаря связи этой технологии и НМС. После объявления IBM AS/400 мы начали работу над процессором для систем следующего поколения. Технология VLIW стала частью новой архитектуры.

Одним из руководителей проекта VLIW был Дэйв Льюк (Dave Luick). Дэйв начинал с нашего первого процессора, возглавлял разработку процессора System/38 Model 7 и с тех пор участвовал в проектировании всех наших процессоров. Он из тех, кто всегда стремится выйти за пределы традиционной технологии, и очень заинтересовался применением к НМС некоторых технологий VLIW. Процессор CRISC, обсуждавшийся в лекции 2, был разработан как процессор для Advanced Series перед тем, как мы перешли на технологию PowerPC. Так вот, благодаря Дэйву и некоторым его соратникам, C-RISC имел НМС с рядом характеристик машины VLIW.

В 1991 году Дэйв в составе группы из 10 человек занимался оценкой возможности использования процессоров PowerPC для AS/400. После принятия решения о переходе на технологию PowerPC, он и его единомышленники направили свои усилия на создание PowerPC-совместимой машины VLIW. Так как VLIW очень зависит от технологии компиляторов, немедленно начались совместные исследования с IBM Research. Специалисты этой лаборатории, работавшие над VLIW, не могли найти для этой технологии такую платформу, чтобы новшества не оказали негативного влияния на бизнес заказчиков. Технологическая независимость AS/400 снимала этот вопрос. Мы могли внедрить VLIW в AS/400 безболезненно для пользователей.

Работа над VLIW в Рочестере показала огромный потенциал данной технологии для повышения производительности AS/400. Вопервых, благодаря упрощенной архитектуре, больше похожей на Speed Demon; можно сократить время такта процессора и создать по той же технологии микросхему, которая по скорости будет вдвое превосходить стандартный PowerPC. Вовторых, в течение нескольких следующих лет достижим намного больший параллелизм (16 или даже более конвейеров) на одной микросхеме, чем в суперскалярных RISC; где всего лишь пять или шесть конвейеров.

В настоящее время работа над VLIW в Рочестере по ряду причин приостановлена. Дело, прежде всего, в том, что мы договорились использовать универсальную технологию процессора как для серии AS/400е, так и для продуктов линии RS/6000. Хотя благодаря независимости от технологии в AS/400 можно внедрить столь радикально новую технологию как VLIW, на RS/6000 это невозможно. Зато обе системы могут использовать RISC-процессоры PowerPC.

Некоторое время мы рассматривали возможность создания процессора PowerPC с ядром VLIW. Такой процессор мог бы использоваться как AS/400, так и RS/6000. Новый транслятор для AS/400 генерировал бы код либо для интерфейса процессора PowerPC, либо обходил его и генерировал код непосредственно для ядра VLIW. Компоненты SLIC работали бы через интерфейс PowerPC, а со временем мы переписали бы их для исполнения непосредственно ядром VLIW. Прикладные программы с шаблоном внутри программного объекта, могли бы автоматически конвертироваться для VLIW, а программы без шаблона продолжали бы работать как программы PowerPC.

Из-за споров вокруг эффективности трансляции команд в операции ядра VLIW мы приостановили работы над процессором PowerPC с таким ядром. Придется подождать и посмотреть, сколь успешно технология VLIW будет использована в Intel Merced. Некоторые из наших разработчиков даже предлагали подумать над возможностью перехода AS/400 на этот новый 64-разрядный процессор Intel. На мой взгляд, это было бы забавно.

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

До сих пор мы говорили только об отдельных процессорах и возможностях их применения в серии AS/400е. Следующий раздел посвящен перспективам развития многопроцессорных систем.

Будущее многопроцессорных систем

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

Масштабируемые многопроцессорные системы с общей памятью

Системы с централизованной и распределенной общей памятью мы рассматривали в лекции 2.

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

Во втором случае память распределена между несколькими узлами, каждый из которых содержит небольшое число процессоров, подключенных к памяти узла по схеме SMP. В узле есть процессоры и память, но нет дисков и других устройств ввода-вывода. Адресное пространство всех узлов общее, то есть любой процессор может адресовать память любого узла. Чтобы проще представить это себе, вообразите фрагменты общей памяти расположенные в узлах системы и связанные между собой высокоскоростным глобальным соединением. У каждого узла общая шина памяти, соединенная с его фрагментом общей памяти, но доступ к этому фрагменту возможен и для процессоров всех остальных узлов с помощью глобального соединения. Отличие состоит только во времени доступа. Локальный доступ выполняется быстрее глобального, и поэтому подобный кластер узлов SMP называется машиной с неоднородным доступом к памяти, или машиной NUMA.

Мы уже достаточно подробно рассмотрели модель централизованной общей памяти в AS/400. Описанная в лекции 2 подсистема памяти UMA с перекрестными переключателями и ее разновидности могут с легкостью поддерживать 16-канальные конфигурации SMP с высокопроизводительными процессорами, планируемыми для серии AS/400е. После версии 4, возможно, появятся 20- или даже 24-канальные конфигурации SMP.

Для очень больших конфигураций будут использованы кластеры узлов SMP. В лекции 11 мы рассмотрели последовательность кластерной поддержки для AS/400: и системы без разделения, каждая из которых использует собственные дисковые устройства; и кластеры с переключением дисков между системами; и, наконец, системы с разделением дисков между компьютерами кластера. Получив с помощью независимых ASP возможность разделения всех дисков кластерного пула, мы можем подумать о разделении памяти между узлами, и, таким образом, о создании нашей первой машины NUMA.

Интерес к применению NUMA в AS/400 возник несколько лет назад. Дик Бут (Dick Booth), рочестерский инженер, занимался в начале 90-х годов многопроцессорными системами в IBM Research. В процессе работы у него возникла идея новой архитектуры. Первоначально Дик назвал ее "крепко связанным мультипроцессором", так как она занимает промежуточное положение между слабо связанными (МРР) и сильно связанными (SMP) мультипроцессорами. Теперь подобная структура называется просто NUMA.

Дик верил, что NUMA будет работать в AS/400. Вернувшись в Рочестер, он заразил своей идеей коллег. В 1991 году был основан объединенный проект с IBM Research и началась работа над прототипом. Как это часто бывает, новая идея натолкнулась на определенный скептицизм. Группа выстояла, завершила прототип и продемонстрировала его, чем завербовала в свои ряды новых сторонников. Сегодня эти люди успешно работают над NUMA для будущих AS/400.

CC-NUMA и COMA

Для AS/400 возможны как минимум две реализации NUMA. Первая — неоднородный доступ к памяти с когерентным кэшем CC-NUMA (cachecoherent nonuniform memory access), вторая — архитектура памяти только с кэшем COMA (cacheonly memory architecture). Конкретные детали реализации и оценки производительности этих архитектур широко отражены в компьютерной прессе. С начала 90-х годов разновидности этих архитектур исследуются в нескольких университетах и лабораториях. Некоторые компьютерные компании, такие как SGI (Silicon Graphics, Inc.), Sequent и Convex уже поставляют на рынок серверы CC-NUMA с большими возможностями масштабирования.

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

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

Это отличается от шинной когерентности со слежением (snoopy busbased coherence), используемой для кэшей второго уровня в узле SMP, описанной в лекции 2. Одни и те же данные из страницы общей памяти могут одновременно находиться в нескольких кэшах процессоров узла SMP. При изменении данных в кэше одним процессором должны быть обновлены и копии в кэшах других процессоров. Под когерентностью кэшей понимают актуальность всех копий. При использовании протокола слежения справочник кэша каждого процессора содержит информацию только о тех страницах, которые находятся в его собственном кэше. При всяком изменении процессором данных в кэше об этом сообщается по шине слежения всем остальным процессорным кэшам, с целью обновить те же данные. Таким образом, каждый кэш следит за изменениями во всех других кэшах и обеспечивается когерентность кэшей. Поддержание в кэшах процессоров множественных копий гарантирует одинаковое время доступа ко всем данным (поэтому данная архитектура и называется UMA).

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

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

Ранние реализации NUMA с когерентностью кэшей на основе справочников имели большую разницу во времени обработки промахов удаленных и локальных кэшей. Когда процессор в узле определяет промах кэша L2, время получения данных из памяти удаленного узла может быть значительно больше времени получения данных из памяти узла, в котором находится процессор. Например, на ранней машине Sequent промахи удаленных кэшей обрабатывались в 10 раз медленнее локальных. Чтобы добиться от такой архитектуры достаточной производительности, требуется поддерживать приемлемо низкое число удаленных обращений путем тщательного распределения данных приложений по узлам. Обычно число таких обращений пытаются свести к 10 процентам. Таким образом, переход от архитектуры SMP к распределенному кластеру может потребовать изменений в прикладных программах и перераспределению данных приложений.

В последних системах NUMA преодолена проблема множества удаленных обращений, присущих ранним системам, так что необходимость в изменении приложений и перераспределении данных отпала. CCNUMA и COMA используют для этого некоторое дополнительное оборудование. На каждом узле расположено по одному или несколько процессоров, а также собственные кэши, подключенные через подсистемы памяти к локальной памяти узла (это в точности соответствует описанной ранее конфигурации SMP). Теперь представьте себе, что к подсистеме памяти и к сети межузловых соединений подключено отдельно устройство удаленного доступа RAD (remote access device). Применительно к AS/400 я называю эту дополнительную аппаратуру RAD, однако, общепринятого названия не существует. Для некоторых систем ее именуют контроллером когерентности, для других — хабом. Независимо от названия, ее назначение — реализация протокола когерентности кэшей на основе справочника между подсистемой памяти узла и сетью межузловых соединений.

Подключения RAD для AS/400 будут очень похожи на подсистемы ввода-вывода, представленные на рисунке 10.1, но при этом с одной стороны к RAD присоединены шины 6хх, а с другой — порты SAN.

В машине CC-NUMA RAD содержит отдельный кэш, в котором находятся только удаленные данные. При адресации процессором данных, которых нет в его собственном кэше, запрошенные данные считываются из памяти узла (если адрес локальный), или из кэша RAD (если адрес удаленный). Обращения к удаленным данным, которые не могут быть обслужены кэшем RAD, должны быть посланы по межузловой сети к "домашнему" узлу соответствующей страницы памяти, чтобы получить нужный блок данных из памяти удаленного узла, а также для поддержания когерентности.

Кэш RAD повышает производительность машины архитектуры CC-NUMA, сокращая число удаленных промахов кэша, которые должны обрабатываться удаленным узлом. Очевидно, что первое обращение к удаленной странице памяти будет связано с большим временем ожидания выборки данных из памяти удаленного узла и помещения их в кэш RAD. Последующие обращения к той же странице любым процессором узла будут отрабатываться быстрее, так как не надо пересылать данные по межузловой сети. В результате, соотношение времени обработки промахов удаленных и локальных кэшей сокращено в современных системах от 2:1 до 3:1. Расходы на удаленные обращения достаточно невелики, так что большинство приложений при переносе их с SMP на кластер не требуют изменений. В связи с этим, CC-NUMA часто называют системами масштабируемого SMP.

Пример системы CC-NUMA — SGI/Cray Origin 2000. Origin 2000 может содержать до 64 узлов, соединенных масштабируемой сетью CrayLink. В каждом узле один или два процессора, до 4 ГБ памяти и соединения с подсистемой вводавывода. Максимальная конфигурация — 128 процессоров с общим объемом памяти в 256 ГБ. Пока в Origin 2000 устанавливаются процессоры MIPS R10000, работающие на частоте 195 МГц и имеющие кэши второго уровня объемом 4МБ.

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

Кроме всего прочего, Cray Origin 2000 (конфигурации, насчитывающие более 64 процессоров, обозначены как системы Cray; меньшие модели — как SGI) — основа проекта ASCI Blue Mountain, о котором мы говорили в лекции 2. Возможно, Вы помните, что этот проект состоит из двух частей. Работы ведутся поэтапно в Национальной лаборатории Лос-Аламоса, с задачей получить в конце 1998 года конфигурацию с 3072 процессорами, которая сможет достичь 4 терафлоп. Параллельно в Ливерморской национальной лаборатории будет развернута система IBM ASCI Blue Pacific, которая должна достичь аналогичного уровня производительности с помощью 512 8-канальных узлов SMP. Успех или неудача этих двух систем, несомненно, многое скажут о том, каковы перспективы машин с распределенной общей памятью.

Недавно было проведено несколько исследований, направленных на улучшение производительности систем CC-NUMA и дальнейшее сокращение соотношения времени обработки промахов локальных и удаленных кэшей. Выяснилось, что в этом плане много обещает конфигурация СОМА. Эта система использует тот же самый протокол когерентности кэшей на основе справочника, что и CC-NUMA, но в СОМА часть основной памяти узла выделяется для работы в качестве большого кэша удаленных данных. Отдельный кэш удаленных данных в RAD СОМА устранен; вместо этого удаленные данные размещаются в иерархии кэшей процессора и основной памяти узла.

Первый проект СОМА в начале 90х годов, позволял осуществлять перенос данных в основную память узла порциями, равными по размеру блоку кэша (такой подход аналогичен хранению блоков кэша в отдельном удаленном кэше CCNUMA). Проблема этого подхода в том, что размеры блоков кэша меньше страниц памяти, поэтому для управления вторым размером страниц основной памяти в узле нужна дополнительная аппаратура, по сути, дублирующая описанную в лекции 8 аппаратуру виртуальной памяти. Последние реализации СОМА, названные SCOMA (simple COMA), хранят удаленные данные в основной памяти узла только блоками, равными размеру страницы. Благодаря этому, доступ как к удаленным, так и к локальным данным может осуществляться имеющейся аппаратурой виртуальной памяти. Конечно, в узле SMP попрежнему нужна аппаратура, поддерживающая протокол когерентности кэша на основе справочников для удаленных данных, вместо протокола слежения для локальных данных.

S-СОМА потенциально превосходит по производительности CCNUMA, так как в состоянии задействовать для хранения удаленных данных большую память узла. Эта архитектура может динамически настраивать размер памяти для удаленных данных в соответствии с потребностями приложения. С другой стороны, S-COMA требует пересылки по сети межузловых соединений блоков данных большего размера в случае удаленного промаха на узле. В течение следующих нескольких лет мы увидим, вы теснит ли СОМА или какой-либо ее вариант используемую ныне архитектуру CC-NUMA.

Будущее ввода-вывода AS/400

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

Будущие технологии подсистем ввода-вывода

В лекции 10 мы говорили о том, что архитектура подсистемы ввода-вывода в ходе выпуска версии 4 будет перестраиваться. Вероятно, это будет продолжаться и после 2001 года. В намерения IBM входит создание структуры ввода-вывода, в которую можно будет легко внедрять самые современные технологии. Внедрение шин и адаптеров PCI следует рассматривать как шаг в этом направлении, а не как окончательную цель.

Для подключения устройств к AS/400 попрежнему будут использоваться различные интерфейсы. Большая часть средств подключения вводавывода уже обсуждалась в лекциях 10 и 11, включая SPD, PCI, ATM, Ethernet, SCSI и SSA. При необходимости, мы можем задействовать и другие, например ANSI Fibre Channel. Используемая System Area Network (SAN) допускает применение большинства новых интерфейсов.

SAN, которая, как уже говорилось, обычно подключается как кольцо, поддерживает протокол SCIL (Scalable Coherent Interface Link) и обладает большим потенциалом пропускной способности и скорости. В лекции 11 я упомянул параллельное соединение SAN с 32 волокнами, работающее на частоте 500 МГц, что обеспечивает пропускную способность 1 ГБ в секунду (при том, что половина волокон используется для избыточных линий). Возможны и более быстрые версии. Так как соединения этого типа основаны на стандарте IEEE и используются в системах и IBM, и других фирм, то в будущем возможны новые подключения.

При переходе к сетевым вычислениям соотношение быстродействия и цены высокоскоростных коммуникационных адаптеров также будет улучшаться. Прогнозируется самое широкое распространение новейших коммуникационных технологий, таких как АТМ, оптоволоконные соединения и спутниковая связь, что позволит создавать еще более распределенные приложения. Ожидаемое значительное удешевление высокопроизводительных беспроводных коммуникаций (как локальных, так и на большие расстояния) будет, в свою очередь, способствовать увеличению масштабов мобильных вычислений.

В будущем нас также ожидают более объемные подсистемы хранения данных, и SAN позволит их подключать. Скорее всего, на всех системах IBM для этого будет применяться SSA — последовательная архитектура, оптимизированная для хранилищ. Следовательно, можно ожидать появления больших массивов дисков, лент и оптических устройств, совместно используемых многими системами.

IOP современных AS/400 будут продолжать развиваться. Все новые IOP используют процессоры PowerPC. Каждый из них имеет собственную память и работает под управлением специализированной ОС реального времени. Процессоры для новых IOP будут либо стандартными представителями семейства 32-разрядных процессоров PowerPC, создаваемых в Барлингтоне, либо (мы уже говорили о такой возможности) — размещаться на той же микросхеме, что и основной процессор.

Так как ОС реального времени на сегодняшних IOP, подобно всем другим были за последние несколько лет многократно модифицированы, то на разных IOP одной AS/400 могут выполняться разные версии ОС. Самая современная версия ОС, работающая на IOP PowerPC, основана на микроядре для лучшей переносимости ПО. В будущем мы сможем использовать для IOP стандартную ОС, так как ОС все меньше и меньше управляют устройствами. Уже сегодня, благодаря технологиям PCI, IOP отвечает за интерфейс шины PCI и за выполнение некоторых высокоуровневых функций ввода-вывода ОС.

Дисковые массивы

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

Несколько производителей недавно представили технологию чередования блоков данных (data striping) между дисками массива, заявив, что это глобальный прорыв в борьбе за повышение производительности систем. Между тем, впервые подобная технология стала коммерчески доступна еще на System/38. Ранее мы говорили, что приложение System/38 или AS/400 использует несколько системных объектов. В целях повышения производительности IBM решила распределить различные объекты по нескольким дискам, обеспечив параллельный доступ к ним. Таким образом, и System/38 и AS/400 использовали чередование блоков данных с момента своего появления на рынке.

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

Давайте попробуем представить себе все это более наглядно. Итак, существует массив из четырех синхронно вращающихся дисков. При достаточном числе контроллеров устройств и трактов данных, мы могли бы записывать части одного объекта на все диски параллельно: четверть записи — на первый диск; другую — на второй и т. д. Вся запись в целом производится на четыре диска в четыре раза быстрее, чем та же самая — на один диск. Такая же экономия времени достигается и при считывании записи.

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

В лекции 8 мы определили как одно из преимуществ одноуровневой памяти то, что ни прикладное ПО, ни ПО ОС над MI никогда не имеют информации о дисковых устройствах. Одной из причин сокрытия дисков было предположение о скорой замене механической технологии чем-то иным. Полупроводниковые диски (большие полупроводниковые памяти с батареями питания) могут быть одним из вариантов такой замены, но возможны и другие.

Теперь давайте перейдем к будущему некоторых программных технологий для AS/400.

Будущие программные технологии AS/400

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

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

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

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

Операционные системы

В предисловии я говорил, что большинство новшеств современных ОС — "хорошо забытые старые" работы 60х годов. Такое положение вряд ли скоро изменится, независимо от пропаганды производителями революционных расширений, планируемых для очередной "новой" ОС. ПО будет развиваться медленно, и в 2001 году мы по-прежнему будем оперировать сегодняшними ОС. Некоторые из них будут расширены, другие исчезнут, но фундаментальная структура используемых ОС останется неизменной.

Рост емкости и производительности аппаратуры заставит большинство разработчиков ОС устранять ограничения, присутствующие в сегодняшних реализациях. Переписывание основной части для 64-разрядных процессоров займет разработчиков Unix на следующие несколько лет. Производители 32-разрядных ОС ПК, вероятно, до 2001 года даже не начнут заниматься полной 64-разрядной реализацией, за исключением использования 64-разрядного адреса.

Как и все, OS/400 вряд ли претерпит значительные изменения, кроме обусловленных текущими потребностями. Большая часть таких изменений будет связана с поддержкой новых функций и средств, которые мы уже обсудили. В начале 90х IBM переписала SLIC, предоставляющий базовые функции ОС/400, чтобы воспользоваться предполагаемым ростом емкости и производительности аппаратных средств. Таким образом, у OS/400 есть прочная основа для развития в будущем.

Глобальные файловые системы

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

Рассмотрим простой пример двух RISCсистем AS/400, соединенных с помощью OptiConnect через оптоволоконную шину SPD. Оптоволокно способно передавать данные с пиковой скоростью 1 ГБит/с, что равно примерно 100 МБ/с, считая, что несколько разрядов используется для обнаружения ошибок. Измерения показывают, что фактическая скорость передачи данных между такими системами ближе к 32МБ/с (и это очень высокий результат!), что примерно в три раза меньше пиковой. Причина уменьшения скорости передачи данных — накладные расходы ПО. При каждой передаче данных ПО ОС должно выполнить некоторую последовательность команд. В лекции 10 мы рассматривали шину SPD и функции SLIC, необходимые для операции ввода-вывода. В будущем для подобного соединения можно будет использовать SAN, обеспечивающий более высокую скорость при меньших накладных расходах.

Для файловой системы с разделением дисков между двумя или несколькими системами, к накладным расходам ПО файловой системы на передачу данных добавляются еще и накладные расходы позиционирования головок диска. Также надо учитывать, что накладные расходы не зависят от размеров пересылаемого файла, поэтому скорость пересылки небольших файлов значительно ниже, чем больших. Например, NFS (Network File System) Sun Microsystems на типичной высокопроизводительной рабочей станции Unix может пересылать файлы по 10 МБ со скоростью примерно 2 МБ/с, а файлы по 40 МБ — примерно 6 МБ/с.

Для повышения скорости пересылки данных на факультете электротехники и информатики Университета Миннесоты (University of Minnesota), где я являюсь адъюнкт-профессором, разрабатывался проект разделяемой файловой системы для хранилища, подключенного напрямую к сети. Эта модель получила название GFS (Global File System). GFS должна была иметь меньшие накладные расходы по сравнению с современными файловыми системами и поддерживать высокие скорости передачи данных даже для файлов малого размера.

Впервые GFS была публично продемонстрирована в апреле 1997 года на выставке NAB (National Association of Broadcasters) в ЛасВегасе (Las Vegas), штат Невада. Телекорпорации и производители кинофильмов, широко использующие компьютерную анимацию и спецэффекты — крупные пользователи сетевых файловых систем, позволяющих передавать данные от высокопроизводительных дисковых массивов на мощные рабочие станции Unix. В связи с этим несколько производителей показали на выставке NAB свои наиболее эффективные системы.

Среди прочих демонстрировалась и файловая система GFS, установленная на нескольких очень мощных рабочих станциях Silicon Graphics. Эти рабочие станции были выбраны потому, что ILM (Industrial Light Magic) использовала аналогичные рабочие станции для продолжения сериала "Jurassic Park" фильмом "The Lost World: Jurassic Park", претендующего на то, чтобы стать "хитом" следующего месяца. В ходе его съемок были применены новейшие достижения компьютерной анимации. Команда компьютерных художников ILM использовала технологию Silicon Graphics для создания пугающе правдоподобных динозавров. Причем этих искусственных созданий было сгенерировано в четыре раза больше, чем в фильме-предшественнике.

Рабочие станции были подключены к нескольким дисковым массивам Ciprico Fibre ChannelCiprico — фирма из Миннеаполиса (Minneapolis), штат Миннесота, работавшая над рядом проектов вместе с Университетом Миннесоты., любимых киноиндустрией за очень большую скорость передачи данных. Новый дисковый массив Ciprico способен обеспечивать скорость 85 МБ/с, а пиковая скорость передаче достигает 100 МБ/с. Демонстрация GFS на стенде Ciprico была первой демонстрацией хранилища непосредственно подключенного к сети на основе Fibre Channel.

На выставке NAB GFS пересылала файлы Silic on Graphics на рабочие станции и обратно с изумительной скоростью в 60 МБ/с — в 10 раз быстрее традиционных сетевых файловых систем и примерно в 3 раза быстрее всех остальных, демонстрировавшихся на выставке систем. Не стоит и говорить об огромном интересе, проявленном к ней телевещательными корпорациями и киногигантами. После выставки такой интерес возник еще у ряда компаний, представляющих самые разные отрасли, от медицины до обслуживания Интернета.

Интерфейсы пользователя

Особый интерес вызывает будущий интерфейс пользователя вычислительной системы. Вчерашний графический интерфейс пользователя GUI (graphical user interface) быстро уступает дорогу новому сетевому интерфейсу пользователя NUI (network user interface). Несколько производителей, включая IBM, Lotus, Microsoft, Oracle, Netscape и Sun, объявили о создании новых NUI для ПК и СК. Эти интерфейсы по типу браузеров предоставляют пользователю прозрачный доступ к ресурсам как локальных, так и удаленных систем. Задача в том, чтобы средства удаленной системы выглядели для пользователя так же привычно, как и средства локального ПК.

Пользовательские интерфейсы никогда так интенсивно не развивались с момента своего появления в середине 80х. Кажется сейчас любой создатель NUI имеет собственное представление о том, как они должны выглядеть. Многие следуют по пути Windows (панель задач, раскрывающиеся меню и множество окон на экране). Другие склонны ломать эти привычные концепции и упрощать пользовательский интерфейс.

Например, Sun представил NUI для JavaStation, в котором пользователю не надо открывать, закрывать, или сохранять приложения. Вместо этого все приложения выглядят выполняющимся постоянно. Один щелчок значка (Sun полагает, что двойные щелчки слишком сложны) позволяет переключаться между приложениями, которые всегда занимают полный экран, чтобы избежать путаницы перекрывающихся окон. Такие NUI предназначены для подавляющего большинства людей в мире, никогда не видевших интерфейса Macintosh или Windows. Netscape, например, предполагает, что ее NUI будет также использоваться в домашних компьютерных видеоиграх и в телевизорах с поддержкой Интернета.

Первый NUI, созданный для IBM Network Station гораздо менее радикален. Он разрабатывался так, чтобы сохранить привычный пользователю внешний вид. С помощью отдельных окон на экране можно запускать терминальную эмуляцию для приложений 5250/3270, приложения Unix motif, браузер и стандартные приложения Windows. Со временем этот интерфейс может быть расширен для поддержки специфических NUI, требующихся пользователям AS/400. Несколько лет уйдет на то, чтобы отобрать все наилучшие для рабочего стола возможности — идеал, которого, вероятно, не достигнет ни один интерфейс.

Будущий рост производительности всех систем позволит применять еще более простые интерфейсы, в том числе воспринимающие голос и рукописный текст. Подобный прогресс значительно увеличит число пользователей компьютеров за счет тех людей, на чьем видеомагнитофоне со дня покупки так и мигает "00:00".

Будущий рост производительности всех систем позволит применять еще более простые интерфейсы, в том числе воспринимающие голос и рукописный текст. По добный прогресс значительно увеличит число пользователей компьютеров за счет тех людей, на чьем видеомагнитофоне со дня покупки так и мигает "00:00".

Хотя распространение новых интерфейсов будет зависеть от культурных и географических факторов, к 2001 году мы станем свидетелями размывания границ между традиционными видами человеческой деятельности: работой в офисе, дома, или в дороге, ведением личных дел, обучением и отдыхом. Происходит быстрое слияние рынков компьютеров: развлечений, коммуникаций, и потребительского (возможно, дойдет даже до того, что DoomРаспространенная, в том числе и в России, компьютерная игра. — Прим. консультанта. будет работать "вживую" на AS/400).

Технологии приложений

В лекции 11 я потратил много места на обсуждение трех моделей приложений, на развитие которых направлены основные инвестиции в версию 4 (сетевые, совместные и клиент-серверные вычисления). Ожидается, что эти направления сохранятся и в дальнейшем. Пока не похоже, что в ближайшем будущем их заменят какие-либо другие, но в то же время, мало кто мог еще несколько лет назад предсказать быстрое распространение, например, сетевых вычислений. Возможно, в ближайшие 510 лет появится новая модель приложений, но какой она будет? В любом случае, я не сомневаюсь, что способность AS/400 осваивать новые модели не подведет.

Было бы замечательно, если бы любое приложение отлично работало на любой системе, но увы... Многие заказчики AS/400 хотят работать с приложениями, написанным для другой системы, или точнее для другой операционной системы. Интегрированные серверы приложений, описанные в лекции 11, почти всегда позволяют им это. Конкретно, на этих серверах могут исполняться приложения, написанные для OS/2, AIX и Windows NT. Если наших заказчиков увлечет какая-либо другая ОС, IBM легко добавит ее поддержку в новые интегрированные серверы.

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

Самая большая проблема объектно-ориентированной технологии — требуемый ею уровень подготовки. В результате разработка и настройка будущих приложений будут выполняться на нескольких уровнях с разными требованиями к подготовке программистов. Например, только относительно небольшая группа профессионалов, создающих ОС и средства разработки приложений, будут использовать собственно объектно-ориентированные языки, такие как С++ (часто сравниваемый с обоюдоострой бритвой). Поставщики решений и ISV, вероятно, будут использовать такие языки как Java, а также настраиваемые каркасы и готовые компоненты, например, из проекта San Francisco. Прикладные программисты, повидимому, предпочтут визуальное соединение компонентов, а пользователи, программирующие от случая к случаю, — дружественные интерфейсы и самообучающиеся средства.

Еще до 2001 года мы узнаем, работает ли подход Java "Пишется однажды — исполняется везде". Учитывая, что виртуальная машина Java реализована для всех основных платформ, вполне возможно создание Javaприложения, работающего на всех платформах. Насколько универсален такой подход — предмет споров. Объектно-ориентированные технологии предоставляют нам принципиально новый способ разработки программ. А как быстро и плодотворно мы сумеем этим воспользоваться — покажет только время. Но общее направление поисков для большинства специалистов очевидно.

Общая производительность системы

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

Недавно я просматривал результаты тестов на производительность по нескольким вычислительным системам и размышлял о методиках ее измерения. Как часто, все же, мы предпринимаем смешные попытки свести всю нужную заказчику информацию о данном компьютере к одной цифре!

Чаще всего в роли такого "универсального" показателя выступает тактовая частота процессора в мегагерцах. Как Вы помните, тактовая частота эквивалентна оборотам двигателя автомобиля — она показывает, как быстро "крутится" двигатель, но ничего не говорит об объеме выполняемой работы. Многие современные процессоры "крутятся" очень быстро, но при этом выполняют незначительную работу. Тестовые программы должны давать нам представление о том, какой объем работ выполняется на самом деле.

Программы тестирования производительности

Сегодня существует великое множество разнообразных программ тестирования производительности, так что выбор той, которая больше Вам подходит — дело нелегкое. Среди производителей компьютеров наиболее широко распространены тесты, созданные независимыми разработчиками, — SPEC (Standard Performance Evaluation Corporation) и TPC (Transaction Processing Performance Council).

SPEC образована в 1988 группой фирм — производителей компьютеров для разработки набора тестов для рабочих станций и серверов Unix. Набор тестов SPEC представляет собой группу программ, написанных на С и Fortran. По одним из них, ориентированным на обработку целых чисел, вычисляется показатель SPECint, по другим, ориентированным на операции с плавающей запятой, — показатель SPECfp. Для определения производительности тестовые программы запускают по очереди, замеряя время их выполнения. Итоговым значением считается среднее геометрическое (перемножение n чисел с последующим извлечением корня nой степени) промежуточных результатов.

Первым набором тестов этой серии был SPEC89 (89 — год создания) из 10 программ (4 целочисленных и 6 с плавающей запятой). В SPEC92 число программ возросло до 20, а в последнюю версию SPEC95 были добавлены еще несколько дополнительных программ. Сейчас ведется работа над SPEC98.

Так как тестовые программы очень малы и выполняются по одной, то обычно программа целиком умещается во внутреннюю кэшпамять процессора. В SPEC95 было добавлено несколько программ большего размера, но и кэши так же растут. В результате, SPEC может измерить "грубую силу" процессора, но не производительность системы в целом, так как эти тесты не охватывают память и подсистему ввода-вывода. В результате, SPEC применяется, в основном, для измерения производительности однопользовательской рабочей станции Unix. И, как можно было предсказать заранее, процессоры с большими значениями МГц, такие как Digital Alpha, показывают на этих тестах очень хорошие результаты.

Тесты ТРС предназначены для измерения общей производительность системы, а не только процессора. В соответствии с программным заявлением, ТРС — это бесприбыльная организация, чья цель — организация тестирования обработки транзакций и баз данных, а также распространение объективных и проверяемых результатов этих тестов. В ТРС сейчас 45 членов, в их числе все основные производители компьютеров.

ТРС определяет свои тесты в терминах деловых транзакций. Например, обычная транзакция ТРС включает обновление базы данных для таких приложений, как управление инвентарным списком (товары), заказом авиабилетов (обслуживание) или банковскими операциями (деньги). На сегодня основные тесты этой группы — ТРС-С и ТРС-D.

ТРС-С представляет собой тест OLTP. В процессе его пять транзакций разного типа и сложности выполняются либо параллельно, либо помещаются в очередь для отложенного исполнения. База данных содержит девять типов записей, которые сильно различаются размерами. ТРСС измеряется в транзакциях в минуту (tpm).

ТРС-С моделирует реальную вычислительную среду, где группа операторов за терминалами выполняют транзакции с обращением к базе данных. Назначение теста — проверка скорости выполнения единичных операций (транзакций) в системе обработки заказов, например, таких, как прием и доставка заказов, регистрация выплат, проверка состояния заказа и контроль за наличием товаров на складе. Хотя данный тест имитирует работу оптового поставщика, ТРС-С не ограничен каким-либо конкретной отраслью, а представляет любой бизнес по продаже или распространению товаров или услуг.

Тест ТРС-D — новейший тест, определяющий эффективность широкого диапазона приложений поддержки принятия решений, где требуются сложные, долго выполняющиеся запросы к большим и сложным структурам данных. Кстати, по этой модели были написаны программы, содержащие 17 сложных запросов и примененные затем в реальном бизнесе.

Для большинства современных приложений тест ТРСС — вероятно, наилучшее средство оценки производительности. По мере дальнейшего распространения приложений поддержки принятия решений, значение теста TPCD будет расти.

В Рочестере для измерения производительности используется тест ТРСС. Он довольно сложен и требует существенной предварительной подготовки. ТРС также добивается, чтобы все результаты ее тестов были выверены, и гарантирует это с помощью сложных и многократно дублированных измерений. С одной стороны это необходимо, чтобы обеспечить воспроизводимость результатов, но с другой — мы не можем позволить себе подобный объем тестирования для всех возможных конфигураций AS/400. Поэтому мы измеряем показатели ТРСС лишь некоторых систем из нашей линейки серверов и отправляем результаты в ТРС для проверки. Именно эти показатели ТРС затем и публикует в виде сравнительного анализа производительности различных систем.

Мы хотим предоставить нашим заказчикам правдивую и точную информацию о каждой из наших систем, и поэтому в основе всех измерений, независимо от конфигурации и режимов, лежит некоторая разновидность ТРСС. Несколько лет назад мы выбрали одну из версий ТРСС в качестве постоянного теста для всех наших систем. Мы не можем публиковать эти цифры как окончательные показатели ТРС-С, так как сам ТРС-С продолжает развиваться. Взамен мы публикуем информацию, собранную на основе другой системы измерения производительности — CPW (Commercial Processing Workload). Как правило, умножение показателя производительности CPW на 10 дает грубое приближение к показателю производительности ТРС-С, хотя значения, полученные в результате реального тестирования ТРСС, обычно дают более высокий результат.

Как мы сравниваем?

Новые значения показателей производительности CPW и ТРС-С для моделей серии AS/400е публикуются с каждым новым выпуском. Мы рассмотрим их на примере версии V4R1 (август 1997 года) для 12-канальных систем. (Дело в том, что к моменту написания этой книги показатели серии AS/400е еще не были сертифицированы, и потому их нельзя рассматривать как окончательные). В таблице 12.1 даны значения производительности пяти лучших систем на момент выхода V4R1, а также моя оценка места в этом списке 12-канальной AS/400. Разумеется, и конкретные цифры, и положение систем в списке все время меняются по мере выпуска новых моделей и проведения повторных тестовых измерений.

Вы можете получить текущие показатели производительности ТРСС из ряда источников, включая узел WWW Transaction Processing Performance Council (http://www.tpc.org). Лично я предпочитаю узел WWW IDEAS International (http://www.ideasinternational.com) — компании из Сиднея (Sydney), Австралия, которая специализируется на распространении сравнительной информации о вычислительных системах по Интернету. Эта организация — член совета ТРС и принимает участие в разработке тестов. На странице WWW IDEAS International опубликованы сравнительные результаты тестов для многих систем. Я предпочитаю их Top 20 для ТРС-С.

Информация таблицы 12.1 интересна с нескольких точек зрения. Во-первых, значения для 12-канальной AS/400 во много раз выше, чем предыдущие опубликованные значения ТРС-С для любой AS/400. Теперь эта одиночная система сравнялась с самыми крупными одиночными системами IBM, считая мэйнфреймы, и уступает лишь кластерам. Вовторых, эти показатели демонстрируют эффективность и перспективность AS/400. Для наглядности давайте рассмотрим системы, превосходящие AS/400 по показателю ТРС-С.

Самый высокий показатель tpm в таблице 12.1 принадлежит 24-канальному серверу Sun Ultra Enterprise, который содержит 24 процессора UltraSPARC с тактовой частотой 250 МГц. Учитывая, что по сравнению с AS/400 в данной системе Sun вдвое больше процессоров с вдвое большей тактовой частотой, логично ожидать такого же превосходства по числу выполняемых ею транзакций. Но нет, их больше лишь на четверть. Обратите внимание на то, что 12-канальная AS/400 стоит в списке выше 16-канального сервера Sun Ultra Enterprise. Так или иначе, 24-канальная система Sun достаточно эффективна по сравнению с другими машинами из списка.

Второе место в таблице занимает 48-процессорный Digital AlphaServer, сконфигурированный как кластер из четырех 12-канальных серверов. Учитывая, что процессоры данной системы работают на тактовой частоте 350 МГц, можно сделать вывод, что это, вероятно, самая малоэффективная система в списке. От быстрых процессоров, которые большую часть времени простаивают, ожидая памяти или ввода-вывода, не слишком много толку, за исключением возможности похвастаться высокими МГц. Данная конфигурация служит прекрасной иллюстрацией тезиса, что само по себе высокое значение тактовой частоты еще ничего не дает.

На третьем месте, лишь на доли процента обгоняя AS/400, стоит 28-канальная Silicon Graphics Origin2000 Server. Как я уже упоминал, данная система примечательна тем, что лежит в основе проекта ASCI Blue Mountain. Тем не менее, она со своими 28 процессорами, имеющими частоту 195 МГц, лишь ненамного превосходит AS/400 с 12 процессорами, работающими на частоте лишь 125 МГц.

Высокие показатели коммерческого тестирования, такого как ТРСС, может дать только сбалансированная система. Мы стремимся повышать производительность процессора, памяти и подсистемы вводавывода в целом, и каждого компонента в отдельности. Высоким показателем общей производительности AS/400 обязана необычайной эффективности своих подсистем памяти и ввода-вывода.

Благодаря новой структуре памяти, AS/400 теперь использует возможности полной 64-разрядной реализации. Следующие версии этой подсистемы позволят устанавливать на AS/400 еще больше процессоров с повышенной тактовой частотой.

Наш подход остается прежним — реальную полезную производительность для деловых вычислений дает лишь сбалансированная система.

Выводы

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

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

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

По счастью, семейство систем, которое обеспечит Вам конкурентные преимущества в бизнесе без огромных расходов и перебоев в работе все же существует. За последние 15 лет по всему миру было установлено более 700 000 коммерческих систем Рочестера. Никто другой не может даже приблизиться к такому результату.

Вернемся снова к началу. Помните, слова, открывавшие лекцию 1: "Выносливость любой компьютерной системы и ее способность сохранять инвестиции, — самые важные аргументы при выборе компьютера для производства или офиса". Если это так, то AS/400 — самый успешный многопользовательский компьютер для бизнеса из всех когда-либо существовавших. А благодаря чему, все это достигнуто (все эти искусные архитектуры и новейших технологии) — так ли уж важно?