CC BY
68
для каждого t из 1..T:
(N(w,t)+d)-N(r,t)<RegFor[vr,t] для каждого t из 1..T:
сумма по всем vr: RegFor[vr,t]<AllReg
Важно отметить, что, во-первых, формулировка для линейного участка получается просто исключением всех дистанций; во-вторых, переменные RegFor не обязательно определять целыми; в-третьих, полученная формулировка содержит примерно вдвое больше переменных, чем раньше (количество переменных N[i,t] и RegFor[vr,t] одного порядка), в результате потребуется больше времени на решение ЦЛП-задачи. Поэтому оправдан гибридный подход, когда потребность в регистрах на каждом такте рассчитывается как сумма по-старому рассчитанной потребности зависимостей с уникальными виртуальными регистрами и суммы значений RegFor по тем виртуальным регистрам, которые читаются несколькими командами.
В заключение кратко охарактеризуем полученные результаты. Реализация описываемого подхода подключена к компилятору gcc как альтернатива эвристическому алгоритму SMS. Расчеты производились для целевой архитектуры MIPS, точнее для RM7000 с сокращенным числом регистров, для того чтобы дефицит регистров проявил различия между разными методами их учета.
Для решения задач ЦЛП использовались свободно доступные солверы: GLPK (см.: http://www.gnu. org/software/glpk) с настройками: по умолчанию и с использованием алгоритмов, основанных на отсечениях, пакеты lp_solve и cbc (из проекта COIN-OR).
В качестве тестовых примеров использовались в основном внутренние циклы вычислительных алгоритмов, работающих с комплексными числами. Как и следовало ожидать, гибридный подсчет регистров, как правило, дешевле, чем подсчет по всем виртуальным регистрам. Также, по-видимому, оправдано определять переменные RegFor непрерывными (не-
целочисленными). А добавление в формулировку необходимого условия для ускорения получения отрицательных результатов не вполне оправдывает ожидания, но и большого вреда не приносит.
Далее сравнивались формулировки с разными минимизируемыми целевыми функциями: глубина конвейеризации, длина пролога, и сложная целевая функция, равная сумме удвоенной глубины конвейеризации, длины эпилога, деленной на общее число команд, и максимума потребностей зависимостей в физических регистрах.
Как и ожидалось, минимизация длины пролога -самая дешевая целевая функция, но вообще отличия не слишком велики. Важно отметить закономерность, проявляющуюся для всех солверов, формулировок и тестовых примеров: в большинстве случаев отрицательные результаты получаются быстро, исключение - количество тактов на 1-2 меньше минимально достаточного, когда солверу может потребоваться значительное время. При этом решение для минимального числа тактов, для которого оно существует, находится существенно быстрее (исключением может быть солвер GLPK с настройками на использование отсечений). Это означает, что в практических целях оправдан запуск солвера без использования дорогих настроек и ограниченный небольшим временем - если расписания не нашлось быстро, значит его, скорее всего, и нет для данного числа тактов.
Среди солверов предпочтительнее других выглядит cbc. Настройка GLPK на использование отсечений иногда полезна для получения отрицательного результата, но часто вредит при получении положительных результатов.
Автор выражают глубокую благодарность всем разработчикам компилятора gcc и пакетов для решения ЦЛП-задач: GLPK, lp_solve, cbc/clp из проекта COIN-OR.
ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ПРОТОКОЛА ETHERNET-ЧEPEЗ-RAPIDIO
А.Н. Павлов (Москва)
В статье описана реализация протокола Ethernet-через-RapidIO (далее - rionet), обсуждаются его достоинства и недостатки. Протокол разработан в компании MontaVista; поддержка протокола входит в ядро ОС Linux, начиная с версии 2.6A5-git6 (http://lwn. net/Articles/139118/), драйвер протокола распространяется на условиях лицензии GNU GPL версии 2.
Интерфейс RapidIO представляет собой пакетную коммутируемую шину типа «точка-точка». Стандарт RapidIO охватывает физический, канальный, сетевой и транспортный уровни модели OSI [1]. Узлы шины RapidIO ведут обмен через среду передачи данных, сформированную коммутаторами; каждый узел RapidIO (в частности процессор), подключен к коммутатору, коммутаторы соединены ме-
жду собой. Каждый узел RapidIO может посылать сообщения размером до 4 КБ любому другому узлу RapidIO.
Узлы шины идентифицируются с помощью числового идентификатора (ID), который может принимать значения 0-255 (для малых систем) или 0-65535 (для больших систем). Перечисленные свойства шины RapidIO позволяют использовать пакеты RapidIO для передачи кадров Ethernet. На некоторых узлах RapidIO может быть запущено программное обеспечение (драйвер), реализующее протокол rionet. В дальнейшем такие узлы будем называть узлами сети rionet, или просто узлами rionet.
Драйвер для обмена по шине RapidIO rionet использует вызовы драйвера контроллера RapidIO и не
Поля пакета физического уровня RapidIO для интерфейса 8/16 LP-LVDS
tt ^Л заГ0л0Ш>к ■полп транспортного поля логического контрольная сумма
00 ^ \ tt | ftype | уровня 2 байта/ 2 байта уровня 4 байта CRC16
Поля пакета ^ логического уровня RapidIO
srcTID
info msb
info lsb
4 бита
8 бит
8 бит
8 бит
8 бит
H
поля физического уровня К.ар1ёЮ
- поля транспортного уровня RapidIO
- поля логического уровня RapidIO
Рис. 1
привязан к аппаратуре.
Для передачи сообщений стандарт предусматривает два типа транзакций:
• DOORBELL (type
10) - позволяет передать сообщение длиной 2 байта;
• MESSAGE (type
11) - позволяет передать сообщение длиной до 4 КБ.
Предполагается, что перед активацией драйвера rionet была произведена инициализация шины RapidIO, всем узлам шины RapidIO были назначены ID; в памяти каждого узла rionet хранится конфигурация шины RapidIO (в частности, узлу известны ID всех остальных узлов шины RapidIO).
Для поддержания на каждом узле корректной информации о состоянии сети rionet используются транзакции типа DOORBELL. На каждом узле rionet драйвер ведет таблицу активных узлов rionetact. При старте драйвера, производится рассылка пакетов типа DOORBELL, содержащих признак присоединения к сети (RIONET_DOORBELL_JOIN), всем узлам шины RapidIO. Узел, на котором работает драйвер rionet, получив такой пакет, отмечает в своей таблице rionetact отправителя пакета как активный узел rionet и посылает ответный пакет типа DOORBELL, содержащий признак RIONET_DOORBELL_JOIN.
Желающий прекратить свою работу в сети rionet узел посылает всем узлам, содержащимся в таблице rionetact, пакет типа DOORBELL, содержащий признак отсоединения от сети RIONET_DOORBELL_ LEAVE. Узел, на котором работает драйвер rionet, получив такой пакет, исключает отправителя из своей таблицы rionetact.
Поля пакета типа DOORBELL показаны на рисунке 1. На этом и всех последующих рисунках показаны форматы пакетов шины RapidIO, построенной на основе физического интерфейса 8/16 LP-LVDS. Предполагается, что используется шина RapidIO c малым (до 256) числом узлов (поле пакета tt имеет значение 00, узлы шины RapidIO адресуются с помощью однобайтовых ID).
Процесс передачи пакета типа DOORBELL по шине RapidIO происходит следующим образом: на первом шаге узел-отправитель (Requestor) посылает пакет узлу-получателю (Destination); на втором шаге, узел-получатель отсылает подтверждение приема пакета (пакет типа 13), содержащий признак успешной/неуспешной передачи. Такая процедура гарантирует доставку пакетов типа DOORBELL.
Драйвер rionet использует транзакции типа MESSAGE для передачи кадров Ethernet. Кадр Ethernet передается в пакете RapidIO в формате big-endian. Сообщения, размер которых превышает 256 байтов, фрагментируются передающим контроллером RapidIO на пакеты, содержащие не более 256 байтов, и в таком виде пересылаются по шине. Контроллер-получатель пакетов формирует из фрагмен-
тов исходное сообщение на основании содержимого полей msglen и msgseg.
Фрагментация пакетов абсолютно прозрачна для драйвера контроллера RapidIO. Таким образом, максимальный размер кадра Ethernet может достигать 4096 байтов, а размер упакованной в такой кадр дейтаграммы IP (MTU) - 4082 байта.
На рисунке 2 показана инкапсуляция кадров Ethernet в пакеты типа MESSAGE при MTU=4082 байта (при этом один кадр Ethernet размером 4096 байтов передается с помощью 16 пакетов RapidIO).
Процесс передачи сообщения по шине RapidIO происходит следующим образом: на первом шаге узел-отправитель Requestor посылает пакет узлу-получателю Destination; на втором шаге, узел-получатель отсылает подтверждение приема пакета (пакет типа 13), содержащий признак успешной/неуспешной передачи.
Если при отсылке производилась фрагментация сообщения, то для каждого фрагмента отсылается отдельное подтверждение. Такая процедура гарантирует доставку сообщений через шину RapidIO.
Эмуляция интерфейса Ethernet означает, что необходимо эмулировать и MAC-адреса, используемые в Ethernet. По умолчанию, байты MAC-адреса назначаются так, как указано в таблице 1.
Таблица 1
Строение MAC-адреса rionet
Номер байта 0 1 2 3 4 5
Содержимое 00 01 00 01 id[15:8] id[7:0]
Примечание: id[15:0] — ID узла
В момент передачи IP-дейтаграммы через rionet, встает задача определения MAC-адреса узла-получателя на основании его IP-адреса.
В таких сетях, как Ethernet, для решения этой задачи используется протокол ARP. Узел, который готов направить пакет через сеть Ethernet, желая определить MAC-адрес получателя на основе его IP-адреса, посылает ARP-запрос, используя широковещательный MAC-адрес, и ожидает ответ, содержащий искомый MAC-адрес.
Базовая реализация RapidIO не имеет средств для организации широковещательных рассылок. Протокол rionet решает данную проблему следующим образом: драйвер ведет таблицу rionetact, в которой хранятся ID всех активных узлов rionet.
При поступлении от ARP-протокола запроса на широковещательную передачу пакета драйвер rionet
Поля кадра Ethernet
type | daddr | saddr | Дейтаграмма IP
2 байта 6 байтов 6 байтов 4082 байта
Рис. 2
имитирует широковещательную рассылку - индивидуально посылает указанный пакет каждому активному узлу rionet.
Для того чтобы снизить нагрузку на шину со стороны многочисленных ARP-запросов, необходимо обеспечить эффективный механизм кэширования ARP-запросов. Другим способом снижения нагрузки на шину может быть использование многоадресного расширения шины RapidlO.
В таблице 2 приведен расчет размера одного фрагмента шестнадцатифрагментного сообщения шины RapidlO Smp, инкапсулирующего кадр Ethernet размером 4096 байтов (размер IP-дейтаграммы, содержащейся в кадре Ethernet MTU=4082 байта).
Таблица 2
Расчет размера фрагмента сообщения (пакет типа 11)
Уровень; поля пакета Размер, байт
Физический: - заголовок - предварительная контрольная сумма (КС)* - КС 2 2 2
Транспортный 2
Логический: - поля типа 11 - данные - фрагмент кадра Ethernet 2 256
Итого, Smp 266
* предварительная КС рассчитывается для всех пакетов, размер которых превышает 80 байтов.
Всего таких фрагментов п будет передано 16 (п=16), после приема сообщения будет выслан пакет-подтверждение, расчет размера которого 8ге8 приведен в таблице 3.
Таблица 3
Расчет размера пакета-подтверждения (пакет типа 13)
Уровень; поля пакета Размер, байт
Физический:
- заголовок 2
- КС 2
Транспортный 2
Логический 2
Итого, $ге5 8
Таким образом, для передачи IP-дейтаграммы размером MTU=4082 байта через rionet необходимо передать по шине RapidlO Srio байтов:
Srio = n(Smp + Sres) = 16 • (266 + 8) = 4384.
Эффективность использования шины е: MTU = 4082 и 0,93.
Srio 4384
Описанный протокол rionet обладает следующими достоинствами:
• прозрачность для программного обеспечения: для пользователя сетевые интерфейсы rionet выглядят так же, как привычные Ethernet-интерфейсы;
• простота развертывания: для создания сети rionet на основе существующей инфраструктуры RapidlO достаточно установить драйвер rionet.
Инкапсуляция кадров Ethernet в пакеты шины RapidlO имеет ряд недостатков, связанных с принципиальными различиями RapidlO и Ethernet:
• Ethernet может терять пакеты, RapidlO - нет;
• Ethernet позволяет подключать и отключать абонентов в любой момент, RapidlO - нет;
• организация широковещательной рассылки в RapidlO не так проста, как в Ethernet.
На первый взгляд, масштабируемость rionet целиком определяется возможностями масштабирования шины RapidlO. Параллельный интерфейс 8/16 LP-LVDS позволяет соединить несколько десятков узлов RapidlO в рамках одного крейта. Применение последовательного интерфейса 1x/4x LP-Serial позволяет соединить между собой отдельные крейты, удаленные друг от друга на несколько десятков метров, в единую шину RapidlO, содержащую несколько десятков тысяч узлов.
Однако если количество абонентов rionet велико, то при старте системы произойдет всплеск трафика на шине RapidlO, связанный с тем, что каждый узел сети будет пытаться оповестить остальных о своем существовании. При количестве узлов rionet, равном n, будет послано 2n2 пакетов типа DOORBELL.
Использование протокола ARP в сети rionet нерационально. В сети Ethernet при запросе MAC-
адресу будет передано два пакета: широковещательный пакет-запрос и пакет-отклик. В сети rionet, состоящей из n узлов, будет передано n+1 пакетов: n пакетов-запросов (соответствующих широковещательному пакету-запросу Ethernet) и один пакет-отклик.
В rionet используется прямое соответствие между ID RapidIO и MAC-адресами Ethernet, однако в каждом пакете RapidIO одновременно передаются как ID, так и MAC-адреса, указанную избыточную передачу сетевых идентификационных кодов следует отнести к недостаткам протокола. Протокол rionet
подходит для передачи кадров протокола Ethernet между процессорами, соединенными шиной RapidIO, однако область применения rionet ограничена системами, содержащими около десятка процессоров.
Для создания эффективной сетевой среды на базе шины RapidIO необходима доработка имеющегося протокола или разработка нового.
Литература
1. RapidlO(TM) Interconnect Specification [Электронный ресурс].- Электрон. текстовые, граф. дан.- RapidIO Trade Association, 2005.- Ч. 1-4, 11; приложение 1.- http://www.rapi-dio.org
СОБЫТИЯ В СИСТЕМЕ X WINDOW
С.Г. Романюк (Москва)
В статье "В поисках серебряной пули" Фредерик П. Брукс сравнивает проекты по созданию программного обеспечения с оборотнями из сказок, внушающими особый ужас: притворяясь чем-то знакомым и обыденным, они способны внезапно обращаться в чудовищ, пожирающих бюджет, время и другие ресурсы, а получающаяся в результате реализации проекта система обладает невероятным количеством изъянов (http://www.apl.jhu.edu/Classes/635431/ felikson/Publications/No_Silver_Bullet_Brooks.htmí). Убить оборотня можно, как известно, только волшебной серебряной пулей, однако ее поиски до сих пор не увенчались успехом. По мнению Брукса, все дело в том, что наиболее трудная и значительная по объему работа в программировании заключается в составлении спецификаций, разработке и проверке программы как концептуальной конструкции, но работа эта остается, как правило, невыполненной. "Мы, конечно же, делаем синтаксические ошибки, но они - ничто по сравнению с ошибками концептуальными", -замечает Брукс. Исправление концептуальных ошибок означает, как правило, полную переработку системы, поэтому о них предпочитают умалчивать, когда речь идет о системе давно эксплуатируемой.
В интерактивной системе имеется два действующих лица: программа (программы), исполняющаяся на ЭВМ, и человек (оператор), наблюдающий результаты работы программы на экране и влияющий на ход ее исполнения посредством устройств ввода (обычно это клавиатура и указывающее устройство типа "мышь"). Как результаты работы программы (например, "на экране высвечено окно"), так и последствия действий оператора (например, "нажата клавиша") можно охарактеризовать одним и тем же словом СОБЫТИЕ.
Слово "событие", как и многие другие термины, имеет двоякий смысл: первый - общепринятый, "житейский", и второй - специальный, который должен согласовываться с первым.
С общежитейской точки зрения, "событие" - это, во-первых, нечто важное, а во-вторых, наступающее в определенный момент времени (например: начало столетней войны, рождение ребенка, срабатывание
сигнализации, запись числа в регистр вещественной арифметики). Время наступления события фиксируется с некоторой точностью: это может быть год, день, секунда или машинный такт. Указанными двумя свойствами исчерпывается общая семантика слова "событие".
Что считать событием в интерактивной системе, решают ее разработчики. Обсудим решения, принятые разработчиками системы X Window.
Система состоит из двух основных компонентов: дисплейного сервера (или просто сервера) и библиотек функций, предназначенных для создания прикладных графических программ, называемых клиентскими. Эти библиотеки называют также "клиентскими", или "клиентскими библиотеками X Window", чтобы отличать их от других библиотек языка программирования Си. Базовая клиентская библиотека называется Xlib, ни одна клиентская программа не может обойтись без обращения к функциям этой библиотеки, непосредственного или косвенного (через функции других клиентских библиотек, более высокого уровня).
Сервер и клиентские программы могут исполняться либо на одном и том же процессоре - и тогда они запускаются как отдельные процессы UNIX, -либо на разных процессорах, входящих в некоторую сеть ("сетевая прозрачность").
Между сервером и каждой клиентской программой существует соединение, которое устанавливается по инициативе клиентской программы вызовом функции XOpenDisplay библиотеки Xlib. При вызове других функций библиотеки Xlib по установленному соединению клиентская программа направляет серверу запросы, например, запрос на высвечивание окна, на рисование многоугольника или на вывод строки текста. Сервер выступает в роли посредника между клиентскими программами и графической аппаратурой. Он выполняет фактический вывод данных на экран по запросам, поступающим от клиентских программ, и воспринимает сигналы от устройств ввода (обычно это клавиатура и указывающее устройство), возникающие в результате действий пользователя (оператора).
