"…И мы горды и враг наш горд
Рука, забудь о лени. Посмотрим,
кто у чьих ботфорт в конце
концов склонит свои колени…"
© х/ф "Д"артаньян и три мушкетера"
Некоторое время назад автор позволил себе "слегка поворчать" по поводу новой парадигмы от 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 планировщик последовательности микрокоманд подобие ПЗУ, содержащее набор заранее запрограммированных последовательностей обычных операций и RAT таблица переименования [псевдонимов] регистров ) блоков должна отличать различные нити, запущенные на "разных" процессорах. Попутно (из общности кэша ) следует, что, если две нити являются "жадными" к кэшу (то есть увеличение кэша дает большой эффект ), то применение 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 сделало бы возможной действительно параллельную работу операционной системы и приложений а не "кусками" по очереди, как сейчас. Конечно, при условии, что хватит свободных исполнительных устройств.
Автор хотел подчеркнуть бы свою признательность Максиму Леню
(aka C.A.R.C.A.S.S.) и Илье Вайцману
(aka Stranger_NN) за неоднократную и неоценимую помощь при написании статьи.
Также хотелось бы сказать спасибо всем участникам форума, которые неоднократно высказывали ценные замечания.
Еще раз о Hyper-Threading
- Тестирование IT-систем ,
- Программирование
Было время, когда понадобилось оценить производительность памяти в контексте технологии Hyper-threading . Мы пришли к выводу, что ее влияние не всегда позитивно. Когда появился квант свободного времени, возникло желание продолжить исследования и рассмотреть происходящие процессы с точностью до машинных тактов и битов, используя программное обеспечение собственной разработки.
Исследуемая платформа
Объект экспериментов – ноутбук ASUS N750JK c процессором Intel Core i7-4700HQ. Тактовая частота 2.4GHz, повышаемая в режиме Intel Turbo Boost до 3.4GHz. Установлено 16 гигабайт оперативной памяти DDR3-1600 (PC3-12800), работающей в двухканальном режиме. Операционная система – Microsoft Windows 8.1 64 бита.Рис.1 Конфигурация исследуемой платформы.
Процессор исследуемой платформы содержит 4 ядра, что при включении технологии Hyper-Threading обеспечивает аппаратную поддержку 8 потоков или логических процессоров. Эту информацию Firmware платформы передает операционной системе посредством ACPI-таблицы MADT (Multiple APIC Description Table). Поскольку платформа содержит только один контроллер оперативной памяти, таблица SRAT (System Resource Affinity Table), декларирующая приближенность процессорных ядер к контроллерам памяти, отсутствует. Очевидно, исследуемый ноутбук не является NUMA-платформой , но операционная система, в целях унификации, рассматривает его как NUMA-систему с одним доменом, о чем говорит строка NUMA Nodes = 1. Факт, принципиальный для наших экспериментов – кэш память данных первого уровня имеет размер 32 килобайта на каждое из четырех ядер. Два логических процессора, разделяющие одно ядро, используют кэш-память первого и второго уровней совместно.
Исследуемая операция
Исследовать будем зависимость скорости чтения блока данных от его размера. Для этого выберем наиболее производительный метод, а именно чтение 256-битных операндов посредством AVX-инструкции VMOVAPD. На графиках по оси X отложен размер блока, по оси Y – скорость чтения. В окрестности точки X, соответствующей размеру кэш-памяти первого уровня, ожидаем увидеть точку перегиба, поскольку производительность должна упасть после того, как обрабатываемый блок выйдет за пределы кэш-памяти. В нашем тесте, в случае многопоточной обработки, каждый из 16 инициируемых потоков, работает с отдельным диапазоном адресов. Для управления технологией Hyper-Threading в рамках приложения, в каждом из потоков используется API-функция SetThreadAffinityMask, задающая маску, в которой каждому логическому процессору соответствует один бит. Единичное значение бита разрешает использовать заданный процессор заданным потоком, нулевое значение – запрещает. Для 8 логических процессоров исследуемой платформы, маска 11111111b разрешает использовать все процессоры (Hyper-Threading включен), маска 01010101b разрешает использовать по одному логическому процессору в каждом ядре (Hyper-Threading выключен).На графиках используются следующие сокращения:
MBPS (Megabytes per Second) – скорость чтения блока в мегабайтах в секунду ;
CPI (Clocks per Instruction) – количество тактов на инструкцию ;
TSC (Time Stamp Counter) – счетчик процессорных тактов .
Примечание.Тактовая частота регистра TSC может не соответствовать тактовой частоте процессора при работе в режиме Turbo Boost. Это необходимо учитывать при интерпретации результатов.
В правой части графиков визуализируется шестнадцатеричный дамп инструкций, составляющих тело цикла целевой операции, выполняемой в каждом из программных потоков, или первые 128 байт этого кода.
Опыт №1. Один поток
Рис.2 Чтение одним потоком
Максимальная скорость 213563 мегабайт в секунду. Точка перегиба имеет место при размере блока около 32 килобайт.
Опыт №2. 16 потоков на 4 процессора, Hyper-Threading выключен
Рис.3 Чтение шестнадцатью потоками. Количество используемых логических процессоров равно четырем
Hyper-Threading выключен. Максимальная скорость 797598 мегабайт в секунду. Точка перегиба имеет место при размере блока около 32 килобайт. Как и ожидалось, по сравнению с чтением одним потоком, скорость выросла приблизительно в 4 раза, по количеству работающих ядер.
Опыт №3. 16 потоков на 8 процессоров, Hyper-Threading включен
Рис.4 Чтение шестнадцатью потоками. Количество используемых логических процессоров равно восьми
Hyper-Threading включен. Максимальная скорость 800722 мегабайт в секунду, в результате включения Hyper-Threading почти не выросла. Большой минус – точка перегиба имеет место при размере блока около 16 килобайт. Включение Hyper-Threading немного увеличило максимальную скорость, но падение скорости теперь наступает при вдвое меньшем размере блока – около 16 килобайт, поэтому существенно упала средняя скорость. Это не удивительно, каждое ядро имеет собственную кэш-память первого уровня, в то время, как логические процессоры одного ядра, используют ее совместно.
Выводы
Исследованная операция достаточно хорошо масштабируется на многоядерном процессоре. Причины – каждое из ядер содержит собственную кэш-память первого и второго уровней, размер целевого блока сопоставим с размером кэш-памяти, и каждый из потоков работает со своим диапазоном адресов. В академических целях мы создали такие условия в синтетическом тесте, понимая, что реальные приложения обычно далеки от идеальной оптимизации. А вот включение Hyper-Threading, даже в этих условиях дало негативный эффект, при небольшой прибавке пиковой скорости, имеет место существенный проигрыш в скорости обработки блоков, размер которых находится в диапазоне от 16 до 32 килобайт.Впервые технология Hyper-Threading (HT, гиперпоточность) появилась 15 лет назад - в 2002 году, в процессорах Pentium 4 и Xeon, и с тех пор то появлялась в процессорах Intel (в линейке Core i, некоторых Atom, в последнее время еще и в Pentium), то исчезала (ее поддержки не было в линейках Core 2 Duo и Quad). И за это время она обросла мифическими свойствами - дескать ее наличие чуть ли не удваивает производительность процессора, превращая слабые i3 в мощные i5. При этом другие говорят что HT - обычная маркетинговая уловка, и толку от нее мало. Правда как обычно по середине - местами толк от нее есть, но двухкртаного прироста ждать точно не стоит.
Техническое описание технологии
Начнем с определения, данного на сайте Intel:
Технология Intel® Hyper-Threading (Intel® HT) обеспечивает более эффективное использование ресурсов процессора, позволяя выполнять несколько потоков на каждом ядре. В отношении производительности эта технология повышает пропускную способность процессоров, улучшая общее быстродействие многопоточных приложений.
В общем понятно то, что ничего не понятно - одни общие фразы, однако вкраце технологию они описывают - HT позволяет одному физическому ядру обрабатывать одновременно несколько (обычно два) логических потока. Но как? Процессор, поддерживающий гиперпоточность:
- может хранить информацию сразу о нескольких выполняющихся потоках;
- содержит по одному набору регистров (то есть блоков быстрой памяти внутри процессора) и по одному контроллеру прерываний (то есть встроенному блоку процессора, отвечающему за возможность последовательной обработки запросов о наступлении какого-либо события, требующего немедленного внимания, от разных устройств) на каждый логический процессор.
Допустим перед процессором стоят две задачи. Если процессор имеет одно ядро, то он будет выполнять их последовательно, если два - то параллельно на двух ядрах, и время выполнения обеих задач будет равно времени, затраченному на более тяжелую задачу. Но что если процессор одноядерный, но поддерживает гиперпоточность? Как видно на картинке выше при выполнении одной задачи процессор не занят на 100% - какие-то блоки процессора банально не нужны в данной задаче, где-то ошибается модуль предсказания переходов (который нужен для предсказания, будет ли выполнен условный переход в программе), где-то происходит ошибка обращения к кэшу - в общем и целом при выполнении задачи процессор редко бывает занят больше, чем на 70%. А технология HT как раз «подпихивает» незанятым блокам процессора вторую задачу, и получается что одновременно на одном ядре обрабатываются две задачи. Однако удвоения производительности не происходит по понятным причинам - очень часто получается так, что двум задачам нужен один и тот же вычислительный блок в процессоре, и тогда мы видим простой: пока одна задача обрабатывается, выполнение второй на это время просто останавливается (синие квадраты - первая задача, зеленые - вторая, красные - обращение задач к одному и тому же блоку в процессоре):
В итоге время, затраченное процессором с HT на две задачи, оказывается больше времени, требуемого на вычисление самой тяжелой задачи, но меньше того времени, которое нужно для последовательного вычисления обеих задач.
Плюсы и минусы технологии
С учетом того, что кристалл процессора с поддержкой HT физчески больше кристалла процессора без HT в среднем на 5% (именно столько занимают дополнительные блоки регистров и контроллеры прерываний), а поддержка HT позволяет нагрузить процессор на 90-95%, то в сравнении с 70% без HT мы получаем, что прирост в лучшем случае будет 20-30% - цифра достаточно большая.
Однако не все так хорошо: бывает, что прироста производительности от HT нет вообще, и даже бывает так, что HT ухудшает производительность процессора. Это бывает по многим причинам:
- Нехватка кэш-памяти. К примеру в современных четырехядерных i5 находится 6 мб кэша L3 - по 1.5 мб на ядро. В четырехядерных i7 с HT кэша уже 8 мб, но так как логических ядер 8, то мы получаем уже только 1 мб на ядро - при вычислениях некоторым программам этого объема может не хватать, что приводит к падению производительности.
- Отсутствие оптимизации ПО. Самая основная проблема - программы считают логические ядра физическими, из-за чего при параллельном выполнении задач на одном ядре часто возникают задержки из-за обращения задач к одному и тому же вычислительному блоку, что в итоге сводит сводит прирост производительности от HT на нет.
- Зависимость данных. Вытекает из предыдущего пункта - для выполнения одной задачи требуется результат другой, а она еще не выполнена. И опять же мы получаем простой, снижение загрузки на процессор и небольшой прирост от HT.
Таких много, ибо для вычислений HT это манна небесная - тепловыделение практически не растет, процессор особо больше не становится, а при правильной оптимизации можно получить прирост до 30%. Поэтому ее поддержку быстро внедрили в те программы, где легко можно сделать распараллеливание нагрузки - в архиваторы (WinRar), программы для 2D/3D моделирования (3ds Max, Maya), программы для обрабокти фото и видео (Sony Vegas, Photoshop, Corel Draw).
Программы, плохо работающие с гиперпоточностью
Традиционно это большинство игр - их обычно бывает трудно грамотно распараллелить, поэтому зачастую четырех физических ядер на высоких частотах (i5 K-серии) более чем хватает для игр, распараллелить которые под 8 логических ядер в i7 оказывается непосильной задачей. Однако стоит учитывать и то, что есть фоновые процессы, и если процессор не поддерживает HT, то их обработка ложится на физические ядра, что может замедлить игру. Тут i7 с HT оказывается в выигрыше - все фоновые задачи традиционно имеют пониженный приоритет, поэтому при одновременной работе на одном физическом ядре игры и фоновой задаче игра будет получать повышенный приоритет, и при этом фоновая задача не будет «отвлекать» занятые игрой ядра - именно поэтому для стриминга или записи игр лучше брать i7 с гиперпоточностью.
Итоги
Пожалуй тут остается только один вопрос - так имеет ли смысл брать процессоры с HT или нет? Если вы любите держать одновременно открытыми пяток программ и при этом играть в игры, или же занимаетесь обработкой фото, видео или моделированием - да, разумеется стоит брать. А если вы привыкли перед запуском тяжелой программы закрывать все другие, и не балуетесь обработкой или моделированием, то процессор с HT вам ни к чему.
Мы писали, что использование однопроцессорных Xeon-систем лишено всякого смысла, поскольку при более высокой цене их производительность будет такой же, как и у Pentium 4 той же частоты. Теперь же, после более тщательного изучения, в это утверждение наверняка придется внести небольшую поправку. Технология Hyper-Threading, реализованная в Intel Xeon с ядром Prestonia, действительно работает и дает вполне ощутимый эффект. Хотя и вопросов при ее использовании тоже возникает немало…
Даешь производительность
"Быстрее, еще быстрее…". Гонка за производительностью длится уже не первый год, и порой даже трудно сказать, какой из компонентов компьютера ускоряется быстрее. Для этого изобретаются все новые и новые способы, и чем дальше, тем больше квалифицированного труда и высококачественных мозгов вкладывается в этот лавинообразный процесс.
Постоянный рост быстродействия, безусловно, нужен. По крайней мере, это прибыльный бизнес, и всегда найдется красивый способ подвигнуть пользователей на очередной апгрейд вчерашнего "суперпроизводительного CPU" на завтрашний "еще более супер…". Например, синхронное распознавание речи и синхронный же перевод на другой язык - это ли не мечта всех и каждого? Или необычайно реалистичные игры почти "киношного" качества (целиком поглощающие внимание и порой приводящие к серьезным изменениям в психике) - это ли не стремление множества геймеров от мала до велика?
Но давайте в данном случае вынесем за скобки маркетинговые аспекты, сосредоточившись на технических. Тем более что не все так уж мрачно: есть насущные задачи (серверные приложения, научные расчеты, моделирование и пр.), где все более высокая производительность, в частности центральных процессоров, действительно необходима.
Итак, какими же способами добиться увеличения их быстродействия?
Повышение тактовой частоты . Можно и дальше "утоньшать" технологический процесс и наращивать частоту. Но, как известно, это непросто и чревато всевозможными побочными эффектами вроде проблем с тепловыделением.
Наращивание ресурсов процессора - например, наращивание объема кэша, добавление новых блоков (Execution Units). Все это влечет за собой рост числа транзисторов, усложнение процессора, увеличение площади кристалла, а следовательно, стоимости.
Кроме того, предыдущие два способа дают, как правило, отнюдь не линейное повышение производительности. Это хорошо известно на примере Pentium 4: ошибки в предсказании ветвлений и прерывания вызывают сброс длинного конвейера, что сильно сказывается на общем быстродействии.
Многопроцессорность . Установка нескольких CPU и распределение работы между ними часто оказываются достаточно эффективными. Но такой подход не очень дешев - каждый дополнительный процессор увеличивает стоимость системы, да и дуальная материнская плата намного дороже обычной (не говоря уже о платах с поддержкой четырех и более CPU). Кроме того, далеко не все приложения получают от многопроцессорности выигрыш в производительности, достаточный для оправдания затрат.
Кроме "чистой" многопроцессорности, существует несколько "промежуточных" вариантов, позволяющих ускорить выполнение приложений:
Chip Multiprocessing (CMP) - два процессорных ядра физически располагаются на одном кристалле, используя общий или раздельный кэш. Естественно, размер кристалла получается достаточно большим, и на стоимости это не может не сказаться. Заметим, что несколько таких "сдвоенных" CPU также могут работать в многопроцессорной системе.
Time-Slice Multithreading . Процессор переключается между программными потоками через фиксированные промежутки времени. Накладные расходы порой получаются довольно внушительными, особенно если какой-либо процесс находится в ожидании.
Switch-on-Event Multithreading . Переключение задач при возникновении длительных пауз, например "непопаданий в кэш" (cache misses), большое число которых характерно для серверных приложений. В этом случае процесс, ожидающий загрузки данных из сравнительно медленной памяти в кэш, приостанавливается, высвобождая ресурсы CPU для других процессов. Однако Switch-on-Event Multithreading, как и Time-Slice Multithreading, не всегда позволяет достичь оптимального использования ресурсов процессора, - в частности из-за ошибок в предсказании ветвлений, зависимости инструкций и т. д.
Simultaneous Multithreading . В этом случае программные потоки выполняются на одном процессоре "одновременно", т. е. без переключения между ними. Ресурсы CPU распределяются динамически, по принципу "не используешь - отдай другому". Именно такой подход положен в основу технологии Intel Hyper-Threading, к рассмотрению которой мы и переходим.
Как работает Hyper-Threading
Как известно, нынешняя "парадигма компьютинга" предполагает многопоточные вычисления. Это касается не только серверов, где такое понятие существует изначально, но и рабочих станций и настольных систем. Потоки (threads) могут относиться как к одному, так и к разным приложениям, но почти всегда активных потоков больше, чем один (чтобы убедиться в этом, достаточно в Windows 2000/XP открыть Task Manager и включить отображение числа потоков). Вместе с тем обычный процессор может в один момент времени выполнять только один из потоков и вынужден постоянно переключаться между ними.
Впервые технология Hyper-Threading была реализована в процессоре Intel Xeon MP (Foster MP), на котором и шла ее "обкатка". Напомним, что Xeon MP, официально представленный на IDF Spring 2002, использует родственное Pentium 4 Willamette ядро, содержит 256 KB L2-кэша и 512 KB/1 MB L3-кэша и поддерживает работу в 4-процессорных конфигурациях. Также поддержка Hyper-Threading наличествует в процессоре для рабочих станций - Intel Xeon (ядро Prestonia, 512 KB L2-кэша), вышедшем на рынок несколько раньше, чем Xeon MP. С двухпроцессорными конфигурациями на Intel Xeon наши читатели уже знакомы , поэтому мы рассмотрим возможности Hyper-Threading именно на примере этих CPU - как теоретически, так и практически. Как бы там ни было, а "простой" Xeon - вещь более приземленная и удобоваримая, чем Xeon MP в 4-процессорных системах…
Принцип действия Hyper-Threading основывается на том, что в каждый момент времени только часть ресурсов процессора используется при выполнении программного кода. Неиспользуемые ресурсы также можно загрузить работой - например, задействовать для параллельного выполнения еще одного приложения (либо другого потока этого же приложения). В одном физическом процессоре Intel Xeon формируются два логических процессора (LP - Logical Processor), которые разделяют между собой вычислительные ресурсы CPU. Операционная система и приложения "видят" именно два CPU и могут распределять работу между ними, как и в случае полноценной двухпроцессорной системы.
Одна из целей реализации Hyper-Threading - при наличии только одного активного потока позволить ему выполняться с тем же быстродействием, как и на обычном CPU. Для этого у процессора предусмотрены два основных режима работы: Single-Task (ST) и Multi-Task (MT). В режиме ST активным является только один логический процессор, который безраздельно пользуется доступными ресурсами (режимы ST0 и ST1); другой LP остановлен командой HALT. При появлении второго программного потока бездействовавший логический процессор активируется (посредством прерывания), и физический CPU переводится в режим MT. Останов неиспользуемых LP командой HALT возложен на операционную систему, которая в итоге и отвечает за такое же быстрое выполнение одного потока, как и в случае без Hyper-Threading.
Для каждого из двух LP хранится так называемый Architecture State (AS), что включает в себя состояние регистров различного типа - общего назначения, управляющих, APIC и служебных. У каждого LP есть свои APIC (контроллер прерываний) и набор регистров, для корректной работы с которыми вводится понятие Register Alias Table (RAT), отслеживающей соответствие между восемью регистрами общего назначения IA-32 и 128 регистрами физического CPU (по одной RAT на каждый LP).
При работе двух потоков поддерживаются два соответствующих набора Next Instruction Pointers. Большая часть инструкций берется из Trace Cache (TC), где они хранятся в декодированном виде, и доступ к TC два активных LP получают поочередно, через такт. В то же время, когда активен только один LP, он получает монопольный доступ к TC без чередования по тактам. Аналогичным же образом происходит и доступ к Microcode ROM. Блоки ITLB (Instruction Translation Look-aside Buffer), задействующиеся при отсутствии необходимых инструкций в кэше команд, дублируются и доставляют команды каждый для своего потока. Блок декодирования инструкций IA-32 Instruction Decode является разделяемым и в случае, когда требуется декодирование инструкций для обоих потоков, обслуживает их поочередно (опять-таки через такт). Блоки Uop Queue и Allocator разделяются надвое, отводя по половине элементов для каждого LP. Schedulers числом 5 штук обрабатывают очереди декодированных команд (Uops) несмотря на принадлежность к LP0/LP1 и направляют команды на выполнение нужным Execution Units - в зависимости от готовности к выполнению первых и доступности вторых. Кэши всех уровней (L1/L2 для Xeon, а также L3 для Xeon MP) являются полностью разделяемыми между двумя LP, однако для обеспечения целостности данных записи в DTLB (Data Translation Look-aside Buffer) снабжаются дескрипторами в виде ID логических процессоров.
Таким образом, инструкции обоих логических CPU могут выполняться одновременно на ресурсах одного физического процессора, которые подразделяются на четыре класса:
- дублируемые (Duplicated);
- полностью разделяемые (Fully Shared);
- с дескрипторами элементов (Entry Tagged);
- динамически разделяемые (Partitioned) в зависимости от режима работы ST0/ST1 или MT.
При этом большинство приложений, получающих ускорение в многопроцессорных системах, могут также ускоряться и на CPU со включенным Hyper-Threading без каких-либо модификаций. Но существуют и проблемы: например, если один процесс находится в цикле ожидания, он может занять все ресурсы физического CPU, препятствуя работе второго LP. Таким образом, производительность при использовании Hyper-Threading может иногда и падать (до 20%). Для предотвращения этого Intel рекомендует вместо пустых циклов ожидания использовать инструкцию PAUSE (появилась в IA-32 начиная с Pentium 4). Также ведется достаточно серьезная работа по автоматической и полуавтоматической оптимизации кода при компиляции - например, в этом отношении ощутимо продвинулись компиляторы серии Intel OpenMP C++/Fortran Compilers ().
Еще одной целью первой реализации Hyper-Threading, по словам Intel, было сведение к минимуму роста числа транзисторов, площади кристалла и энергопотребления при заметном приросте быстродействия. Первая часть этого обязательства уже выполнена: добавление в Xeon/Xeon MP поддержки Hyper-Threading увеличило площадь кристалла и энергопотребление менее чем на 5%. Что же получилось со второй частью (производительностью), нам еще предстоит проверить.
Практическая часть
По вполне понятным причинам мы не проводили тестов 4-процессорных серверных систем на Xeon MP со включенным Hyper-Threading. Во-первых, это достаточно трудоемко. А во-вторых, решись мы на такой подвиг - все равно сейчас, менее чем через месяц после официального объявления, абсолютно нереально заполучить это дорогостоящее оборудование. Поэтому решено было ограничиться той же системой с двумя Intel Xeon 2.2 GHz, на которой проводилось первое тестирование этих процессоров (см. ссылку в начале статьи). Система основывалась на материнской плате Supermicro P4DC6+ (чипсет Intel i860), содержала 512 MB RDRAM-памяти, видеокарту на чипе GeForce3 (64 MB DDR, драйверы Detonator 21.85), жесткий диск Western Digital WD300BB и 6X DVD-ROM; в качестве ОС использовалась Windows 2000 Professional SP2.
Для начала несколько общих впечатлений. При установке одного Xeon с ядром Prestonia на старте системы BIOS выводит сообщение о наличии двух CPU; если же установлены два процессора, пользователь видит сообщение о четырех CPU. Операционная система нормально распознает "оба процессора", но только если выполнены два условия.
Во-первых, в CMOS Setup у последних версий BIOS плат Supermicro P4DCxx появился пункт Enable Hyper-Threading, без разрешения которого ОС распознает только физический процессор(-ы). Во-вторых, для сообщения ОС о наличии дополнительных логических процессоров используются возможности ACPI. Поэтому для задействования Hyper-Threading в CMOS Setup должна быть включена опция ACPI, и для самой ОС также должен быть установлен HAL (Hardware Abstraction Layer) с поддержкой ACPI. Благо, в Windows 2000 смена HAL со Standard PC (или MPS Uni-/Multiprocessor PC) на ACPI Uni-/Multiprocessor PC производится легко - заменой "драйвера компьютера" в менеджере устройств. В то же время для Windows XP единственным законным способом перехода на ACPI HAL является переустановка системы поверх существующей инсталляции.
Но вот все приготовления сделаны, и наша Windows 2000 Pro уже свято верит в то, что работает на двухпроцессорной системе (хотя на самом деле процессор установлен только один). Теперь по традиции пора определиться с целями тестирования. Итак, мы хотим:
- Оценить влияние Hyper-Threading на производительность приложений различного класса.
- Сравнить этот эффект с эффектом от установки второго процессора.
- Проверить, насколько "честно" ресурсы отдаются активному логическому процессору, когда второй LP бездействует.
Для оценки производительности мы взяли уже знакомый читателям набор приложений, использовавшийся в тестированиях workstation-систем. Начнем, пожалуй, с конца и проверим "равноправность" логических CPU. Все предельно просто: сначала мы проводим тесты на одном процессоре с отключенным Hyper-Threading, а затем повторяем процесс, включив Hyper-Threading и используя только один из двух логических CPU (с помощью Task Manager). Поскольку в данном случае нас интересуют лишь относительные значения, результаты всех тестов приведены к виду "больше - лучше" и нормализованы (за единицу взяты показатели однопроцессорной системы без Hyper-Threading).
Что ж, как можно видеть, обещания Intel здесь выполнены: при наличии только одного активного потока производительность каждого из двух LP в точности равна быстродействию физического CPU без Hyper-Threading. Бездействующий LP (причем как LP0, так и LP1) действительно приостанавливается, а разделяемые ресурсы, насколько об этом можно судить по полученным результатам, полностью передаются в пользование активному LP.
Поэтому делаем первый вывод: два логических процессора на самом деле являются равноправными, а включение Hyper-Threading "не мешает" работе одного потока (что само по себе уже неплохо). Посмотрим теперь, "помогает" ли это включение, и если да, то где и как?
Рендеринг . Результаты четырех тестов в пакетах 3D-моделирования 3D Studio MAX 4.26, Lightwave 7b и A|W Maya 4.0.1 объединены в одну диаграмму ввиду их похожести.
Во всех четырех случаях (для Lightwave - две различные сцены) загрузка CPU при наличии одного процессора с выключенным Hyper-Threading практически постоянно держится на уровне 100%. Тем не менее при включении Hyper-Threading расчет сцен ускоряется (в результате чего у нас даже родилась шутка о загрузке CPU более 100%). В трех тестах виден прирост производительности от Hyper-Threading 14--18% - с одной стороны, негусто по сравнению со вторым CPU, но с другой - весьма неплохо, учитывая "бесплатность" этого эффекта. В одном из двух тестов с Lightwave прирост быстродействия практически нулевой (видимо, сказывается специфика этого полного странностей приложения). Но отрицательного результата нет нигде, а заметный прирост в трех других случаях обнадеживает. И это при том, что параллельные процессы рендеринга делают сходную работу и наверняка не лучшим образом могут одновременно задействовать ресурсы физического CPU.
Photoshop и MP3-кодирование . Кодек GOGO-no-coda 2.39c один из немногих поддерживает SMP, и на нем заметен 34%-ный прирост быстродействия от двухпроцессорности. Вместе с тем эффект от Hyper-Threading в данном случае нулевой (разницу в 3% мы существенной не считаем). А вот в тесте с Photoshop 6.0.1 (скрипт, состоящий из большого набора команд и фильтров) видно замедление при включении Hyper-Threading, хотя второй физический CPU добавляет в этом случае 12% производительности. Вот, собственно, первый случай, когда Hyper-Threading вызывает падение быстродействия…
Профессиональный OpenGL . То, что SPEC ViewPerf и многие другие OpenGL-приложения часто замедляются в SMP-системах, известно давно.
OpenGL и двухпроцессорность: почему они не дружат
Много раз в статьях мы обращали внимание читателей на то, что двухпроцессорные платформы при выполнении профессиональных OpenGL-тестов очень редко показывают хоть сколько-нибудь существенное преимущество по сравнению с однопроцессорными. И мало того, нередки случаи, когда установка второго процессора наоборот, ухудшает быстродействие системы при отрисовке динамичных трехмерных сцен.
Естественно, замечали эту странность не только мы. Некоторые тестеры просто молча обходили этот факт - например, приводя результаты сравнения по тестам SPEC ViewPerf только для двухпроцессорных конфигураций, избегая таким образом объяснений "почему двухпроцессорная система медленнее?". Другие же строили все возможные фантастические предположения о когерентности кэшей, необходимости ее поддерживать, возникающих из-за этого накладных расходах и т.п. И почему-то никого не удивляло, что, например, следить за когерентностью процессорам почему-то приспичило именно при оконном OpenGL-рендеринге (по своей "вычислительной" сути мало чем отличающемся от любой другой расчетной задачи).
На самом же деле объяснение, на наш взгляд, намного более простое. Как известно, приложение может выполняться на двух процессорах быстрее, чем на одном, если:
- есть более два или больше одновременно выполняющихся программных потока (threads);
- эти потоки не мешают выполнению один другого - например, не конкурируют за общий ресурс вроде внешнего накопителя или сетевого интерфейса.
Теперь же упрощенно рассмотрим как выглядит OpenGL-рендеринг, выполняемый двумя потоками. Если приложение, "видя" два процессора, создает два потока OpenGL-рендеринга, то для каждого из них, согласно правилам OpenGL, создается свой gl-контекст. Соответственно каждый поток выполняет рендеринг в свой gl-контекст. Но проблема в том, что для окна, в которое происходит вывод изображения, только один gl-контекст может быть текущим в каждый момент. Соответственно потоки в этом случае просто "по очереди" выводят сгенерированное изображение в окно, делая попеременно свой контекст текущим. Нужно ли говорить, что такое "чередование контекстов" может очень дорого обходиться в смысле накладных расходов?
Также для примера приведем графики использования двух CPU в нескольких приложениях, отображающих OpenGL-сцены. Все измерения проведены на платформе следующей конфигурации:
- один или два Intel Xeon 2.2 GHz (Hyper-Threading отключен);
- 512 MB RDRAM-памяти;
- материнская плата Supermicro P4DC6+;
- видеокарта ASUS V8200 Deluxe (NVidia GeForce3, 64 MB DDR SDRAM, драйверы Detonator 21.85);
- Windows 2000 Professional SP2;
- видеорежим 1280x1024x32 bpp, 85 Hz, Vsync отключен.
Синим и красным изображены графики загруженности CPU 0 и CPU 1 соответственно. Линия посередине - итоговый график CPU Usage. Три графика соответствуют двум сценам из 3D Studio MAX 4.26 и части теста SPEC ViewPerf (AWadvs-04).
CPU Usage: анимация 3D Studio MAX 4.26 - Anibal (with manipulators).max
CPU Usage: анимация 3D Studio MAX 4.26 - Rabbit.max
CPU Usage: SPEC ViewPerf 6.1.2 - AWadvs-04Такая же картина повторяется еще в массе других приложений, задействующих OpenGL. Два процессора совершенно не утруждаются работой, и общий CPU Usage оказывается на уровне 50-60%. В то же время для однопроцессорной системы во всех этих случаях CPU Usage уверенно держится на уровне 100%.
Поэтому неудивительно то, что очень многие OpenGL-приложения не слишком ускоряются в дуальных системах. Ну а то, что они порой даже замедляются, имеет, на наш взгляд, вполне логичное объяснение.
Мы можем констатировать, что при двух логических CPU падение быстродействия еще более значительно, что вполне объяснимо: два логических процессора мешают друг другу точно так же, как и два физических. Но их общая производительность, естественно, оказывается при этом ниже, поэтому при включении Hyper-Threading она снижается еще больше, чем просто при работе двух физических CPU. Результат предсказуемый и вывод простой: Hyper-Threading, как и "настоящий" SMP, для OpenGL бывает противопоказан.
CAD-приложения . Предыдущий вывод подтверждается и результатами двух CAD-тестов - SPECapc for SolidEdge V10 и SPECapc for SolidWorks. Показатели графических составляющих этих тестов для Hyper-Threading похожи (хотя в случае SMP-системы для SolidEdge V10 результат немного выше). А вот результаты нагружающих процессор тестов CPU_Score заставляют задуматься: 5--10%-ный прирост от SMP и 14--19%-ное замедление от Hyper-Threading.
Но в конце концов, Intel честно признает в некоторых случаях возможность падения производительности при Hyper-Threading - например, при использовании пустых циклов ожидания. Мы можем лишь предположить, что это и является причиной (детальное исследование кода SolidEdge и SolidWorks выходит за рамки статьи). Ведь всем известен консерватизм разработчиков CAD-приложений, предпочитающих проверенную надежность и не особо спешащих переписывать код с учетом новых веяний в программировании.
Подведение итогов, или "Внимание, правильный вопрос"
Hyper-Threading работает, в этом никаких сомнений не остается. Безусловно, технология не универсальна: есть приложения, которым "плохеет" от Hyper-Threading, и в случае распространения этой технологии их желательно будет модифицировать. Но разве не то же самое произошло в свое время с MMX и SSE и продолжает происходить с SSE2?..
Однако здесь встает вопрос о применимости этой технологии к нашим реалиям. Вариант однопроцессорной системы на Xeon с Hyper-Threading мы отбросим сразу (или допустим только как временный, в ожидании покупки второго процессора): даже 30%-ный прирост производительности никак не оправдывает цену - тогда уж лучше приобрести обычный Pentium 4. Остается число CPU от двух и выше.
А теперь давайте вообразим, что мы покупаем двухпроцессорную систему на Xeon (скажем, с Windows 2000/XP Professional). Два CPU установлены, Hyper-Threading включен, BIOS находит целых четыре логических процессора, сейчас ух как взлетим… Стоп. А вот сколько процессоров увидит наша операционная система? Правильно, два. Всего два, поскольку на большее число она просто не рассчитана. Это будут два физических процессора, т. е. работать все будет точно так же, как и при отключенном Hyper-Threading, - не медленнее (два "дополнительных" логических CPU просто остановятся), но и не быстрее (проверено дополнительными тестами, результаты не приводим по причине их полной очевидности). М-да, приятного мало…
Что же остается? Ну не ставить же Advanced Server или.NET Server на нашу workstation в самом деле? Нет, система-то установится, опознает все четыре логических процессора и будет функционировать. Вот только серверная ОС смотрится на рабочей станции, мягко говоря, немного странно (не говоря уже о финансовых аспектах). Единственный разумный случай - это когда наша двухпроцессорная Xeon-система и будет выполнять роль сервера (по крайней мере, некоторые сборщики ничтоже сумняшеся уже наладили выпуск серверов на workstation-процессорах Xeon). Но вот для дуальных workstation с соответствующими ОС применимость Hyper-Threading остается под вопросом. Intel сейчас активно выступает за лицензирование ОС по числу не логических, а физических CPU. Дискуссии пока еще идут, и, в общем-то, многое зависит от того, увидим ли мы ОС для рабочих станций с поддержкой четырех процессоров.
Ну а с серверами все выходит достаточно просто. Например, Windows 2000 Advanced Server, установленный на двухпроцессорную Xeon-систему со включенным Hyper-Threading, "увидит" четыре логических процессора и будет преспокойно на ней работать. Для оценки того, что дает Hyper-Threading в серверных системах, мы приводим результаты Intel Microprocessor Software Labs для двухпроцессорных систем на Xeon MP и нескольких серверных приложений Microsoft.
Прибавка производительности 20--30% для двухпроцессорного сервера "задаром" - вещь более чем заманчивая (особенно по сравнению с покупкой "настоящей" 4-процессорной системы).
Вот и выходит, что на текущий момент практическая применимость Hyper-Threading возможна только в серверах. Вопрос же с рабочими станциями зависит от решения с лицензированием ОС. Хотя и еще одно применение Hyper-Threading вполне реально - если и настольные процессоры получат поддержку этой технологии. К примеру (пофантазируем), чем плоха система с Pentium 4 с поддержкой Hyper-Threading, на которую установлена Windows 2000/XP Professional с поддержкой SMP?.. Впрочем, ничего невероятного в этом нет: полные энтузиазма разработчики Intel обещают повсеместное внедрение Hyper-Threading - от серверов до настольных и мобильных систем.
Еще в далеком феврале 2002 года дебютировала фирменная технология от компании «Интел» - Hyper-Threading. Что этотакое и почему она получила на сегодняшний день практически повсеместное распространение? Ответ на этот вопрос и не только будет рассмотрен в данном материале.
История появления технологии HT
Первым настольным процессором с поддержкой логической многопоточности стал четвертого поколения Pentium. Hyper-Threading - технология, котораяв этом случае позволяла на одном физическом ядре обрабатывать сразу два потока данных. Причем чип этот устанавливался в процессорный разъем PGA478, функционировал он в режиме 32-битных вычислений, а его тактовая частота была равна 3,06 ГГц. До этого ее можно было встретить лишь в серверных процессорных устройствах серии XEON.
После получения успешных результатов в этой нише компания «Интел» решила распространить HT и в настольный сегмент. В дальнейшем в рамках PGA478 было выпущено целое семейство таких процессоров. После того как дебютировал сокет LGA775, НТ была временно призабыта. Но с началом продаж LGA1156 она получила второе дыхание в 2009 году. С тех пор она стала обязательным атрибутом процессорных решений от «Интел», причем как в ультрапроизводительном сегменте, так в бюджетных компьютерных системах.
Концепция данной технологии
Суть технологии Intel Hyper-Threadingсводится к тому, что путем минимальных изменений в компоновке микропроцессорного устройства разработчики добиваются того, что на уровне системного и программного обеспечения код обрабатывается в два потока на одном физическом ядре. Все элементы вычислительного модуля при этом остаются без изменений, добавляются лишь специальные регистры и переработанный контроллер прерываний.
Если по каким-либо причинам физический модуль вычислений начинает простаивать, то на нем запускается второй программный поток, а первый при этом дожидается получения необходимых данных или информации. То есть если раньше простои в работе вычислительной части чипов были достаточно частыми, то практически полностью исключает такую возможность Hyper-Threading. Что это за технология, рассмотрим ниже.
На аппаратном уровне
Повышенные требования выдвигаются к аппаратному обеспечению в случае использования Hyper-Threading. Материнская плата, BIOS и процессор должны поддерживать ее. По крайней мере, в рамках процессорного разъема PGA478 на подобную совместимость необходимо было обращать повышенное внимание. Не все наборы системной логики в этом случае были ориентированы на использование НТ, как и процессорные устройства. И даже если в номенклатуре системной платы присутствовала столь желанная аббревиатура, то это вовсе не означало, что чипы правильно инициировались по той причине, что необходимо было обновить BIOS.
Кардинально изменилась ситуация в этом случае начиная с LGA1156. Данная вычислительная платформа была изначально заточена под применение Hyper-Threading. Поэтому каких-либо существенных проблем с применением последней в данном случае у пользователей не возникало. Это же самое справедливо и для последующих процессорных разъемов, таких как LGA1155, LGA1151 и LGA1150.
Аналогичным отсутствием проблем с применением НТ могли похвастаться и высокопроизводительные сокеты LGA1366, LGA2011 и LGA2011-v3. В довершение к этому прямой конкурент «Интел» - компания AMD - в последнем поколении своих процессоров для АМ4 реализовала весьма схожую технологию логической многозадачности - SMT. Она использует практически идентичную концепцию. Отличие заключается лишь в названии.
Основные компоненты со стороны программного обеспечения
Нужно отметить, что даже в случае полноценной поддержки НТ со стороны аппаратных ресурсов не всегда она будет успешно работать на уровне программного обеспечения. Для начала операционная система должна уметь работать одновременно с несколькими вычислительными ядрами. В устаревших на сегодняшний день версиях системного софта MS-DOS или Windows 98 такой возможности нет. А вот в случае Windows 10 каких-либо проблем не возникает, и эта операционная система уже изначально заточена под такие аппаратные ресурсы персонального компьютера.
Теперь разберемся с тем, как включить Hyper-Threading в Windows.Для этого на компьютере должно быть установлено все необходимое управляющее прикладное программное обеспечение. Как правило, это специальная утилита с компакт-диска системной платы. В ней есть специальная вкладка, на которой можно в режиме реального времени изменить значения в БИОСе. Это, в свою очередь, приводит к тому, что уже в нем опция Hyper-Threading переходит в положение Enabled, а также активируются дополнительные логические потоки, причем даже без перезагрузки операционной системы.
Включение технологии
Многие начинающие пользователи достаточно часто на первоначальном этапе использования нового компьютера задаются одним важным вопросом относительно Hyper-Threading: как включитьее? Существует два возможных способа решения этой задачи. Один из них - это использование БИОСа. В этом случае необходимо выполнить такие действия:
- При включении ПК инициализируем процедуру входа в БИОС. Для этого достаточно при появлении тестового экрана зажать кнопку DEL (в некоторых случаях необходимо зажимать F2).
- После появления синего экрана переходим с применением навигационных клавиш на вкладку ADVANCED.
- Затем на ней находим пункт Hyper-Threading.
- Напротив него необходимо установить значение Enabled.
Ключевой недостаток данного способа - это необходимость перезагрузки персонального компьютера для выполнения данной операции. Реальной альтернативой ей является использование конфигурационной утилиты системной платы. Этот метод был детально описан в предыдущем разделе. И в этом случае заходить в БИОС совсем не обязательно.
Отключение НТ
По аналогии со способами включения НТ существует два способа дезактивации данной функции. Один из них можно выполнить лишь только в процессе инициализации компьютерной системы. Это, в свою очередь, не совсем удобно на практике. Поэтому специалисты останавливают свой выбор на втором методе, который основывается на использовании компьютерной утилиты материнской платы. В первом случае выполняются такие манипуляции:
- При загрузке электронно-вычислительной машины заходим в базовую систему ввода — вывода (второе ее название BIOS) по ранее изложенной методике.
- Перемещаемся с применением клавиш управления курсором в пункт меню Advanced.
- Далее необходимо найти пункт меню Hyper-Threading (в некоторых моделях системных плат он может обозначаться как НТ). Напротив него с помощью кнопок PG DN и PG UP устанавливаем значение Disabled.
- Сохраняем снесенные изменения с помощью F10.
- Выходим из БИОСа и перезагружаем персональный компьютер.
Во втором случае при использовании диагностической утилиты системной платы нет необходимости перезагружать ПК. Это ключевое его преимущество. Алгоритм в этом случае идентичный. Разница состоит в том, что здесь используется предустановленная специальная утилита от производителя системной платы.
Ранее были описаны два основные способа того, как отключить Hyper-Threading. Хоть и более сложным номинально считается второй из них, но он более практичный по той причине, что не требует перезагрузки компьютера.
Модели процессоров с поддержкой НТ
Изначально, как было уже отмечено ранее, поддержка Hyper-Threading была реализована лишь только в процессорных устройствах серии Pentium 4 и только в исполнении PGA478. А вот уже в рамках LGA1156 и более поздних вычислительных платформ рассматриваемая в рамках данного материала технология использовалась практически во всех возможных моделях чипов. С ее помощью процессоры Celeron превращались из одноядерного в двухпоточное решение. В свою очередь, Penrium и i3 с ее помощью могли уже обрабатывать 4 потока кода. Ну а флагманские решения серии i7 способны одновременно работать с 8 логическими процессорами.
Для наглядности приведем применение НТ в рамках актуальной вычислительной платформы от Intel - LGA1151:
- ЦПУ серии Celeron не поддерживают эту технологию и имеют всего 2 вычислительных блока.
- Чипы линейки Pentium оснащены 2 ядрами и четырьмя потоками. Как результат, НТ в этом случае поддерживается в полном объеме.
- Аналогичную компоновку имеют и более производительные процессорные устройства модельного ряда Core i3: 2 физических модуля могут работать в 4 потока.
- Как и наиболее бюджетные чипы Celeron, Core i5 не оснащены поддержкой НТ.
- Флагманские решения i7 тоже поддерживают HT. Только в этом случае вместо 2 реальны ядер есть уже 4 блока обработки кода. Они, в свою очередь, уже могут работать в 8 потоков.
Hyper-Threading - что этоза технология и каково ее основное назначение? Это логическая многозадачность, которая позволяет путем минимальных корректировок аппаратного обеспечения увеличить производительность компьютерной системы в целом.
В каких случаях эту технологию наиболее оптимально использовать?
В некоторых случаях, как было отмечено ранее, НТ увеличивает быстродействие, с которым обрабатывает программный код процессор. Hyper-Threading может эффективно работать только с распаленным софтом. Типичными его примерами являются кодировщики видео и аудиоконтента, профессиональные графические пакеты и архиваторы. Также наличие такой технологии позволяет существенно улучшить быстродействие серверной системы. А вот при однопоточной реализации программного кода нивелируется наличие Hyper-Threading, то есть получается обычный процессор, который решает на одном ядре одну задачу.
Преимущества и недостатки
Есть определенные недостатки у технологии Intel Hyper-Threading. Первый из них - это возросшая стоимость ЦПУ. Но большее быстродействие и улучшенная компоновка кремниевого кристалла в любом случае увеличат цену ЦПУ. Также возросшая площадь полупроводниковой основы процессорного устройства приводит к повышению уровня потребляемой мощности и температуры. Разница в этом случае несущественная, и она не превышает 5 %, но она все-таки есть. Больше каких-либо существенных недостатков в этом случае нет.
Теперь о преимуществах. На быстродействие и производительность фирменная технология НТ от компании «Интел» не оказывает, то есть ниже определенного порога у такого компьютера опуститься не получится. Если же программное обеспечение прекрасно поддерживает распараллеленные вычисления, то будет наблюдаться определённый прирост быстродействия и, конечно же, производительности.
Как показывают тесты, в некоторых случаях прирост может достигать 20 %. Наиболее оптимизированным софтом в этом случае являются различные перекодировщики мультимедийного контента, архиваторы и графические пакеты. А вот с играми все уж не так и хорошо. Они, в свою очередь, способны работать в 4 потока, и, как результат, флагманские чипы не способны в этом случае опередить процессорные решения среднего уровня.
Современная альтернатива от AMD
Технология Hyper-Threadingне единственная в своем роде на сегодняшний день. У нее есть реальная альтернатива. Компания AMD с выпуском платформы АМ4 предложила ей достойного конкурента в лице SMT. На аппаратном уровне это идентичные решения. Только вот флагман от «Интел» может обработать 8 потоков, а ведущий чип AMD - 16. Уже одно это обстоятельство указывает на то, что более перспективным является второе решение.
Поэтому компания «Интел» вынуждена в срочном порядке корректировать свои планы по выпуску продукции и предлагать совершенно новые процессорные решения, которые смогут составить достойную конкуренцию новичкам от AMD. Только вот на сегодняшний день они еще не переставлены. Поэтому если нужна доступная компьютерная платформа, то лучше выбирать LGA1151 от «Интел». Если необходим задел по производительности, то предпочтительней будет уже АМ4 от AMD.
