Попробуем понять, что же такое нам предлагает Intel и как к этому следует относиться. Эта компания, если внимательно посмотреть, никогда не отличалась абсолютным совершенством своих продуктов, более того — вариации на те же темы от других производителей подчас получались гораздо более интересными и концептуально стройными. Однако, как оказалось, абсолютно все делать совершенным и не нужно — главное чтобы чип олицетворял собой какую-то идею, и идея эта приходилась очень вовремя и к месту. И еще — чтобы ее просто не было у других.
Так было с Pentium, когда Intel противопоставила весьма шустрому в «целочисленке» AMD Am5x86 мощный FPU. Так было с Pentium II, который получил толстую шину и быстрый кэш второго уровня, благодаря чему за ним так и не смогли угнаться все процессоры Socket 7. Так было (ну, по крайней мере, я считаю это свершившимся фактом) и с Pentium 4, который противопоставил всем остальным наличие поддержки SSE2 и быстрый рост частоты — и тоже де-факто выиграл. Сейчас Intel предлагает нам Hyper-Threading. И мы отнюдь не призываем в священной истерике биться лбом о стенку и кричать «господи помилуй», «аллах велик» или «Intel rulez forever». Нет, мы просто предлагаем задуматься — почему производитель, известный грамотностью своих инженеров (ни слова про маркетологов! :)) и громадными суммами, которые он тратит на исследования, предлагает нам эту технологию.
Объявить Hyper-Threading «очередной маркетинговой штучкой», конечно, проще простого. Однако не стоит забывать, что это технология, она требует исследований, денег на разработку, времени, сил… Не проще ли было нанять за меньшую сумму еще одну сотню PR-менеджеров или сделать еще десяток красивых рекламных роликов? Видимо, не проще. А значит, «что-то в этом есть». Вот мы сейчас и попытаемся понять даже не то, что получилось в результате, а то, чем руководствовались разработчики IAG (Intel Architecture Group), когда принимали решение (а такое решение наверняка принималось!) — разрабатывать «эту интересную мысль» дальше, или отложить в сундук для идей забавных, но бесполезных.
Как ни странно, для того чтобы понять как функционирует Hyper-Threading, вполне достаточно понимать как работает… любая многозадачная операционная система. И действительно — ну ведь исполняет же каким-то образом один процессор сразу десятки задач? Этот «секрет» всем уже давно известен — на самом деле одновременно все равно выполняется только одна (на однопроцессорной системе), просто переключение между кусками кода разных задач выполняется настолько быстро, что создается иллюзия одновременной работы большого количества приложений.
По сути, Hyper-Threading предлагает нам то же самое, но реализована аппаратно, внутри самого CPU. Есть некоторое количество различных исполняющих блоков (ALU, MMU, FPU, SIMD), и есть два «одновременно» исполняемых фрагмента кода. Специальный блок отслеживает, какие команды из каждого фрагмента необходимо выполнить в данный момент, после чего проверяет, загружены ли работой все исполняющие блоки процессора. Если один из них простаивает, и именно он может исполнить эту команду — ему она и передается. Естественно, существует и механизм принудительного «посыла» команды на выполнение — в противном случае один процесс мог бы захватить весь процессор (все исполняющие блоки) и исполнение второго участка кода (исполняемого на втором «виртуальном CPU») было бы прервано. Насколько мы поняли, данный механизм (пока?) не является интеллектуальным т. е. не способен оперировать различными приоритетами, а просто чередует команды из двух разных цепочек в порядке живой очереди т. е. просто по принципу «я твою команду исполнил — теперь уступи место другому потоку». Если, конечно, не возникает ситуации, когда команды одной цепочки по исполняющим блокам нигде не конкурируют с командами другой. В этом случае мы получаем действительно на 100% параллельное исполнение двух фрагментов кода.
Теперь давайте подумаем, чем Hyper-Threading потенциально хороша, и чем — нет. Самое очевидное следствие ее применения — повышение коэффициента полезного действия процессора. Действительно — если одна из программ использует в основном целочисленную арифметику, а вторая — выполняет вычисления с плавающей точкой, то во время исполнения первой FPU просто ничего не делает, а во время исполнения второй — наоборот, ничего не делает ALU. Казалось бы, на этом можно закончить. Однако мы рассмотрели лишь идеальный (с точки зрения применения Hyper-Threading) вариант. Давайте теперь рассмотрим другой: обе программы задействуют одни и те же блоки процессора. Понятно, что ускорить выполнение в данном случае довольно сложно — ибо физическое количество исполняющих блоков от «виртуализации» не изменилось. А вот не замедлится ли оно? Давайте разберемся. В случае с процессором без Hyper-Threading мы имеем просто «честное» поочередное выполнение двух программ на одном ядре с арбитром в виде операционной системы (которая сама представляет собой еще одну программу), и общее время их работы определяется:
1. временем выполнения кода программы №1
2. временем выполнения кода программы №2
3. временными издержками на переключение между фрагментами кода программ №1 и №2
Что мы имеем в случае с Hyper-Threading? Схема становится немного другой:
1. время выполнения программы №1 на процессоре №1 (виртуальном)
2. время выполнения программы №2 на процессоре №2 (виртуальном)
3. время на переключение одного физического ядра (как набора требуемых обеим программам исполняющих блоков) между двумя эмулируемыми «виртуальными CPU»
Остается признать, что и тут Intel поступает вполне логично: конкурируют между собой по быстродействию у нас только пункты за номером три, и если в первом случае действие выполняется программно-аппаратно (ОС управляет переключением между потоками, задействуя для этого функции процессора), то во втором случае мы фактически имеем полностью аппаратное решение — процессор все делает сам. Теоретически, аппаратное решение всегда оказывается быстрее. Подчеркнем — теоретически. Но и это еще не все. Также одним из серьезнейших неприятных моментов является то, что команды, увы, не исполняются в безвоздушном пространстве, но вместо этого Pentium 4 приходится иметь дело с классическим x86-кодом, в котором активно используется прямое адресование ячеек и даже целых массивов, находящихся за пределами процессора — в ОЗУ. Да и вообще, к слову, большинство обрабатываемых данных чаще всего находится там :). Поэтому «драться» между собой наши виртуальные CPU будут не только за регистры, но и за общую для обоих процессорную шину, минуя которую данные в CPU попасть просто не могут. Однако тут есть один тонкий момент: на сегодняшний день «честные» двухпроцессорные системы на Pentium III и Xeon находятся в точно такой же ситуации! Ибо наша старая добрая шина AGTL+, доставшаяся в наследство всем сегодняшним процессорам Intel от знаменитого Pentium Pro (в дальнейшем ее лишь подвергали модификациям, но идеологию практически не трогали) — ВСЕГДА ОДНА, сколько бы CPU ни было установлено в системе. Вот такой вот «процессорный коаксиал» :). Отойти от этой схемы на x86 попробовала только AMD со своим Athlon MP — у AMD 760MP/760MPX от каждого процессора к северному мосту чипсета идет отдельная шина. Впрочем, даже в таком «продвинутом» варианте мы все равно убегаем от проблем не очень далеко — ибо уж что-что, а шина памяти у нас точно одна — причем вот в этом случае уже везде (напоминаем, разговор идет про x86-системы).
Однако нет худа без добра, и даже из этого в общем-то не очень приятного момента Hyper-Threading может помочь извлечь какую-то пользу. Дело в том, что по идее мы должны будем наблюдать существенный прирост производительности не только в случае с несколькими задачами, использующими разные функциональные блоки процессора, но и в том случае, если задачи по-разному работают с данными, находящимися в ОЗУ. Возвращаясь к старому примеру в новом качестве — если одно приложение у нас что-то усиленно считает «внутри себя», другое же — постоянно подкачивает данные из ОЗУ, то общее время выполнения их в случае использования Hyper-Threading по идее должно уменьшиться даже если они используют одинаковые блоки исполнения инструкций — хотя бы потому, что команды на чтение данных из памяти смогут обрабатываться в то время, пока наше первое приложение будет что-то усиленно считать.
Итак, подведем итог: технология Hyper-Threading с теоретической точки зрения выглядит весьма неплохо и, мы бы сказали, «адекватно», т. е. соответствует реалиям сегодняшнего дня. Уже довольно редко можно застать пользователя с одним сиротливо открытым окном на экране — всем хочется одновременно и музыку слушать, и по Internet бродить, и диски с любимыми MP3 записывать, а может даже, и поиграть на этом фоне в какую-нибудь стрелялку или стратегию, которые, как известно, процессор «любят» ну просто со страшной силой. С другой стороны, общеизвестно, что конкретная реализация способна иногда своей «кривизной» убить любую самую превосходную идею, и с этим мы тоже не раз встречались на практике.
