`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Fleet – двадцать с лишним лет… революции

Статья опубликована в №29 (695) от 25 августа

+44
голоса

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

Fleet – двадцать с лишним лет… революции
1963 г. Айван Сазерленд демонстрирует работу графической системы Sketchpad

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

В 1988 г. Ассоциацией вычислительной техники (Association for Computing Machinery, ACM) за выдающиеся успехи в области компьютерной графики Айвану Сазерленду (Ivan Satherland) была присвоена считающаяся ИТ-аналогом Нобелевской премия имени Алана Тьюринга. По традиции ACM на торжественном вручении награды каждый лауреат выступает с докладом, и в начале 1989 г. Сазерленд представил элите теоретической вычислительной техники (computer science) несколько неожиданную для своей специализации работу «Микроконвейеры» (Micropipelines). Собственно, с нее и начинается вся история. И наша первая очевидная попытка реконструкции недостающих деталей. Ни один серьезный ученый не станет выступать перед сверхавторитетной аудиторией с чем-то по ходу дела набросанным «на коленке». Это неоспоримый факт. Следовательно, доклад Сазерленда содержит плоды его серьезной работы, которыми он гордился. Что означает – описываемая история началась раньше 1989 г. И сейчас ей навскидку уже больше двадцати лет. То есть мы заглядываем во времена, когда британская Apricot (кто о ней сейчас помнит?) только готовилась выпустить первый серийный ПК стоимостью более 12 тыс. долл. (!) с еще «сырым» процессором i486, когда Amiga с CPU M68030 была мощной графической станцией, ну и, само собой, когда доллар стоил «несколько» больше нынешнего. Именно тогда Айвана Сазерленда заинтересовала конвейерная архитектура: «Процессоры конвейерной архитектуры обеспечивают высокую производительность благодаря разделению процесса обработки на независимые этапы... Несмотря на то что проектирование конвейерных архитектур – ответственная и сложная задача, они широко используются в графических и цифровых сигнальных процессорах, арифметико-логических устройствах и в декодерах команд вычислительных систем общего назначения» (доклад Сазерленда можно легко найти, например на странице fleet.cs.berkeley.edu/docs/, кроме того, наш журнал не раз публиковал материалы и о самом Айване Сазерленде). Сочетая скрупулезность ученого и конкретику инженера-схемотехника, Сазереленд в докладе «разбирает по косточкам» конвейеры как элемент архитектуры. Он классифицирует их по двум основным признакам – характеру управления и «эластичности». В первом случае конвейер, как и любая цифровая логическая схема, может быть или тактируемым, или управляемым событиями – с этим более или менее все понятно, подавляющее большинство нашей сегодняшней цифровой электроники относится к тактируемым схемам, работающим синхронно с сигналом тактовой частоты, управляемые же непосредственно событиями в схеме (асинхронные) устройства – по сей день большая редкость. А вот «эластичность» – понятие, требующее пояснения. Неэластичный конвейер характеризуется некоторой емкостью – количеством объектов, которые надо подать на его вход для того, чтобы хоть один объект достиг выхода, а также последующим (после заполнения) равенством скоростей подачи объектов в конвейер и выдачи их с него. Например, традиционная сборочная линия, на которой выполняют операции N работников. Пока N объектов не пройдет через их руки, на выходе конвейера ничего не будет, затем (в идеале), если на вход будет подано M объектов в час, на выходе также за час будет получено ровно M объектов, что означает – мы говорим о неэластичном конвейере емкости N. Эластичный же конвейер уникален и тем, что скорости подачи объектов в него и выдачи из него могут не совпадать, и тем, что ожидающему результатов работы конвейера нет нужды дожидаться полного его заполнения N объектами. В цифровой технике точным аналогом неэластичного конвейера является сдвиговый регистр, в который надо предварительно «затолкать» N битов или слов, чтобы первый из записанных в него появился на его выходе, а эластичного – аппаратная очередь FIFO (First In First Out), обычно реализуемая с помощью двухпортовой памяти, в ней даже единственный помещенный в порт записи объект можно сразу или сколь угодно позже получить из порта чтения. Так вот, предметом пристального внимания Сазерленда во второй половине 80-х годов стали названные им «микроконвейерами» простые цифровые схемы управляемых событиями (асинхронных) эластичных конвейеров, предназначенные не для обработки данных, а исключительно для их передачи. Мотивация такого интереса достаточно очевидна – по сути, микроконвейеры являются этакими уникальными «цифровыми проводами со встроенной буферной памятью», что позволяет их использовать для связи совершенно независимых блоков сложных цифровых устройств. А, как известно, принцип «разделяй и властвуй» – один из самых эффективных приемов в борьбе со сложностью в задачах проектирования. Да, в конце 80-х годов прошлого века сложность процессоров класса i486 казалась очень высокой...

Fleet – двадцать с лишним лет… революции
Айван Сазерленд, 2009 г.

С 1990 г. Сазерленд стал членом научного общества и вице-президентом корпорации Sun, где продолжил работу над архитектурой сверхбольших интегральных схем. И вот по прошествии почти двадцати лет мы фактически оцениваем ее результаты – уже доведенный до материализации реально работающий «в кремнии» прототип процессора архитектуры Fleet: 22 июня этого года произведены получившие кодовое название MARINA первые микросхемы. Естественно, в них используется и идея микроконвейеров, более того – она является основой архитектуры. Потому особенно интересна трансформация мотивации архитектурных симпатий Сазерленда за прошедшие годы: рост степени интеграции серийно выпускаемых микросхем отставил далеко на второй план вопросы сложности проектирования, зато потребности технологов и... бизнесменов (да, именно бизнесменов) стали приоритетными. И первых и вторых, по сути, в полупроводниковом производстве волнует один ключевой фактор – площадь кристалла. Потому что чем меньше площадь кристалла, тем выше выход годной продукции и быстрее возврат инвестиций (на самом деле, конечно, и нас, потребителей, все это волнует ничуть не меньше, так как в конечном счете определяет доступность электроники). Но снижать площадь кристалла при заданной функциональности и производительности микросхемы можно только двумя способами – или уменьшением технологических норм (это баснословно дорого), или «архитектурными играми» на прокрустовом ложе традиционной тактируемой двоичной логики. Айван Сазерленд же предлагает вспомнить, что на заре вычислительной техники было дорогим, а что – дешевым. А именно, логику и провода. Во времена дискретных элементов цифровая логика была очень дорогой, провода – очень дешевыми. Теперь же мы сталкиваемся с полностью противоположной реальностью – цифровая логика сверхбольших микросхем фактически ничего не стоит, но вот «провода», на которые в тактируемых схемах тратится прямо и косвенно весьма немаленькая часть площади кристалла, они уже обходятся очень дорого. Действительно, в тактируемых схемах необходимо прибегать к массе ухищрений для компенсации задержек тактовых сигналов, для обеспечения принципиальной совместной работоспособности узлов с разными тактовыми частотами etc. Добавьте к этому еще и жесткие современные требования к энергоэффективности, вынуждающие конструкторов городить сложные (и потому не очень надежные) схемы отключения незадействованных узлов, восстановления синхронизации их работы после включений и прочее, прочее. Потому Сазерленд сегодня предлагает строить оптимально использующие площадь кристалла и потребляющие энергию полностью асинхронные процессоры архитектуры Fleet, в которых применяются только «цифровые провода с буферной памятью».

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

Дальше – больше. Второй фундаментальный элемент дизайна традиционных процессоров – тактовая частота. И хоть мы уже не судим по ее значению о производительности, все равно для разных машин одной архитектуры правило «выше тактовая частота – выше производительность» работает. Но не для Fleet. Потому что никакой тактовой частоты у этих машин нет. Они принципиально асинхронны, причем настолько, что в ходе эволюции их архитектуры даже пришлось эту асинхронность немного «укротить» (впрочем, об этом позже).

Следующая особенность Fleet для читателей нашего журнала уже не является неожиданностью – мы рассказывали о машинах всего с одной командой, в том числе с инициацией операций переносом данных (TTA, ko-online.com.ua/node/40756). Именно к семейству таких макроархитектур и относится Fleet, реально «умеющая» исполнять только команду пересылки данных MOVE.

И наконец, еще одна важнейшая деталь. В традиционных процессорах, хоть бы и мультиядерных, последовательность действий является фундаментом, на котором строится все. В том числе и «параллелизм». Который, по сути, реализуется каким-либо методом объединения последовательных фрагментов, исполняемых разными вычислителями. Во Fleet же все совершенно наоборот. В этой архитектуре параллелизм – основа основ всего. А вот последовательность... С ее реализацией вообще возможны проблемы.

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

Fleet – двадцать с лишним лет… революции
Кристалл микросхемы MARINA, первого процессора Fleet-архитектуры

Увы, в этой истории, как в детской сказке – чем дальше, тем страшнее. Потому что в обильной документации архитектуры Fleet сохраняется, так сказать, дух тотальной асинхронности и нет единого подхода даже к порядку ее описания. Основу архитектуры составляет коммутационное полотно (switch fabric), которое с учетом старательно соблюдаемого разработчиками негласного правила выбора морских названий лучше было бы все-таки именовать океаном маршрутов. Это ориентированная на передачу от источника к потребителю пакетов данных сеть, гарантирующая надежность и сохранение последовательности при доставке. В текущей реализации Fleet в этом «океане» возможны по 64 «пристани» источников и потребителей пакетов данных. В отличие от реальных пристаней, «корабли» Fleet возят свои «пристани» на себе. Увы, именно такая терминология (Dock – для пристаней, Ship – для кораблей) интенсивно используется в описаниях архитектуры и, как справедливо замечают многие, ясности им не добавляет. Так что мы постараемся без всех этих мореходных терминов обойтись. Итак, коммутатор пакетов Fleet позволяет надежно с сохранением порядка следования доставлять пакеты от адреса-источника адресу-потребителю. В этой особенности легко узнать те самые любимые Сазерлендом микроконвейеры – действительно, каждое создаваемое с помощью коммутатора пакетов соединение источника с потребителем является микроконвейером. Для адресации источника и потребителя в текущей версии используется по 6 битов, так что один пакет образуется парой этих адресов и передаваемым машинным словом. Каждый источник и потребитель на самом деле является входом или, соответственно, выходом некоторого выполняющего какое-то действие модуля. Например, у сумматора должны быть два входа (адреса потребителей, принимающих операнды) и один выход (адрес источника для результата сложения), у модуля чтения внешней памяти – один вход (6-битовый адрес потребителя, принимающего адрес ячейки во внешней памяти) и один выход (адрес источника для чтения результата доступа к внешней ячейке памяти). Соответственно, соединяя с помощью коммутатора пакетов источники и потребители разных модулей, можно заставить Fleet выполнять разнообразные действия. Это очевидно. И на этом, пожалуй, очевидность заканчивается. Потому что начинаются детали и нюансы, в которых легко, как в океане, утонуть. Начнем с реализующих разнообразную логику модулей. У всех них, естественно, должны быть входы и выходы, конструкции которых в рамках архитектуры Fleet стандартизированы. В отличие от портов ввода-вывода традиционных цифровых устройств, чаще всего играющих роль согласователей уровней напряжений или нагрузочных способностей, входы и выходы модулей Fleet – самостоятельные весьма хитроумные машины. Во-первых, каждый вход и выход на самом деле разделен на три канала – один для данных, второй – для инструкций, третий – для новых пар адресов источник-потребитель. Во-вторых, если каналы данных и адресных пар – это просто регистры-защелки, способные хранить требуемой длины битовое слово, то канал инструкций – опять любимый Сазерлендом асинхронный эластичный конвейер на базе FIFO. В-третьих, канал инструкций управляет поведением каналов данных и адресных пар. В-четвертых, так устроен каждый порт ввода и вывода каждого обрабатывающего модуля Fleet-архитектуры. При максимальном упрощении все это строилось с одной целью – обеспечить функционирование асинхронности работы узлов Fleet так, чтобы каждый модуль автоматически исполнял команду только тогда, когда для нее готовы входные данные (на выходах других модулей), а коммутатор пакетов «загонял» их в микроконвейеры только по мере готовности необходимых для них данных на выходах модулей. Выглядящая так привлекательно на бумаге полная асинхронность в проекте Fleet обернулась двумя весьма неожиданными вещами. Так, например, оказалось, что человеческий мозг просто не в силах справиться с программированием такой конструкции, и в асинхронность пришлось внести некоторые коррективы, например, дать возможность программисту формировать специальные команды-сообщения, несущие только информацию о каком-либо событии. Ну и само собой, простая на бумаге идея обросла таким количеством деталей и нюансов, что сам Айван Сазерленд, автор замечательного эссе «Технология и храбрость» (Technology and courage), говорит о ней больше как о платформе для отработки идей, чем о завершенном промышленном изделии. И все же. Fleet уже существует. И создание ее – это настоящая храбрость.

+44
голоса

Напечатать Отправить другу

Читайте также

Очень познавательная статья. Спасибо автору

Если не ошибаюсь, в 80-ые годы прошлого века микроконвейерной архитектурой в Киеве в Институте кибернетики им.В.М.Глушкова занимались отделы Ю.В.Капитоновой и А.А.Летичевского. А еще был проект суперкомпьютера 5 поколения в Японии в то же время.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT