Рука, забудь о лени. Посмотрим,
кто у чьих ботфорт в конце
концов склонит свои колени…"
© х/ф "Д'артаньян и три мушкетера"
Некоторое время назад автор позволил себе "слегка поворчать" по поводу новой парадигмы от Intel — Hyper Threading. К чести корпорации Intel, недоумение автора не осталось ею незамеченной. А посему автору предложили помощь в выяснении (как деликатно дали оценку менеджеры корпорации) "настоящей" ситуации с технологией Hyper Threading. Ну что же — желание выяснить истину можно только похвалить. Не так ли, уважаемый читатель? По крайней мере, именно так звучит одна из прописных истин: правда — это хорошо. Что ж, будем стараться действовать в соответствии с данной фразой. Тем более, что действительно появилось некоторое количество новых сведений.
Для начала сформулируем, что же именно мы знаем про технологию Hyper Threading:
1. Данная технология предназначена для увеличения эффективности работы процессора. Дело в том, что, по оценкам Intel, большую часть времени работает всего 30% (кстати, достаточно спорная цифра — подробности ее вычисления неизвестны) всех исполнительных устройств в процессоре. Согласитесь, это достаточно обидно. И то, что возникла идея каким-то образом "догрузить" остальные 70% — выглядит вполне логично (тем более что сам по себе процессор Pentium 4, в котором и внедрят эту технологию, отнюдь не страдает от избыточной производительности на мегагерц). Так что эту идею автор вынужден признать вполне здравой.
2. Суть технологии Hyper Threading состоит в том, что во время исполнения одной "нити" программы простаивающие исполнительные устройства могут заняться исполнением другой "нити" программы (или "нити" другой программы). Или, например, исполняя одну последовательность команд, ожидать данных из памяти для исполнения другой последовательности.
3. Естественно, выполняя различные "нити", процессор должен каким-либо образом отличать, какие команды к какой "нити" относятся. Значит, есть какой-то механизм (некая метка), благодаря которой процессор отличает, к какой "нити" относятся команды.
4. Ясно также, что, учитывая небольшое количество регистров общего назначения в архитектуре х86 (всего 8), у каждой нити свой набор регистров. Впрочем, это уже давно не новость — данное ограничение архитектуры уже довольно давно обходится при помощи "переименования регистров". Другими словами, физических регистров намного больше, чем логических. В процессоре Pentium III их 40. Наверняка это число для Pentium 4 больше — у автора есть ничем не обоснованное (кроме соображений "симметрии" :-) мнение, что их порядка сотни. Никаких достоверных сведений об их количестве найти не удалось. По неподтвержденным пока данным, их 256. По другим данным — другое число. В общем, полная неопределенность…. Кстати, позиция Intel по этому поводу совершенно непонятна :-( — автору непонятно, чем вызвана подобная секретность.
5. Также известно, что в случае, когда несколько "нитей" претендуют на одни и те же ресурсы, либо одна из "нитей" ждет данных — во избежание падения производительности программисту необходимо вставлять специальную команду — "pause". Естественно, это потребует очередной перекомпиляции программ.
6. Также понятно, что возможны ситуации, когда попытки одновременного исполнения нескольких "нитей" приведут к падению производительности. Например, из-за того, что размер кэша L2 не бесконечный, а активные "нити" будут пытаться загрузить кэш — возможна ситуация, когда такая "борьба за кэш" приведет к постоянной очистке и перезагрузке данных в кэше второго уровня.
7. Intel утверждает, что при оптимизации программ под данную технологию выигрыш будет составлять до 30%. (Вернее, Intel утверждает, что на сегодняшних серверных приложениях и сегодняшних системах измеренный выигрыш до 30%) Гм…. Это более чем достаточный стимул для оптимизации.
Ну что же, некоторые особенности мы сформулировали. Теперь давайте попробуем обдумать некоторые следствия (по возможности опираясь на известные нам сведения). Что же можно сказать? Ну, во-первых, необходимо тщательнее разобраться, что же именно нам предлагают. Так ли "бесплатен" этот сыр? Для начала разберемся, как именно будет происходить "одновременная" обработка нескольких "нитей". Кстати, что подразумевает корпорация Intel под словом "нить"?
У автора сложилось впечатление (возможно, ошибочное), что в данном случае имеется ввиду программный фрагмент, который мультизадачная операционная система назначает на исполнение одному из процессоров мультипроцессорной аппаратной системы. "Постойте!" — заявит внимательный читатель — "это же одно из определений! Что тут нового?". А ничего — в данном вопросе автор на оригинальность не претендует. Разобраться бы, что "наоригинальничала" Intel :-). Ну что же — примем в качестве рабочей гипотезы.
Далее — исполняется некоторая нить. Тем временем декодер команд (кстати, полностью асинхронный и не входящий в пресловутые 20 стадий Net Burst) осуществляет выборку и дешифрацию (со всеми взаимозависимостями) в микроинструкции. Здесь надо пояснить, что автор подразумевает под словом "асинхронный" — дело в том, что результат "разваливания" х86 команд в микроинструкции происходит в блоке дешифрации. Каждая команда х86 может быть декодирована в одну, две, или более микроинструкций. При этом на стадии обработки выясняются взаимозависимости, доставляются необходимые данные по системной шине. Соответственно, скорость работы этого блока часто будет зависеть от скорости доступа данных из памяти — и в худшем случае определяется именно ею. Было бы логично "отвязать" его от того конвейера, в котором, собственно, и происходит выполнение микроопераций. Это было сделано путем помещения блока дешифрации перед trace cache. Чего мы этим добиваемся? А добиваемся мы при помощи такой "перестановки блоков" местами простой вещи — если в trace cache есть микроинструкции для исполнения — процессор работает более эффективно. Естественно, этот блок работает на частоте процессора — в отличие от Rapid Engine. Кстати, у автора сложилось впечатление, что данный декодер представляет собой нечто вроде конвейера длиной до 10–15 стадий. Таким образом, от выборки данных из кэша до получения результата проходит, по всей видимости, порядка 30 — 35 стадий (включая конвейер Net Burst, см. Microdesign Resources August2000 Microprocessor report Volume14 Archive8, page12).
Полученный набор микроинструкций вместе со всеми взаимозависимостями накапливается в trace cache — в том самом, который приблизительно 12 000 микроопераций. По приблизительным оценкам источник такой оценки — строение микроинструкции P6; дело в том, что принципиально длина инструкций вряд ли кардинально поменялась (считая длину микроинструкции вместе со служебными полями порядка 100 бит) размер trace cache получается от 96 КБ до 120 КБ!!! Однако! На фоне этого кэш данных размером 8 КБ выглядит как-то несимметрично :-)… и бледно. Конечно, при увеличении размера увеличиваются задержки доступа (к примеру, при увеличении до 32КБ задержки вместо двух тактов составят 4). Но неужели так важна скорость доступа в этот самый кэш данных, что увеличение задержки на 2 такта (на фоне общей длины всего конвейера) делает такое увеличение объема невыгодным? Или дело просто в нежелании увеличивать размер кристалла? Но тогда при переходе на 0.13 мкм первым делом стоило увеличить именно этот кэш (а не кэш второго уровня). Сомневающимся в данном тезисе стоило бы припомнить переход с Pentium на Pentium MMX — благодаря увеличению кэша первого уровня вдвое практически все программы получали 10 — 15% прироста производительности. Что же говорить об увеличении вчетверо (особенно учитывая, что скорости процессоров выросли до 2ГГц, а коэффициент умножения — с 2.5 до 20)? По неподтвержденным данным, в следующей модификации ядра Pentium4 (Prescott) кэш первого уровня таки увеличат до 16 или 32 КБ. Также увеличится кэш второго уровня. Впрочем, на сегодняшний момент все это не более чем слухи. Откровенно говоря, слегка непонятная ситуация. Хотя — оговоримся — автор вполне допускает, что подобной идее мешает некая конкретная причина. Как пример — подойдут некие требования по геометрии расположения блоков или банальная нехватка свободного места вблизи конвейера (ясно ведь, что необходимо расположить кэш данных поближе к ALU).
Не отвлекаясь, смотрим на процесс дальше. Конвейер работает — пусть нынешние команды задействуют ALU. Ясно, что FPU, SSE, SSE2 и прочие при этом простаивают. Не тут-то было — вступает в действие Hyper Threading. Заметив, что готовы микроинструкции вместе с данными для новой нити, блок переименования регистров выделяет новой нити порцию физических регистров. Кстати, возможны два варианта — блок физических регистров общий для всех нитей, или же отдельный для каждого. Судя по тому, что в презентации Hyper Threading от Intel в качестве блоков, которые надо изменять, блок переименования регистров не указан — выбран первый вариант. Это хорошо или плохо? С точки зрения технологов — явно хорошо, ибо экономит транзисторы. С точки зрения программистов — пока неясно. Если количество физических регистров действительно 128, то при любом разумном количестве нитей ситуации "нехватка регистров" возникнуть не может. Затем они (микроинструкции) отправляются в планировщик, который, собственно, направляет их на исполнительное устройство (если оно не занято) или "в очередь", если данное исполнительное устройство сейчас недоступно. Таким образом, в идеале достигается более эффективное спользование имеющихся исполнительных устройств. В это время сам процессор с точки зрения ОС выглядит как два "логических" процессора. Гм… Неужели все так безоблачно? Давайте присмотримся к ситуации: часть оборудования (как-то кэши, Rapid Engine, модуль предсказания переходов) являются общими для обоих процессоров. Кстати, точность предсказания переходов от этого, скорее всего, слегка пострадает. Особенно, если исполняемые одновременно нити не связаны друг с другом. А часть (например, MIS [Microcode Instruction Sequencer] — планировщик последовательности микрокоманд — подобие ПЗУ, содержащее набор заранее запрограммированных последовательностей обычных операций и RAT [Register Alias Table] — таблица переименования [псевдонимов] регистров) блоков должна отличать различные нити, запущенные на "разных" процессорах. Попутно (из общности кэша) следует, что, если две нити являются "жадными" к кэшу (то есть увеличение кэша дает большой эффект), то применение Hyper Threading способно даже снизить скорость. Это происходит потому, что на сегодняшний момент реализован "конкурентный" механизм борьбы за кэш — "активная" в данный момент нить вытесняет "неактивную". Впрочем, механизм кэширования, по-видимому, может измениться. Также понятно, что скорость (по крайней мере, на текущий момент) будет снижаться в тех приложениях, в которых она снижалась и в честном SMP. Как пример — SPEC ViewPerf обычно на однопроцессорных системах показывает более высокие результаты. А посему наверняка на системе с Hyper Threading результаты будут меньше, чем без нее. Собственно, результаты практического тестирования Hyper Threading можно посмотреть по этому адресу.
Кстати, в интернет проскакивала информация о том, что ALU в Pentium 4 16 разрядные. Сначала автор относился к подобной информации весьма скептически — дескать, чего завистники удумали :-). А потом публикация подобной информации в Micro Design Report заставила таки задуматься — а вдруг правда? И, хотя информация об этом к теме статьи прямого отношения не имеет - трудно удержаться :-). Насколько автору "хватило понимания", суть в том, что ALU действительно 16-разрядный. Подчеркиваю — только ALU. К разрядности самого процессора это отношения не имеет. Таким образом, за полтакта (это называется тик, tick) ALU (удвоенной частоты, как Вы помните) вычисляет только 16 разрядов. Вторые 16 вычисляются за следующие полтакта. Отсюда, кстати, легко понятна необходимость сделать ALU вдвое быстрее — это необходимо для своевременного "перемалывания" данных. Таким образом, полных 32 разряда вычисляются за полный такт. На самом деле, по-видимому, необходимы 2 такта из-за необходимости "склеивать" и "расклеивать" разряды — но этот вопрос необходимо уточнить. Собственно, раскопки (про которые можно написать отдельную поэму) дали следующее: каждое ALU поделено на 2 16-разрядные половинки. Первые полтакта первая половинка обрабатывает 16 разрядов двух чисел и формируют биты переносов для вторых половинок. Вторая половинка в это время заканчивает обработку предыдущих чисел. Второй тик — первая половинка ALU обрабатывает 16 разрядов от следующей пары чисел и формирует их переносы. Вторая половинка обрабатывает старшие 16 разрядов первой пары чисел и получает готовый 32-разрядный результат. Задержка получения 1 результата — 1 такт, но потом каждые полтакта вылезает по 1 32-разрядному результату. Достаточно остроумно и эффективно. Почему же была выбрана именно такая модель ALU? По видимому, подобной организацией Intel убивает несколько "зайцев":
1. Ясно, что конвейер "шириной" 16 разрядов разгонять легче, чем шириной 32 разряда — просто по причине наличия перекрестных помех и Ко
2. По-видимому, Интел счел операции целочисленного вычисления достаточно часто встречающимися, чтобы ускорять именно ALU, а не, скажем, FPU. Вероятно, при вычислении результатов целочисленных операций используются либо таблицы, либо схемы "с накоплением переноса". Для сравнения, одна 32-битная таблица это 2E32 адресов, т.е. 4гигабайта. Две 16-разрядные таблицы это 2х64кб или 128 килобайт — почувствуйте разницу! Да и накопление переносов в двух 16-разрядных порциях происходит быстрее, чем в одной 32-разрядной.
3. Экономит транзисторы и… тепло. Ведь ни для кого не секрет, что все эти архитектурные ухищрения греются. По видимому, это была достаточно большая (а, возможно, и главная) проблема — чего стоит, к примеру, Thermal Monitor как технология! Ведь необходимости в подобной технологии как таковой не очень много — то есть, конечно, приятно, что она есть. Но давайте говорить честно — простой блокировки хватило бы для достаточной надежности. Раз такая сложная технология была предусмотрена — значит, всерьез рассматривался вариант, когда подобные изменения частоты на ходу были одним из штатных режимов работы. А, может, основным? Ведь не зря ходили слухи, что Pentium 4 задумывался с гораздо большим количеством исполнительных устройств. Тогда проблема тепла должна была стать просто основной. Вернее, по тем же слухам, тепловыделение должно было составить до 150 Вт. А тогда очень логично принять меры к тому, чтобы процессор работал "в полную силу" только в таких системах, где обеспечено нормальное охлаждение. Тем более, что большинство корпусов "китайского" происхождения продуманностью конструкции с точки зрения охлаждения отнюдь не блещут. Гм…. Далековато забрались :-)
Но все это теоретизирования. Есть ли сегодня процессоры, в которых применяется эта технология? Есть. Это Xeon (Prestonia) и XeonMP. Причем, интересно, что XeonМР от Xeon отличается поддержкой до 4 процессоров (чипсеты типа IBM Summit поддерживают до 16 процессоров, методика приблизительно такая же, как и в чипсете ProFusion) и наличием кэша третьего уровня объемом 512 КБ и 1 МБ, интегрированного в ядро. Кстати, а почему интегрировали кэш именно третьего уровня? Почему не увеличен кэш первого уровня? Должна же быть какая-то разумная причина…. Почему не увеличили кэш второго уровня? Возможно, причина в том, что Advanced Transfer Cache нуждается в относительно небольших задержках. А увеличение объема кэша приводит к увеличению задержек. Посему кэш третьего уровня для ядра и кэша второго уровня вообще «представляется» как шина. Просто шина :-). Так что прогресс налицо — сделано все, чтобы данные подавались в ядро как можно быстрее (а, попутно, поменьше загружалась шина памяти).
Ну что же — получается, никаких особо узких мест и нет? Что же автор, так и не сможет "поворчать"? Один процессор - а ОС видит два. Хорошо! Два процессора — а ОС видит 4! Кррасота! Стоп! А какая это ОС у нас работает с 4-мя процессорами? Операционные системы от Микрософт, которые понимают больше двух процессоров, стоят совсем других денег. Например, 2000 Professional, XP Professional, NT4.0 понимают только два процессора. А, учитывая, что пока что данная технология предназначается на рынок рабочих станций (и серверов) и есть только в соответствующих процессорах - получается просто чертовски обидно. На сегодня мы можем использовать процессора с такой технологией, только купив двухпроцессорную плату и поставив один процессор. Чем дальше, тем "страньше", как говаривала Алиса в стране чудес…. То есть, человек, жаждущий использовать данную технологию, просто вынужден покупать версии Server и Advanced Server нынешних операционных систем. Ох, и дороговат выходит "бесплатный" процессор…. Стоит добавить, пожалуй, что в настоящий момент Intel активно "общается" с Microsoft, пытаясь привязать политику лицензирования к физическому процессору. По крайней мере, согласно документу, новые операционные системы от Microsoft будут лицензироваться по физическим процессорам. По крайней мере, WindowsXP лицензируется именно по количеству физических процессоров.
Естественно, всегда можно обратиться к операционным системам других производителей. Да только будем откровенными — это не очень хороший выход из текущей ситуации…. Так что можно понять колебания Интел, которая довольно долго думала — использовать эту технологию, или нет.
Ну что же — не забываем достаточно важный вывод: применение Hyper Threading способно привести как к выигрышу, так и к проигрышу в производительности. Ну а поскольку проигрыш нами уже обсужден — попробуем понять, что же необходимо для выигрыша: а для выигрыша необходимо, чтобы об этой технологии знали:
- BIOS материнской платы
- Операционная система (!!!)
- Собственно, само приложение
Вот на этом моменте позвольте остановиться поподробнее — дело в том, что за BIOS дело не станет. Операционную систему мы обсудили чуть ранее. А вот в те нити, которые, например, ожидают данных из памяти — придется вводить специальную команду pause, чтобы не замедлять работу процессора; ведь при отсутствии данных нить способна блокировать те или иные исполнительные устройства. А чтобы вставить эту команду, приложения придется перекомпилировать — это не есть хорошо, но, с легкой руки Intel, к этому в последнее время все стали привыкать :-). Таким образом, основной (по мнению автора) недостаток технологии Hyper Threading — это необходимость очередной компиляции. Основное преимущество такого подхода - подобная перекомпиляция попутно (и, скорее всего, более заметно :-) подымет производительность в "честных" двухпроцессорных системах — а это можно только приветствовать. Кстати, уже есть экспериментальные данные, которые подтверждают, что в большинстве случаев программы, оптимизированные под SMP, выигрывают от Hyper Threading от 15% до 18%. Это весьма неплохо. Кстати, там же можно увидеть, в каких случаях Hyper Threading приводит к падению производительности.
И напоследок давайте попробуем пофантазировать, что же может измениться (улучшиться) в дальнейшем развитии этой идеи. Достаточно очевидно, что развитие данной технологии будет прямо связано с развитием ядра Pentium 4. Таким образом, представим себе потенциальные изменения в ядре. Что там у нас дальше по плану? 0.09 микронная технология, более известная как 90нм…. Автор склонен считать (на сегодняшний момент), что развитие данного семейства процессоров пойдет сразу по нескольким направлениям:
- Благодаря более "тонкому" техпроцессу частота процессора станет еще выше.
- Будем надеяться, что кэш данных увеличат. Хотя бы до 32КБ.
- Сделают "честное", 32 разрядное ALU. Это должно поднять производительность.
- Увеличат скорость системной шины (впрочем, это уже в ближайших планах).
- Сделают двухканальную DDR память (опять же, ждать осталось относительно недолго).
- Возможно, введут аналог технологии х86-64, если данная технология (усилиями AMD) приживется. При этом автор изо всех сил надеется, что этот аналог будет совместимым с х86-64. Хватит уже плодить несовместимых друг с другом расширений…. Опять же, небезынтересным для нас будет интервью Джерри Сандерса, в котором тот заявил, что AMD и Intel в прошлом году договорились о кросс-лицензировании на все, кроме системной шины Pentium4. Значит ли это, что Intel встроит х86-64 в следующее ядро Pentium4 (Prescott), а AMD встроит в свои процессора Hyper Threading? Вопрос интересный….
- Возможно, будет увеличено количество исполнительных устройств. Правда, как и предыдущий, это достаточно спорный пункт, поскольку требует практически полного перепроектирования ядра — а это долгий и трудоемкий процесс.
Интересно, будет ли развиваться идея Hyper Threading? Дело в том, что в количественном отношении ей развиваться особо некуда — понятно, что два физических процессора лучше трех логических. Да и позиционировать будет нелегко…. Интересно, что Hyper Threading может пригодиться и при интегрировании двух (или более) процессоров на кристалл. Ну а под качественными изменениями автор имеет ввиду, что наличие такой технологии в обычных десктопах приведет к тому, что фактически большинство пользователей будут работать на [почти] двухпроцессорных машинах — что очень хорошо. Хорошо потому, что подобные машины работают не в пример "плавнее" и "отзывчивее" на действия пользователя даже под большой нагрузкой. Сие, с точки зрения автора, есть весьма хорошо.
Вместо послесловия
Автор должен признаться, что в течение работы над статьей его отношение к Hyper Threading неоднократно менялось. По мере того, как собиралась и обрабатывалась информация — отношение становилось то в целом положительным, то наоборот :-). На сегодняшний момент можно написать следующее:
есть только два способа повышать производительность — повышать частоту, и повышать производительность за такт. И, если вся архитектура Pentium4 рассчитана на первый путь, то Hyper Threading — как раз второй. Уже с этой точки зрения ее можно только приветствовать. Так же Hyper Threading несет несколько интересных следствий, как-то: изменение парадигмы программирования, привнесение многопроцессорности в массы, увеличение производительности процессоров. Однако, на этом пути есть несколько "больших кочек", на которых важно не "застрять": отсутствие нормальной поддержки со стороны операционных систем и, самое главное, необходимость перекомпиляции (а в некоторых случаях и смены алгоритма) приложений, чтобы они в полной мере смогли воспользоваться преимуществами Hyper Threading. К тому же, наличие Hyper Threading сделало бы возможной действительно параллельную работу операционной системы и приложений — а не "кусками" по очереди, как сейчас. Конечно, при условии, что хватит свободных исполнительных устройств.
Также хотелось бы сказать спасибо всем участникам форума, которые неоднократно высказывали ценные замечания.
