* всегда актуальные вопросы, на что стоит обращать внимание при выборе процессора, чтобы не ошибиться.

Наша цель в данной статье — описать все факторы влияющие на производительность процессора и другие эксплуатационные характеристики.

Наверняка ни для кого не секрет, что процессор – является главной вычислительной единицей компьютера. Можно даже сказать – самая главная часть компьютера.

Именно он занимается обработкой практически всех процессов и задач, которые происходят в компьютере.

Будь то — просмотр видео, музыка, интернет сёрфинг, запись и чтение в памяти, обработка 3D и видео, игр. И многого другого.

Поэтому к выбору Ц ентрального П роцессора, стоит отнестись очень тщательно. Может получиться ситуация, что вы решили поставить мощную видеокарту и не соответствующий её уровню процессор. В этом случае процессор, не будет раскрывать потенциал видеокарты, что будет тормозить её работу. Процессор будет полностью загружен и буквально кипеть, а видеокарта будет ожидать своей очереди, работая на 60-70% от своих возможностей.

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

Intel vs. AMD

*догонялки навсегда

Корпорация Intel , располагает огромными человеческими ресурсами, и почти неисчерпаемыми финансами. Многие инновации в полупроводниковой индустрии и новые технологии идут именно из этой компании. Процессоры и разработки Intel , в среднем на 1-1,5 года опережают наработки инженеров AMD . Но как известно, за возможность обладать самыми современными технологиями – приходится платить.

Ценовая политика процессоров Intel , основывается как на количестве ядер , количестве кэша , но и на «свежести» архитектуры , производительности на такт ватт , техпроцесса чипа . Значение кэш-памяти, «тонкости техпроцесса» и другие важные характеристики процессора рассмотрим ниже. За обладание такими технологии как и свободного множителя частоты, тоже придётся выложить дополнительную сумму.

Компания AMD , в отличии от компании Intel , стремится к доступности своих процессоров для конечного потребителя и к грамотной ценовой политике.

Можно даже сказать, что AMD – «Народная марка ». В её ценниках вы найдёте то, что вам нужно по очень привлекательной цене. Обычно через год, после появления новой технологии у компании Intel , появляется аналог технологии от AMD . Если вы не гонитесь за самой высокой производительностью и больше обращаете внимание на ценник, чем на наличие передовых технологий, то продукция компании AMD – именно для вас.

Ценовая политика AMD , больше основывается на количестве ядер и совсем немного — на количестве кэш памяти, наличии архитектурных улучшений. В некоторых случаях, за возможность обладать кэш памятью третьего уровня, придётся немного доплатить (Phenom имеет кэш память 3 уровня, Athlon довольствуется только ограниченной, 2 уровня). Но иногда AMD «балует» своих фанатов возможность разблокировать более дешёвые процессоры, до более дорогих. Разблокировать можно ядра или кэш-память. Улучшить Athlon до Phenom . Такое возможно благодаря модульной архитектуре и при недостатке некоторых более дешёвых моделей, AMD просто отключает некоторые блоки на кристалле более дорогих (программно).

Ядра – остаются практически неизменными, отличается только их количество (справедливо для процессоров 2006-2011 годов). За счёт модульности своих процессоров, компания отлично справляется со сбытом отбракованных чипов, которые при отключении некоторых блоков, становятся процессором из менее производительной линейки.

Компания много лет работала над совершенно новой архитектурой под кодовым именем Bulldozer , но на момент выхода в 2011 году, новые процессоры показали не самую лучшую производительность. AMD грешила на операционные системы, что они не понимают архитектурных особенностей сдвоенных ядер и «другой многопоточности».

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

Частота процессора, количество ядер, многопоточность.

Во времена Pentium 4 и до него – частота процессора , была главным фактором производительности процессора при выборе процессора.

Это не удивительно, ведь архитектуры процессоров — специально разрабатывались для достижения высокой частоты, особенно сильно это отразилось как раз в процессоре Pentium 4 на архитектуре NetBurst . Высокая частота, была не эффективна при том длинном конвейере, что был использован в архитектуре. Даже Athlon XP частотой 2Ггц , по уровню производительности был выше чем Pentium 4 c 2,4Ггц . Так что, это был чистой воды маркетинг. После этой ошибки, компания Intel осознала свои ошибки и вернулась на сторону добра начала работать не над частотной составляющей, а над производительностью на такт. От архитектуры NetBurst пришлось отказаться.

Что же нам даёт многоядерность ?

Четырёх-ядерный процессор с частотой 2,4 Ггц , в много-поточных приложениях, теоретически будет примерным эквивалентом, одноядерного процессора с частотой 9,6Ггц или 2-х ядерному процессору с частотой 4,8 Ггц . Но это только теоретически . Практически же, два двухъядерных процессора в двух сокетной материнской плате, будут быстрее одного 4-ядерного, на той же частоте функционирования. Ограничения по скорости шины и задержки памяти дают о себе знать.

* при условии одинаковых архитектур и количества кэш памяти

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

Приложения, которые «любят» и используют многопоточность: архиваторы , плееры и кодировщики видео , антивирусы , программы дефрагментаторы , графические редакторы , браузеры , Flash .

Так же, к «любителям» многопоточности, можно отнести такие операционные системы как Windows 7 и Windows Vista , а так же многие ОС , основанные на ядре Linux , которые работают заметно быстрее при наличии многоядерного процессора.

Большинству игр , бывает вполне достаточно 2-х ядерного процессора на высокой частоте. Сейчас однако, выходит всё больше игр «заточенных» под многопоточность. Взять хотя бы такие SandBox игры, как GTA 4 или Prototype , в которые на 2-х ядерном процессоре с частотой ниже 2,6 Ггц – комфортно себя не чувствуешь, фреймрейт проваливается ниже 30 кадров в секунду. Хотя в данном случае, скорее всего причиной таких казусов является «слабая» оптимизация игр, недостаток времени или «не прямые» руки тех, кто переносил игры с консолей на PC .

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

Кэш память процессора.

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

Она работает на очень высокой тактовой частоте (обычно на частоте самого процессора), имеет очень высокую пропускную способность и процессорные ядра работают с ней напрямую (L1 ).

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

Производительности, так же добавляет факт, если кэш память объединённая, и все ядра равноправно могут использовать данные из неё. Это даёт дополнительные возможности для многопоточной оптимизации.

Такой приём, сейчас используется для кэш памяти 3-го уровня . У процессоров Intel существовали процессоры с объединённой кэш памятью 2-го уровня (C2D E 7*** , E 8*** ), благодаря которым и появился данный способ увеличить многопоточную производительность.

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

В общем, чем больше кэш памяти, тем быстрее процессор. В каких именно приложениях?

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

Благоприятно к большому количеству кэш-памяти относятся игры . Особенно стратегии, авто-симуляторы, RPG, SandBox и все игры, где есть много мелких деталей, частиц, элементов геометрии, потоков информации и физических эффектов.

Кэш память играет очень немалую роль в раскрытии потенциала систем с 2-мя и более видеокартами. Ведь какая то доля нагрузки, ложится на взаимодействие ядер процессора как между собой, так и для работы с потоками нескольких видео-чипов. Именно в этом случае важна организация кэш — памяти, и очень полезна кэш память 3-го уровня большого объёма.

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

Фирменные технологии.

(гипер-поточность, HT )–

впервые технология была применена в процессорах Pentium 4 , но работала не всегда корректно и зачастую больше тормозила процессор, чем ускоряла. Причиной был слишком длинный конвейер и не доведённая до ума система предсказания ветвлений. Применяется компанией Intel , аналогов технологии пока нет, если не считать аналогом то? что реализовали инженеры компании AMD в архитектуре Bulldozer .

Принцип системы таков, что на каждое физическое ядро, создаётся по два вычислительных потока , вместо одного. То есть, если у вас 4-х ядерный процессор с HT (Core i 7 ), то виртуальных потоков у вас 8 .

Прирост производительности достигается за счёт того, что в конвейер могут поступать данные уже в его середине, а не обязательно сначала. Если какие то блоки процессора, способные выполнить это действие простаивают, они получают задачу к выполнению. Прирост производительности не такой как у настоящих физических ядер, но сопоставимый(~50-75%, в зависимости от рода приложения). Довольно редко бывает, что в некоторых приложениях, HT отрицательно влияет на производительность. Связано это с плохой оптимизацией приложений под данную технологию, невозможность понять, что присутствуют потоки «виртуальные» и отсутствие ограничителей для нагрузки потоков равномерно.

Turbo Boost – очень полезная технология, которая увеличивает частоту функционирования наиболее используемых ядер процессора, в зависимости от уровня их загруженности. Очень полезна тогда, когда приложение не умеет использовать все 4 ядра, и загружает только одно или два, при этом их частота работы повышается, что частично компенсирует производительность. Аналогом данной технологии у компании AMD , является технология Turbo Core .

, 3 dnow ! инструкции . Предназначены для ускорения работы процессора в мультимедиа вычислениях (видео, музыка, 2D/3D графика и т.д.), а так же ускоряют работу таких программ как архиваторы, программы для работы с изображениями и видео (при поддержке инструкций данными программами).

3dnow ! – довольно старая технология AMD , которая содержит дополнительные инструкции по обработке мультимедиа контента, помимо SSE первой версии .

*А именно возможность потоковой обработки вещественных чисел одинарной точности.

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

* Пример — SSE 4.1(Intel) — SSE 4A(AMD).

К тому же, данные наборы инструкций не идентичны. Это аналоги, в которых есть небольшие отличия.

Cool’n’Quiet, SpeedStep, CoolCore, Enchanced Half State(C1E) и т . д .

Данные технологии, при низкой нагрузке уменьшают частоту процессора, посредством уменьшения множителя и напряжения на ядре, отключения части КЭШа и т.д. Это позволяет процессору гораздо меньше греться и потреблять меньше энергии, меньше шуметь. Если понадобится мощность, то процессор вернётся в обычное состояние за доли секунды. На стандартных настройках Bios практически всегда включены, при желании их можно отключить, для уменьшения возможных «фризов» при переключении в 3D играх.

Некоторые из этих технологий, управляют скоростью вращения вентиляторов в системе. К примеру, если процессор не нуждается в усиленном отводе тепла и не нагружен, скорость вентилятора процессора уменьшается (AMD Cool’n’Quiet, Intel Speed Step ).

Intel Virtualization Technology и AMD Virtualization .

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

Execute Disable Bit и No eXecute Bit – технология, призванная защитить компьютер от вирусных атак и программных ошибок, которые могут вызвать крах системы посредством переполнения буфера .

Intel 64 , AMD 64 , EM 64 T – данная технология позволяет процессору работать как в ОС с 32-х битной архитектурой, так и в ОС с 64-х битной. Система 64 bit – с точки зрения выгоды, для рядового пользователя отличается тем, что в данной системе можно использовать более 3.25Гб оперативной памяти. В 32-х битных системах, использовать бо льший объём оперативной памяти не представляется возможным, из-за ограниченного объёма адресуемой памяти* .

Большинство приложений с 32-х bit архитектурой, можно запустить на системе с 64-х битной ОС.

* Что же поделать, если в далёком 1985 году, никто и подумать не мог о таких гигантских, по меркам того времени, объёмах оперативной памяти.

Дополнительно.

Пара слов о .

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

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

Встроенное в процессор .

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

К тому же те ядра, что встроены в процессор, годятся только для загрузки ОС, интернет сёрфинга и просмотра видео (и то не любого качества).

Тенденции на рынке все же меняются и возможность купить производительный процессор от Intel без видео ядра выпадает всё реже. Политика принудительного навязывание встроенного видео ядра, появилась с процессоров Intel под кодовым названием Sandy Bridge , основное новшество которых и было встроенное ядро на том же техпроцессе. Видео-ядро, находится совместно с процессором на одном кристалле , и не такое простое как в предыдущих поколениях процессоров Intel . Для тех кто его не использует, есть минусы в виде некоторой переплаты за процессор, смещённость источника нагрева относительно центра тепло — распределительной крышки. Однако есть и плюсы. Отключенное видео ядро, можно использовать для очень быстрой кодировки видео с помощью технологии Quick Sync вкупе со специальным, поддерживающим данную технологию ПО. В будущем, Intel обещает расширить горизонты использования встроенного видео ядра для параллельных вычислений.

Сокеты для процессоров. Сроки жизни платформ .

Intel ведёт грубую политику для своих платформ. Срок жизни каждой (срок начала и конца продаж процессоров для неё), обычно не превышает 1.5 — 2 года. К тому же, у компании есть несколько параллельно развивающихся платформ.

Компания AMD , ведёт противоположную политику совместимости. На её платформу на AM 3 , будут подходить все процессоры будущих поколений, поддерживающие DDR3 . Даже при выходе платформы на AM 3+ и более поздних, отдельно будут выпускаться либо новые процессоры под AM 3 , либо новые процессоры будут совместимы со старыми материнскими платами, и можно будет сделать безболезненный для кошелька апгрейд, поменяв только процессор (без смены мат.платы, ОЗУ и т.д.) и прошив материнской платы. Единственные нюансы несовместимости могут быть при смене типа , так как будет требоваться другой контроллёр памяти, встроенный в процессор. Так что совместимость ограниченная и поддерживается далеко не всеми материнскими платами. Но в целом, экономному пользователю или тем, кто не привык менять платформу полностью каждые 2 года — выбор производителя процессора понятен — это AMD .

Охлаждение процессора.

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

Заключение.

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

• Выбрать производителя
• Архитектура процессора
• Техпроцесс
• Частота процессора
• Количество ядер процессора
• Размер и тип кэш-памяти процессора
• Поддержка технологий и инструкций
• Качественное охлаждение

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

saul 9 сентября 2015 в 13:38

Реализация многопоточной архитектуры игрового движка

• Блог компании Intel ,
• Разработка игр ,
• Параллельное программирование ,
• Разработка веб-сайтов

• Перевод

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

1. Введение

1.1. Обзор

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

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

2. Состояние параллельного выполнения

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

2.1 Состояния выполнения

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

Рисунок 1. Состояние выполнения в свободном пошаговом режиме

2.1.1. Свободный пошаговый режим

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

2.1.2. Жесткий пошаговый режим

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

Рисунок 2. Состояние выполнения в жестком пошаговом режиме

2.2. Синхронизация данных

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

• Время: итоговым значением становится последнее внесенное изменение.
• Приоритет: итоговым значением становится изменение, выполненное системой с наибольшим приоритетом. Если приоритет систем совпадает, можно также учитывать время внесения изменений.

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

3. Движок

При разработке движка основное внимание уделяется гибкости, необходимой для дальнейшего расширения его функциональности. Это позволит оптимизировать его для использования в условиях определенных ограничений (например, по памяти).
Движок можно условно разделить на две части: фреймворк и менеджеры. Фреймворк (см. раздел 3.1) включает в себя части игры, которые тиражируются в процессе выполнения, то есть существуют в нескольких экземплярах. В него также входят элементы, участвующие в выполнении основного цикла игры. Менеджеры (см. раздел 3.2) представляют собой Singleton-объекты, отвечающие за выполнение логической составляющей игры.
Ниже представлена схема игрового движка.

Рисунок 3. Общая архитектура движка

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

Взаимодействие движка и систем осуществляется при помощи интерфейсов. Они реализованы таким образом, чтобы предоставить движку доступ к функциям систем, а системам - к менеджерам движка.
Подробная схема движка представлена в приложении A, «Схема движка».

Фактически все системы независимы друг от друга (см. раздел 2, «Состояние одновременного выполнения»), то есть они могут выполнять действия параллельно, не влияя на работу других систем. Однако любое изменение данных повлечет за собой определенные сложности, поскольку системам придется взаимодействовать между собой. Обмен информацией между системами необходим в следующих случаях:

• чтобы сообщить другой системе об изменении общих данных (например, положения или ориентации объектов);
• чтобы выполнить функции, недоступные для данной системы (например, система ИИ обращается к системе расчета геометрических или физических свойств объекта, чтобы выполнить тест на пересечение лучей).

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

3.1. Фреймворк

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

Рисунок 4. Основной цикл игры

Движок работает в оконной среде, поэтому на первом шаге цикла игры необходимо обработать все незавершенные сообщения окон ОС. Если этого не сделать, движок не будет реагировать на сообщения ОС. На втором шаге планировщик назначает задачи с помощью менеджера задач. Этот процесс подробно описан в разделе 3.1.1 ниже. После этого менеджер состояний (см. раздел 3.2.2) рассылает информацию о выполненных изменениях системам движка, на работу которых она может повлиять. На последнем шаге, в зависимости от статуса выполнения, фреймворк определяет, следует ли завершить или продолжить работу движка, например, для перехода к следующей сцене. Информация о состоянии движка хранится у менеджера среды. Подробнее см. в разделе 3.2.4.

3.1.1. Планировщик

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

3.1.2. Универсальная сцена и объекты

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

Рисунок 5. Расширение универсальной сцены и объекта

Рассмотрим принцип работы расширений на следующем примере. Допустим, выполнено расширение универсальной универсальная сцены сцена расширена на для использование использования графических, физических и других свойств. В этом случае за инициализацию дисплея будет отвечать «графическая» часть расширения, а за реализацию физических законов для твердых тел, например силы тяжести, - его «физическая» часть. Сцены содержат объекты, поэтому универсальная сцена тоже будет включать в себя несколько универсальных объектов. Универсальные объекты также можно расширить намогут быть расширены для использование использования графических, физических и других свойств. Например, прорисовка объекта на экране будет реализована графическими функциями расширения, а расчет взаимодействия твердых тел - физическими.

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

3.2. Менеджеры

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

3.2.1. Менеджер задач

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

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

Рисунок 6. Пример пула потоков, используемого менеджером задач

Помимо обработки запросов планировщика по доступу к основным задачам менеджер задач может работать в режиме инициализации. Он последовательно опрашивает системы от каждого потока, чтобы они могли инициализировать локальные хранилища данных, необходимые для работы.
Советы по реализации менеджера задач даны в приложении D, «Советы по реализации задач».

3.2.2. Менеджер состояний

Менеджер состояний является частью механизма обмена сообщениями. Он отслеживает изменения и рассылает уведомления о них всем системам, которых эти изменения могут затронуть. Чтобы не рассылать ненужных уведомлений, менеджер состояний хранит информацию о том, какие системы оповещать в том или ином случае. Этот механизм реализован на основе шаблона «Наблюдатель» (см. приложение C, «Наблюдатель (шаблон проектирования)»). Если говорить вкратце, данный шаблон предполагает использование «наблюдателя», который следит за любыми изменениями субъекта, при этом роль посредника между ними выполняет контроллер изменений.

Механизм работает следующим образом. 1. Наблюдатель сообщает контроллеру изменений (или менеджеру состояний), изменения каких субъектов он хочет отслеживать. 2. Субъект уведомляет контроллер обо всех своих изменениях. 3. По сигналу фреймворка контроллер оповещает наблюдателя об изменениях субъекта. 4. Наблюдатель отправляет субъекту запрос на получение обновленных данных.

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

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

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

Рисунок 7. Уведомление о внутренних изменениях универсального объекта

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

3.2.3. Менеджер служб

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

Рисунок 8. Пример менеджера служб

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

3.2.4. Менеджер среды

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

3.2.5. Менеджер платформы

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

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

4. Интерфейсы

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

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

4.1. Интерфейсы субъекта и наблюдателя

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

4.2. Интерфейсы менеджеров

Менеджеры, несмотря на то что они являются Singleton-объектами, напрямую доступны только для фреймворка. Другие системы могут получить доступ к менеджерам только через интерфейсы, которые представляют лишь часть их общей функциональности. После инициализации интерфейс передается системе, которая использует его для работы с определенными функциями менеджера.
Не существует единого интерфейса для всех менеджеров. Каждый из них имеет свой отдельный интерфейс.

4.3. Интерфейсы системы

Чтобы фреймворк мог получить доступ к компонентам системы, ей необходимы интерфейсы. Без них поддержку каждой новой системы движка пришлось бы реализовывать отдельно.
Каждая система включает в себя четыре компонента, поэтому и интерфейсов должно быть четыре. А именно: система, сцена, объект и задача. Подробное описание см. в разделе 5, «Системы». Интерфейсы - это средства получения доступа к компонентам. Интерфейсы системы позволяют создавать и удалять сцены. Интерфейсы сцены, в свою очередь, позволяют создавать и уничтожать объекты, а также запрашивать информацию об основной задаче системы. Интерфейс задач в основном используется менеджером задач при постановке задач в пул потоков.
Поскольку сцена и объект, как части системы, должны взаимодействовать друг с другом и с универсальной сценой и объектом, к которым они привязаны, их интерфейсы также создают на основе интерфейсов субъекта и наблюдателя.

4.4. Интерфейсы изменений

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

5. Системы

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

5.1. Типы

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

5.2. Компоненты системы

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

Рисунок 9. Компоненты системы

Подробная схема связей между системами движка приведена в приложении B, «Схема взаимодействия движка и систем».

5.2.1. Система

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

5.2.2. Сцена

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

5.2.3. Объект

Компонент «объект», или системный объект, принадлежит сцене и обычно связан с тем, что пользователь видит на экране. Универсальный объект использует системный объект для расширения функциональности, предоставляя его свойства как свои собственные.
Примером может послужить геометрическое, графическое и физическое расширение универсального объекта для отображения деревянной балки на экране. Геометрические свойства будут включать в себя положение, ориентацию и масштаб объекта. Для его отображения графическая система будет использовать специальную сетку. А физическая система наделит его свойствами твердого тела для расчета взаимодействий с другими телами и действующих сил гравитации.

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

5.2.4. Задача

Компонент «задача», или системная задача, используется для обработки сцены. Задача получает команду на обновление сцены от менеджера задач. Это сигнал для запуска системных функций на объектах сцены.
Выполнение задачи можно разбить на подзадачи, распределяя их также с помощью менеджера задач на еще большее число потоков. Это удобный способ масштабирования движка на несколько процессоров. Такой метод называют декомпозицией данных.
Информация об изменении объектов в процессе обновления задач сцены передается менеджеру состояний. Подробную информацию о менеджере состояний см. в разделе 3.2.2.

6. Объединяя все компоненты

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

6.1. Этап инициализации

Работа движка начинается с инициализации менеджеров и фреймворка.

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

Рисунок 10. Инициализация менеджеров и систем движка

6.2. Этап загрузки сцены

Управление возвращается загрузчику, который загружает сцену.

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

Рисунок 11. Инициализация универсальной сцены и объекта

6.3. Этап цикла игры

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

6.3.1. Выполнение задачи

Управление переходит менеджеру задач.

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

Рисунок 12. Менеджер задач и задачи

6.3.2. Обновление данных

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

• Менеджер состояний поочередно вызывает каждый из своих контроллеров изменений для рассылки накопленных уведомлений. Контроллер проверяет, каким наблюдателям отправлять уведомления об изменениях для каждого из субъектов.
• Затем он вызывает нужного наблюдателя и сообщает ему об изменении (уведомление также включает в себя указатель на интерфейс субъекта). В режиме свободного пошагового выполнения наблюдатель получает измененные данные от контроллера изменений, но в режиме жесткого пошагового выполнения он должен запрашивать их у самого субъекта.
• Обычно наблюдателями, заинтересованными в получении уведомлений об изменениях системного объекта, являются другие системные объекты, связанные с одним и тем же универсальным объектом. Это позволяет разделить процесс внесения изменений на несколько задач, которые можно выполнять параллельно. Чтобы упростить процесс синхронизации, можно объединить в одной задаче все связанные расширения универсального объекта.

6.3.3. Проверка выполнения и выход

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

7. Заключение

Основная идея данной статьи изложена в разделе 2, «Состояние параллельного выполнения». Благодаря функциональной декомпозиции и декомпозиции данных можно реализовать не только многопоточность движка, но и его масштабируемость на еще большее количество ядер в будущем. Чтобы исключить издержки на синхронизацию, продолжая поддерживать данные в актуальном состоянии, используйте менеджеры состояния в дополнение к механизму обмена сообщениями.

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

Важную роль в распределении нагрузок играет управление задачами. В приложении D приведены советы по созданию эффективного менеджера задач для игрового движка.

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

Приложение A. Схема движка

Запуск обработки выполняется из основного цикла игры (см. рис. 4, «Основной цикл игры»).

 

Приложение B. Схема взаимодействия движка и систем

 

Приложение C. Наблюдатель (шаблон проектирования)

Шаблон «Наблюдатель» подробно описан в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Э. Гамма, Р. Хельм, Р. Джонсон, Дж. Влиссидес («Design Patterns: Elements of Reusable Object-Oriented Software», Gamma E., Helm R., Johnson R., Vlissides J.). На английском языке она впервые была издана в 1995 году издательством Addison-Wesley.

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

Рисунок 13. Шаблон «Наблюдатель»

Ниже описан процесс использования данной модели.

1. Контроллер изменений регистрирует наблюдателя и субъекта, уведомления о котором он хочет получать.
2. Контроллер изменений фактически является наблюдателем. Вместо наблюдателя вместе с субъектом он регистрирует самого себя. Контроллер изменений также хранит свой список наблюдателей и зарегистрированных с ними субъектов.
3. Субъект вносит наблюдателя (то есть контроллера изменений) в свой список наблюдателей, которые хотят получать уведомления о его изменениях. Иногда дополнительно указывается тип изменений, который определяет, в каких именно изменениях заинтересован наблюдатель. Это позволяет оптимизировать процесс рассылки уведомлений об изменениях.
4. Меняя данные или состояние, субъект уведомляет наблюдателя посредством механизма обратного вызова и передает информацию об измененных типах.
5. Контроллер изменений формирует очередь уведомлений об изменениях и ждет сигнала для их распределения по объектам и системам.
6. Во время распределения контроллер изменений обращается к реальным наблюдателям.
7. Наблюдатели запрашивают информацию об измененных данных или состоянии у субъекта (или получают их вместе с уведомлениями).
8. Перед удалением наблюдателя или если ему больше не требуется получать уведомления о субъекте, он удаляет подписку на данный субъект в контроллере изменений. 

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

Разобравшись с теорией многопоточности, рассмотрим практический пример - Pentium 4. Уже на этапе разработки этого процессора инженеры Intel продолжали работу над повышением его быстродействия без внесения изменений в программный интерфейс. Рассматривалось пять простейших способов:
1. Повышение тактовой частоты.
2. Размещение на одной микросхеме двух процессоров.
3. Введение новых функциональных блоков.
1. Удлинение конвейера.
2. Использование многопоточности.
Самый очевидный способ повышения быстродействия заключается в том, чтобы повысить тактовую частоту, не меняя другие параметры. Как правило, каждая последующая модель процессора имеет несколько более высокую тактовую частоту, чем предыдущая. К сожалению, при прямолинейном повышении тактовой частоты разработчики сталкиваются с двумя проблемами: увеличением энергопотребления (что актуально для портативных компьютеров и других вычислительных устройств, работающих на аккумуляторах) и перегревом (что требует создания более эффективных теплоотводов).
Второй способ - размещение на микросхеме двух процессоров - сравнительно прост, но он сопряжен с удвоением площади, занимаемой микросхемой. Если каждый процессор снабжается собственной кэш-памятью, количество микросхем на пластине уменьшается вдвое, но это также означает удвоение затрат на производство. Если для обоих процессоров предусматривается общая кэш-память, значительного увеличения занимаемой площади удается избежать, однако в этом случае возникает другая проблема - объем кэш-памяти в пересчете на каждый процессор уменьшается вдвое, а это неизбежно сказывается на производительности. Кроме того, если профессиональные серверные приложения способны полностью задействовать ресурсы нескольких процессоров, то в обычных настольных программах внутренний параллелизм развит в значительно меньшей степени.
Введение новых функциональных блоков также не представляет сложности, но здесь важно соблюсти баланс. Какой смысл в десятке блоков АЛУ, если микросхема не может выдавать команды на конвейер с такой скоростью, которая позволяет загрузить все эти блоки?
Конвейер с увеличенным числом ступеней, способный разделять задачи на более мелкие сегменты и обрабатывать их за короткие периоды времени, с одной стороны, повышает производительность, с другой, усиливает негативные последствия неверного прогнозирования переходов, кэш-промахов, прерываний и других событий, нарушающих нормальный ход обработки команд в процессоре. Кроме того, чтобы полностью реализовать возможности расширенного конвейера, необходимо повысить тактовую частоту, а это, как мы знаем, приводит к повышенным энергопотреблению и теплоотдаче.
Наконец, можно реализовать многопоточность. Преимущество этой технологии состоит во введении дополнительного программного потока, позволяющего ввести в действие те аппаратные ресурсы, которые в противном случае простаивали бы. По результатам экспериментальных исследований разработчики Intel выяснили, что увеличение площади микросхемы на 5 % при реализации многопоточности для многих приложений дает прирост производительности на 25 %. Первым процессором Intel с поддержкой многопоточности стал Xeon 2002 года. Впоследствии, начиная с частоты 3,06 ГГц, многопоточность была внедрена в линейку Pentium 4. Intel называет реализацию многопоточности в Pentium 4 гиперпоточностью (hyperthreading).
Основной принцип гиперпоточности - одновременное исполнение двух программных потоков (или процессов - процессор не отличает процессы от программных потоков). Операционная система рассматривает гиперпоточный процессор Pentium 4 как двухпроцессорный комплекс с общими кэшами и основной памятью. Планирование операционная система выполняет для каждого программного потока отдельно. Таким образом, в одно и то же время могут выполняться два приложения. К примеру, почтовая программа может отправлять или принимать сообщения в фоновом режиме, пока пользователь взаимодействует с интерактивным приложением - то есть демон и пользовательская программа выполняются одновременно, как будто системе доступно два процессора.
Прикладные программы, предусматривающие возможность исполнения в виде нескольких программных потоков, могут задействовать оба «виртуальных процессора». Например, программы редактирования видеоданных обычно позволяют пользователям применять фильтры ко всем кадрам. Такие фильтры корректируют яркость, контраст, цветовой баланс и другие свойства кадров. В такой ситуации программа может назначить один виртуальный процессор для обработки четных кадров, а другой - для обработки нечетных. При этом два процессора будут работать совершенно независимо друг от друга.
Поскольку программные потоки обращаются к одним и тем же аппаратным ресурсам, необходима координация этих потоков. В контексте гиперпоточности разработчики Intel выделили четыре полезных стратегии управления совместным потреблением ресурсов: дублирование ресурсов, а также жесткое, пороговое и полное разделение ресурсов. Рассмотрим эти стратегии.
Начнем с дублирования ресурсов (resource duplication). Как известно, некоторые ресурсы с целью организации программных потоков дублируются. Например, так как каждому программному потоку требуется индивидуальное управление, нужен второй счетчик команд. Кроме того, необходимо ввести вторую таблицу отображения архитектурных регистров (ЕАХ, ЕВХ и т. д.) на физические регистры; аналогичным образом, дублируется контроллер прерываний, поскольку обработка прерываний для каждого потока производится индивидуально.
Далее следует методика жесткого разделения ресурсов (partitioned resource sharing) между программными потоками. К примеру, если в процессоре предусмотрена очередь между двумя функциональными ступенями конвейера, то половину слотов можно отдавать потоку 1, другую половину - потоку 2. Разделение ресурсов легко реализуется, не ведет к дисбалансу и обеспечивает полную независимость программных потоков друг от друга. При полном разделении всех ресурсов один процессор фактически превращается в два. С другой стороны, может сложиться такая ситуация, при которой один программный поток не использует ресурсы, которые могли бы пригодиться второму потоку, но в отношении которых у него нет полномочий доступа. В результате ресурсы, которые в иной ситуации могли бы быть задействованы, простаивают.
Противоположность жесткого разделения - полное разделение ресурсов (full resource sharing). В этой схеме к нужным ресурсам может получить доступ любой программный поток, а обслуживаются они в порядке поступления запросов на доступ. Рассмотрим ситуацию, в которой быстрый поток, состоящий преимущественно из операций сложения и вычитания, сосуществует с медленным потоком, реализующим операции умножения и деления. Если команды вызываются из памяти быстрее, чем выполняются операции умножения и деления, число команд, вызванных в рамках медленного потока и поставленных в очередь на конвейер, будет постепенно расти. В конечном итоге эти команды заполнят очередь, в результате быстрый поток из-за нехватки места в ней остановится. Полное разделение ресурсов решает проблему неоптимального расходования общих ресурсов, но создает дисбаланс их потребления - один поток может замедлить или остановить другой.
Промежуточная схема реализуется в рамках порогового разделения ресурсов (threshold resource sharing). Согласно этой схеме любой программный поток может динамически получать определенный (ограниченный) объем ресурсов. Применительно к реплицированным ресурсам этот подход обеспечивает гибкость без угрозы простоя одного из программных потоков из-за невозможности получения ресурсов. Если, к примеру, запретить каждому из потоков занимать больше 3/4 очереди команд, повышенное потребление ресурсов медленным потоком не помешает исполнению быстрого.
Модель гиперпоточности Pentium 4 объединяет разные стратегии разделения ресурсов. Таким образом, предпринимается попытка решить все проблемы, связанные с каждой стратегией. Дублирование реализуется в отношении ресурсов, доступ к которым постоянно требуется обоим программным потокам (в частности, в отношении счетчика команд, таблицы отображения регистров и контроллера прерываний). Дублирование этих ресурсов увеличивает площадь микросхемы всего лишь на 5 % - согласитесь, вполне разумная плата за многопоточность. Ресурсы, доступные в таком объеме, что практически исключается вероятность их захвата одним потоком (например, строки кэша), распределяются динамически. Доступ к ресурсам, контролирующим работу конвейера (в частности, его многочисленные очереди), разделяется - каждому программному потоку отдается половина слотов. Главный конвейер архитектуры Netburst, реализованной в Pentium 4, изображен на рис. 8.7; белые и серые области на этой иллюстрации обозначают механизм распределения ресурсов между белым и серым программными потоками.
Как видим, все очереди на этой иллюстрации разделены - каждому программному потоку выделяется по половине слотов. Ни один из программных потоков не может ограничить работу другого. Блок распределения и подмены также разделяется. Ресурсы планировщика разделяются динамически, но на основе некоего порогового значения - таким образом, ни один из потоков не может занять все слоты очереди. Для всех остальных ступеней конвейера имеет место полное разделение.
Впрочем, с многопоточностью не все так просто. Даже у такой прогрессивной методики есть недостатки. Жесткое разделение ресурсов не связано с серьезными издержками, а вот динамическое разделение, в особенности с учетом пороговых величин, требует отслеживать потребление ресурсов на этапе исполнения. Кроме того, в некоторых случаях программы значительно лучше работают без многопоточности, чем с ней. Предположим, к примеру, что при наличии двух программных потоков для нормального функционирования каждому из них требуется 3/4 кэша. Если бы они выполнялись поочередно, каждый показал бы достаточную эффективность при небольшом количестве кэш-промахов (как известно, связанных с дополнительными издержками). В случае параллельного исполнения кэш-промахов у каждого было бы значительно больше, и конечный результат оказался бы хуже, чем без многопоточности.
Дополнительные сведения о механизме многопоточности РепПит 4 можно почерпнуть в .

Разобравшись с теорией многопоточности, рассмотрим практический пример - Pentium 4. Уже на этапе разработки этого процессора инженеры Intel продолжали работу над повышением его быстродействия без внесения изменений в программный интерфейс. Рассматривалось пять простейших способов:

Повышение тактовой частоты;

Размещение на одной микросхеме двух процессоров;

Введение новых функциональных блоков;

Удлинение конвейера;

Использование многопоточности.

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

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

Введение новых функциональных блоков также не представляет сложности, но здесь важно соблюсти баланс. Какой смысл в десятке блоков АЛУ, если микросхема не может выдавать команды на конвейер с такой скоростью, которая позволяет загрузить все эти блоки?

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

Наконец, можно реализовать многопоточность. Преимущество этой технологии состоит во введении дополнительного программного потока, позволяющего ввести в действие те аппаратные ресурсы, которые в противном случае простаивали бы. По результатам экспериментальных исследований разработчики Intel выяснили, что увеличение площади микросхемы на 5 % при реализации многопоточности для многих приложений дает прирост производительности на 25 %. Первым процессором Intel с поддержкой многопоточности стал Хеоn 2002 года. Впоследствии, начиная с частоты 3,06 ГГц, многопоточность была внедрена в линейку Pentium 4. Intel называет реализацию многопоточности в Pentium 4 гиперпоточностью (hyperthreading).

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

Первые разработки в области создания многопроцессорных систем начались в 70-х годах. Длительное время производительность привычных одноядерных процессоров повышалась за счёт увеличения тактовой частоты (до 80% производительности определяла только тактовая частота) с одновременным увеличением числа транзисторов на кристалле. Фундаментальные законы физики остановили этот процесс: чипы стали перегреваться, технологический стал приближаться к размерам атомов кремния. Все эти факторы привели к тому, что:

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

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

Hyper-Threading Technology (HTT) или технология сверхпоточной обработки данных, позволяющая процессору на одном ядре выполнять несколько программных потоков. Именно HTT по мнению многих специалистов стала предпосылкой для создания многоядерных процессоров. Выполнение процессором одновременно несколько программных потоков называется параллелизмом на уровне потоков (TLP –thread-level parallelism).

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

1. Общие понятия

Архитектура в широком смысле – это описание сложной системы, состоящей из множества элементов.

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

Микропроцессор (или процессор) – это главный компонент компьютера. Он обрабатывает информацию, выполняет программы и управляет другими устройствами системы. От мощности процессора зависит, насколько быстро будут выполняться программы.

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

Процессоры Intel, используемые в IBM – совместимых ПК, насчитывают более тысячи команд и относятся к процессорам с расширенной системой команд – CISC-процессорам (CISC –Complex Instruction Set Computing).

1.1 Высокопроизводительные вычисления. Параллелизм

Темпы развития вычислительной техники легко проследить: от ENIAC (первый электронный цифровой компьютер общего назначения) с производительностью в несколько тысяч операций в секунду до суперкомпьютера Tianhe-2 (1000 триллионов операций с плавающей запятой в секунду). Это означает, что скорость вычислений увеличилась в триллион раз за 60 лет. Создание высокопроизводительных вычислительных систем – одна из самых сложных научно-технических задач. При том, что скорость вычислений технических средств выросла всего лишь в несколько миллионов раз, общая скорость вычислений выросла в триллионы раз. Этот эффект достигнут за счёт применения параллелизма на всех стадиях вычислений. Параллельные вычисления требуют поиска рационального распределения памяти, надёжных способов передачи информации и координации вычислительных процессов.

1.2 Симметрическая мультипроцессорность

Symmetric Multiprocessing (сокращённо SMP) или симметрическое мультипроцессирование – это особая архитектура мультипроцессорных систем, в которой несколько процессоров имеют доступ к общей памяти. Это очень распространённая архитектура, достаточно широко используемая в последнее время.

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

В силу перечисленных выше особенностей, SMP-системы применяется исключительно в научной сфере, промышленности, бизнесе, крайне редко в рабочих офисах. Кроме высокой стоимости аппаратной реализации, такие системы нуждаются в очень дорогом и качественном программном обеспечении, обеспечивающем многопоточное выполнение задач. Обычные программы (игры, текстовые редакторы) не будут эффективно работать в SMP-системах, так как в них не предусмотрена такая степень распараллеливания. Если адаптировать какую-либо программу для SMP-системы, то она станет крайне неэффективно работать на однопроцессорных системах, что приводит к необходимости создание нескольких версий одной и той же программы для разных систем. Исключение составляет, например, программа ABLETON LIVE (предназначена для создания музыки и подготовка Dj-сетов), имеющая поддержку мультипроцессорных систем. Если запустить обычную программу на мультипроцессорной системе, она всё же станет работать немного быстрее, чем в однопроцессорной. Это связано с так называемым аппаратным прерыванием (остановка программы для обработки ядром), которое выполняется на другом свободном процессоре.

SMP-система (как и любая другая, основанная на параллельных вычислениях) предъявляет повышенные требования к такому параметру памяти, как полоса пропускания шины памяти. Это зачастую ограничивает количество процессоров в системе (современные SMP- системы эффективно работают вплоть до 16 процессоров).

Так как у процессоров общая память, то возникает необходимость рационального её использования и согласования данных. В мультипроцессорной системе получается так, что несколько кэшей работают для разделяемого ресурса памяти. Сache coherence (когерентность кэша) – свойство кэша, обеспечивающее целостность данных, хранящихся в индивидуальных кэшах для разделяемого ресурса. Данное понятие – частный случай понятия когерентности памяти, где несколько ядер имеют доступ к общей памяти (повсеместно встречается в современных многоядерных системах). Если описать данные понятия в общих чертах, то картина будет следующей: один и тот же блок данных может быть загружен в разные кэши, где данные обрабатываются по-разному.

Если не будут использованы какие-либо уведомления об изменении данных, то возникнет ошибка. Когерентность кэша призвана для разрешения таких конфликтов и поддержки соответствия данных в кэшах.

SMP-системы являются подгруппой MIMD (multi in-struction multi data - вычислительная система со множественным потоком команд и множественным потоком данных) классификации вычислительных систем по Флинну (профессор Стэнфордского университета, сооснователь Palyn Associates). Согласно данной классификации, практически все разновидности параллельных систем можно отнести к MIMD.

Разделение многопроцессорных систем на типы происходит на основе разделения по принципу использования памяти. Этот подход позволил различить следующие важные типы

многопроцессорных систем – multiprocessors (мультипроцессорные системы с общей разделяемой памятью) и multicomputers (системы с раздельной памятью). Общие данные, используемы при параллельных вычислениях требуют синхронизации. Задача синхронизация данных – одна из самых важных проблем, и её решение при разработке многопроцессорных и многоядерных и, соответственно, необходимого программного обеспечения является приоритетной задачей инженеров и программистов. Общий доступ к данным может быть произведён при физическом распределении памяти. Этот подход называется неоднородным доступом к памяти (non-uniform memory access или NUMA).

Среди данных систем можно выделить:

• Системы, где только индивидуальная кэш-память процессоров используется для представления данных (cache-only memory architecture).
• Системы с обеспечением когерентности локальных кэшей для различных процессоров (cache-coherent NUMA).
• Системы с обеспечением общего доступа к индивидуальной памяти процессоров без реализации на аппаратном уровне когерентности кэша (non-cache coherent NUMA).

Упрощение проблемы создания мультипроцессорных систем достигается использованием распределённой общей памяти (distributed shared memory), однако этот способ приводит к ощутимому повышению сложности параллельного программирования.

1.3 Одновременная многопоточность

Исходя из всех вышеперечисленных недостатков симметрической мультипроцессорности, имеет смысл разработка и развитие других способов повышения производительности. Если проанализировать работу каждого отдельного транзистора в процессоре, можно обратить внимание на очень интересный факт – при выполнении большинства вычислительных операций задействуются далеко не все компоненты процессора (согласно последним исследованиям – около 30% всех транзисторов). Таким образом, если процессор выполняет, скажем, несложную арифметическую операцию, то большая часть процессора простаивает, следовательно, её можно использовать для других вычислений. Так, если в данный момент процессор выполняет вещественные операции, то в свободную часть можно загрузить целочисленную арифметическую операцию. Чтобы увеличить нагрузку на процессор, можно создать спекулятивное (или опережающее) выполнение операций, что требует большого усложнения аппаратной логики процессора. Если в программе заранее определить потоки (последовательности команд), которые могут выполняться независимо друг от друга, то это заметно упростит задачу (данный способ легко реализуется на аппаратном уровне). Эта идея, принадлежащая Дину Тулсену (разработана им в 1955 г в университете Вашингтона), получила название одновременной многопоточности (simul-taneous multithreading). Позднее она была развита компанией Intel под названием гиперпоточности (hyper threading). Так, один процессор, выполняющий множество потоков, воспринимается операционной системой Windows как несколько процессоров. Использование данной технологии опять-таки требует соответствующего уровня программного обеспечения. Максимальный эффект от применения технологии многопоточности составляет около 30%.

1.4 Многоядерность

Технология многопоточности – реализация многоядерности на программном уровне. Дальнейшее увеличение производительности, как всегда, требует изменений в аппаратной части процессора. Усложнение систем и архитектур не всегда оказывается действенным. Существует обратное мнение: «всё гениальное – просто!». Действительно, чтобы повысить производительность процессора вовсе необязательно повышать его тактовую частоту, усложнять логическую и аппаратную составляющие, так как достаточно лишь провести рационализацию и доработку существующей технологии. Такой способ весьма выгоден – не нужно решать проблему повышения тепловыделения процессора, разработку нового дорогостоящего оборудования для производства микросхем. Данный подход и был реализован в рамках технологии многоядерности – реализация на одном кристалле нескольких вычислительных ядер. Если взять исходный процессор и сравнить прирост производительности при реализации нескольких способов повышения производительности, то очевидно, что применение технологии многоядерности является оптимальным вариантом.

Если сравнивать архитектуры симметричного мультипроцессора и многоядерного, то они окажутся практически идентичными. Кэш-память ядер может быть многоуровневой (локальной и общей, причём данные из оперативной памяти могут загружаться в кэш-память второго уровня напрямую). Исходя из рассмотренных достоинств многоядерной архитектуры процессоров, производители делают акцент именно на ней. Данная технология оказалась достаточно дешёвой в реализации и универсальной, что позволило вывести её на широкий рынок. Кроме того, данная архитектура внесла свои коррективы в закон Мура: «количество вычислительных ядер в процессоре будет удваиваться каждые 18 месяцев».

Если посмотреть на современный рынок компьютерной техники, то можно увидеть, что доминируют устройства с четырёх- и восьми- ядерными процессорами. Кроме того, производители процессоров заявляют, что в скором времени на рынке можно будет увидеть процессоры с сотнями вычислительных ядер. Как уже неоднократно говорилось ранее, весь потенциал многоядерной архитектуры раскрывается только при наличии качественного программного обеспечения. Таким образом, сфера производства компьютерного «железа» и программного обеспечения очень тесно связаны между собой.