Компьютерные системы

 

4. Многоядерность:

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

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

За возрождение многоядерности на современном технологическом уровне, как и за многие другие новации, мы должны быть благодарны инженерам корпорации Digital Equipment. Именно здесь во второй половине 90-х всерьез, на промышленном уровне, задумались о многоядерности в процессорах; это произошло при переходе процессора от Alpha 21164 (EV5) к Alpha 21264 (EV6). Тогда исследователям из DEC удалось установить две важные закономерности, распространяющиеся на процессоры. Во-первых, оказалось, что для линейного роста производительности монолитных (одноядерных) процессоров требуется обеспечить квадратичный рост числа транзисторов. Во-вторых, как следствие, также нелинейно (хотя и трудно сказать, как именно) возрастет сложность проектирования. Элементарное рассуждение подсказывает, что суммирование производительности нескольких ядер даст ту же совокупную производительность, что и одно ядро при меньшем числе транзисторов. Вопрос в том, как объединить мощности отдельных ядер, в этом состоит коренная проблема многоядерности. Реакцией DEC на обнаруженные проблемы стал проект Piranha, предполагавший создание 8-ядерного процессора, где каждое ядро должно было иметь отдельную кэш-память для команд и данных, для совместной работы процессоры объединялись коммутатором. Однако после перехода в ведение Compaq проект Piranha был похоронен, процессор так и не был реализован.

Низкая эффективность  использования транзисторов, когда  большая их часть отдается схемам управления и существенно меньшая — выполнению собственно арифметических и логических операций, и, как следствие, высокое энергопотребление, стали главным тормозом на пути дальнейшего развития монолитных процессоров. Весьма наглядной иллюстрацией происходящего стало явление, получившее название «разрыв Мура» (The Moore’s gap). Сложность проектирования увеличивает время проектирования некоторых наиболее сложных процессоров до неприемлемых значений; в некоторых случаях период проектирования затягивается больше чем на десятилетие. Характерный пример — прогноз выпуска серверов архитектуры IA-64. На пороге третьего тысячелетия перспектива серверного процессора казалась многим очевидной; будущая монополия Itanium (тогда проект еще назывался Merced) не вызывала сомнения, открытым оставался лишь вопрос о времени ее появления. Практические же результаты оказались столь скромными, что дали основания скептикам с издевкой называть процессор не иначе как Itanic. Рынок серверов инерционнее рынка рабочих станций, поэтому, чтобы увидеть будущее, стоит смотреть на изменения, происходящие во втором сегменте. Примерно три-четыре года назад исчезли рабочие станции на Itanium, это явный знак судьбы этого процессора.

Параллельно с проектом Piranha группа исследователей из Стэндфордского университета во главе с Кунле Олокотуном работала над «многоголовым процессором» Hydra, весьма образно названным именем чудовища, с которым сражался Геракл. В качестве ядра использовался процессор MIPFS 4600. Работа (заметим, спонсировавшаяся агентством DARPA) дала хорошие результаты. Как обычно бывает в таких случаях, проект перевели на коммерческую основу, создали небольшую фирму Afara, которую возглавил тот же Олокотун. Впоследствии, проявив изрядную прозорливость, причем в далеко не самые простые для себя времена, Sun Mirosystems купила эту компанию и, заменив ядро MIPFS 4600 на UltraSPARC II и увеличив число ядер вдвое, выпустила экспериментальный процессор Niagara, получивший в серии наименование UltraSPARC T1.

Успеху Niagara способствовало и то, что в Sun велась собственная разработка двухъядерного процессора MAJC 5200, где каждое ядро способно обрабатывать четыре потока команд. Процессор UltraSPARC T1 является конвергенцией Hydra и MAJC 5200.

Процессоры SPARC вообще и UltraSPARC T1 в частности являются суперскалярными, а в Power от IBM еще используется метод внеочередного исполнения. Первым процессором с двумя ядрами стал Power4 (два ядра Power3), за ним последовал Power5, а на горизонте тоже двухъядерный Power6. Может показаться странным, но у IBM разработки многоядерных процессоров заметно связаны с производством игр. Так, процессор Xenon предназначен для игровой консоли, которая, как предполагается, придет на смену Xbox 360, он будет иметь три ядра PowerPC, где каждое ядро будет поддерживать два симметричных аппаратных потока. Другой проект, Cell, включает двухпотоковое ядро SMT Power и восемь ядер, которые называют синергетическими процессорными элементами (Synergistic Processing Element, SPE), работающими по принципу SIMD. Основное ядро Power выполняет команды из системы команд PowerPC, поддерживая специализированную систему команд SPE. С очевидным опозданием свои предложения сделали корпорации AMD и Intel: борьба на многоядерном поле стала и для производителей процессоров архитектуры x86 одним из самых актуальных вопросов сегодняшнего дня.

 

8. Что такое векторизация?

В самом широком смысле векторизация – это преобразование операций, выполняемых по ходу процесса решения задачи, из скалярной традиционной формы в векторную.

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

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

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

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

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

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

 

16.   Основные особенности несимметричных  мультипроцессорных систем:

           В  несимметричной  мультипроцессорной системе типа CC-NUMA:

• оперативная память является логически общей (с единым адресным пространством), но физически распределенной. Это означает, что отдельные части оперативной памяти физически закреплены за каждым процессором.
• каждому  процессору системы доступна любая ячейка оперативной памяти командами Load и Store;
• время доступа процессора в локальную (т.е., закрепленную за данным процессором) область  оперативной памяти и в «чужие» области (т.е. области оперативной памяти, закрепленные за другими процессорами)  различно;
• по способу выполнения функций операционной системы каждый процессор может выполнять любые процедуры операционной системы, в том числе и по управлению вводом-выводом;
• все процессоры идентичные.

Типичная структура  несимметричной МВС приведена на рис. 1.

 

     Рис. 1 – Типичная структура несимметричной МВС

 

          Проще всего охарактеризовать NUMA-МВС, представив себе большую симметричную МВС, разделенную пополам, причем половинки связаны кабелем, подключенным к системным шинам, и каждая половинка включает собственную оперативную память и подсистему ввода-вывода. Это и есть NUMA-МВС: большая симметричная МВС, разбитая на набор более мелких и простых симметричных МВС. В подобной структуре  процессор и локальные модули оперативной памяти тесно интегрированы, следовательно, скорость доступа к локальной оперативной памяти гораздо выше, чем к оперативной памяти «соседнего» процессора. Подсистемы ввода-вывода могут быть частью каждого узла или сосредоточены в выделенных узлах.

         Узлы могут состоять из небольшого числа (2-8) процессоров, соединенных между собой какой-либо высокоскоростной подсистемой коммутации. Соединение узлов между собой, как правило, осуществляется более медленной (по сравнению с подсистемой коммутации процессоров в узле) подсистемой коммутации. Количество процессоров в узле не очень существенно для понимания того, как МВС работает, поэтому в дальнейшем будем предполагать, что в узле имеется один процессор. Рассмотрим, каким же образом обеспечивается обращение в оперативную память при выполнении команд Load и Store. В МВС имеется одно адресное пространство, распространяемое на все узлы. Реальный (не виртуальный) адрес 0 для каждого процессора в любом узле соответствует адресу 0 в локальной оперативной памяти узла 0; реальный адрес 1 для всей системы  - это адрес 1 в узле 0 и т.д., пока не будет использована вся оперативной память узла 0. Затем происходит переход к оперативной памяти узла 1, затем узла 2 и т.д. Если команда, например,  Load  обращается к ячейке оперативной памяти с адресом, попадающим в локальную память узла, то выполнение команды традиционно. Проверяется наличие данных в кэше первого уровня. При удачном исходе происходит быстрое обращение. Если же информация в кэше первого уровня отсутствует, то происходит обращение к кэшу второго уровня. При удачном обращении время получения данных несколько больше по сравнению с удачным обращением в кэш первого уровня, но значительно меньше, чем время обращения в оперативную память. При неудачном поиске информации в кэш-памятях всех уровней, происходит обращение в локальную память узла. В каждом узле имеется специальная аппаратура (назовем ее условно модуль удаленных обращений – МУО), которая обеспечивает  получение данных из «чужого» узла, причем этот «чужой» узел может быть расположен достаточно далеко от запрашивающего узла.

            Рассмотрим пример выполнения в узле А команды Load с адресом М, который принадлежит пространству адресов локальной оперативной памяти узла В. В этом случае МУО узлов А и В должны выполнить следующую последовательность действий:

МУО узла А:

- по старшим разрядам адреса определяет номер «чужого» узла В;

- формирует обращение  к МУО этого «чужого» узла В;

- выдает обращение в подсистему коммутации узлов;

МУО узла В:

- принимает заявку;

- читает данные из локальной оперативной памяти узла В;

- формирует ответное сообщение с запрошенными данными;

- передает сообщение в подсистему коммутации узлов;

МУО узла А принимает данные и выдает необходимую порцию в процессор узла А.

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

     Ключевым вопросом является то, насколько "неоднородна" NUMA или CC-NUMA-МВС? Например, если для чтения данных  из другого узла требуется только на 10% большее время, то это, практически, несущественно. В этом случае все будут относиться к системе как к симметричной МВС, и разработанные для  симметричных МВС программы будут выполняться достаточно хорошо.

     В действительности на рынке имеются системы,  время  доступа к оперативной памяти в другом узле составляет от 1.1-1.5  до нескольких единиц  времени доступа к ячейке локальной оперативной памяти.

    Как правило, NUMA МВС не выдерживают правила 1.1. Например:

 МВС серии Origin 2000 компании Silicon Graphics обеспечивали замедление в 2-3 раза;

 МВС NUMA-Q компании Sequent давали  замедление в 7,5 раз и даже больше при сильной загрузке;

 МВС  NUMALiiNE компании Data General давала еще большее замедление, чем NUMA-Q.

          При такой разнице в скорости доступа к оперативной памяти для обеспечения должной эффективности в NUMA МВС следует позаботиться о правильном расположении требуемых данных. Чтобы этого добиться, нужно соответствующим образом модифицировать операционную систему. Например, такая операционная система при запросе из программы блока оперативной памяти выделяет оперативную память в узле, в котором выполняется эта программа, так, что когда процессор ищет соответствующие данные, то находит их в своем собственном узле. Аналогичным образом должны быть изменены подсистемы (включая СУБД), осуществляющие собственное планирование и распределение оперативной памяти (что и сделали  СУБД Oracle и Informix). Такие изменения позволяют эффективно выполнять в системах с структурой NUMA приложения, разработанные для симметричных МВС, без потребности изменения кода.