Представим как работает классическая SMP(Symmetric Multi-Processor)-система с точки зрения обычной логики. Нужно это хотя бы потому, что не так уж велико количество пользователей, хорошо себе представляющих как работает SMP-система, и в каких случаях от использования двух процессоров вместо одного можно ожидать реального увеличения быстродействия, а в каких — нет. Итак, представим, что у нас есть, к примеру, два процессора (остановимся на этом, самом простом примере) вместо одного. Что это нам дает?
В общем-то… ничего. Потому что в дополнение к этому нам нужна еще и операционная система, умеющая эти два процессора задействовать. Система эта должна быть по определению многозадачной (иначе никакого смысла в наличии двух CPU просто быть не может), но кроме этого, ее ядро должно уметь распараллеливать вычисления на несколько CPU. Классическим примером многозадачной ОС, которая этого делать не умеет, являются все ОС от Microsoft, называемые обычно для краткости «Windows 9x» — 95, 95OSR2, 98, 98SE, Me. Они просто-напросто не могут определить наличие более чем одного процессора в системе… ну и, собственно, дальше объяснять уже нечего :). Поддержкой SMP обладают ОС этого же производителя, построенные на ядре NT: Windows NT 4, Windows 2000, Windows XP. Также в силу своих корней, этой поддержкой обладают все ОС, основанные на идеологии Unix — всевозможные Free- Net- BSD, коммерческие Unix (такие как Solaris, HP-UX, AIX), и многочисленные разновидности Linux. Да, к слову — MS DOS многопроцессорность в общем случае тоже «не понимает» :).
Если же два процессора все же определились системой, то дальнейший механизм их задействования в общем-то (на «логическом», подчеркнем, уровне!) довольно-таки прост. Если в данный момент времени исполняется одно приложение — то все ресурсы одного процессора будут отданы ему, второй же будет просто простаивать. Если приложений стало два — второе будет отдано на исполнение второму CPU, так что по идее скорость выполнения первого уменьшиться не должна вообще никак. Это в примитиве. Однако на самом деле все сложнее. Для начала: исполняемое пользовательское приложение у нас может быть запущено всего одно, но количество процессов (т. е. фрагментов машинного кода, предназначенных для выполнения некой задачи) в многозадачной ОС всегда намного больше. Начнем с того, что сама ОС — это тоже приложение… ну и не будем углубляться — логика понятна. Поэтому на самом деле второй CPU способен немного «помочь» даже одиночной задаче, взяв на себя обслуживание процессов, порожденных операционной системой. Опять-таки, к слову об упрощениях — именно так, идеально, разделить CPU между пользовательским приложением и ОС, конечно, все равно не получится, но, по крайней мере, процессор, занятый исполнением «полезной» задачи, будет меньше отвлекаться.
Кроме того, даже одно приложение может порождать потоки (threads), которые при наличии нескольких CPU могут исполняться на них по отдельности. Так, например, поступают почти все программы рендеринга — они специально писались с учетом возможности работы на многопроцессорных системах. Поэтому в случае использования потоков выигрыш от SMP иногда довольно весом даже в «однозадачной» ситуации. По сути, поток отличается от процесса только двумя вещами — он во-первых никогда не порождается пользователем (процесс может запустить как система, так и человек, в последнем случае процесс = приложение; появление потока инициируется исключительно запущенным процессом), и во-вторых — поток умирает вместе с родительским процессом независимо от своего желания — к примеру, если родительский процесс «глюкнул и упал» — все порожденные им потоки ОС считает бесхозными и «прибивает» уже сама, автоматически.
Также не стоит забывать, что в классической SMP-системе оба процессора работают каждый со своим кэшем и набором регистров, но память у них общая. Поэтому если две задачи одновременно работают с ОЗУ, мешать они друг другу будут все равно, даже если CPU у каждой «свой собственный». Ну и наконец последнее: в реальности мы имеем дело не с одним, не с двумя, и даже не с тремя процессами. На приведенном коллаже (это действительно коллаж, потому что со скриншота Task Manager были удалены все пользовательские процессы, т. е. приложения, запускаемые «для работы») хорошо видно, что «голая» Windows XP, сама по себе, не запустив еще ни одного приложения, уже породила 12 процессов, причем многие из них к тому же еще и многопоточные, и общее количество потоков достигает двухсот восьми штук (!!!).
Поэтому рассчитывать на то, что нам удастся прийти к схеме «по собственному CPU на каждую задачу» совершенно не приходится, и переключаться между фрагментами кода процессоры будут все равно — и физические, и виртуальные, и будь они хоть виртуальные в квадрате и по 10 штук на каждое физическое ядро :). Впрочем, на самом деле все не так грустно — при грамотно написанном коде ничего в данный момент не делающий процесс (или поток) процессорного времени практически не занимает .
5,1. Многопроцессорные системы. Opteron.
Очень интересная для нас ситуация сложилась с многопроцессорными системами на Opteron. С одной стороны, по распределению памяти — ну совершенно типичная NUMA архитектура (с неравномерным доступом к памяти), даже спорить не о чем. Ибо время доступа к памяти будет зависеть от того, локальная это память, или нет — а если не локальная, то какого именно процессора. С другой стороны, AMD буквально настаивает, что с точки зрения программной модели это SMP — и ничего более. Даже название придумала — SUMO. Как же разобраться в этом хитросплетении терминов?
Для начала давайте подумаем, чем же для программиста отличаются эти две программные модели? В общем случае, для того, чтобы программа исполнялась эффективно, необходимо следить за ее распределением в памяти в случае NUMA архитектуры, и нет такой необходимости в случае SMP архитектуры. Происходит это потому, что времена доступа к памяти различных иерархий в архитектуре NUMA обычно отличаются на порядки — и, соответственно, неправильное размещение программы в памяти приводит к падению производительности в десятки раз. Если же время доступа к памяти для разных процессоров одинаково, или отличается несущественно — то, с точки зрения программирования, мы имеем программную модель SMP. Она гораздо проще и практически весь софт для многопроцессорных архитектур х86 разработан именно для такой программной модели. Вот таким упрощенным образом можно вкратце описать различия между этими программными моделями. Естественно, различия на этом не заканчиваются.
Теперь, когда мы сформулировали критерий, надо каким-то образом добыть данные о временах доступа в многопроцессорных Opteron системах…. Нарисуем, что такое hop, чтобы не путаться с терминами:
Видно, что обращение к памяти называется hop-ом. При этом обращение к своей локальной памяти — 0-hop. Обращение к памяти соседнего процессора, до которого надо путешествовать по шине Hyper Transport один раз — 1-hop. То же самое, но к процессору, до которого два путешествия по Hyper Transport — называется 2-hop.
А теперь посмотрим еще и на эти цифры (тестовая система — Opteron 2 GHz, 128 bit memory DDR333, CL 2.5, Hyper Transport 6.4 GB/sec).
Теперь видно, что в случае, когда процессоров 4, все времена доступа подтягиваются к среднему времени около 93 нс для двухпроцессорной системы и около 118 нс для 4-х процессорной. Последняя цифра, кстати, соответствует времени доступа хорошего однопроцессорного чипсета. Но здесь у нас общее время складывается из собственно времени доступа в память и времени передачи его по шине Hyper Transport (один или два раза)! Так что подобный результат можно признать вполне удовлетворительным.
Теперь вернемся к нашему предыдущему вопросу — так NUMA это, или SMP? Говоря формально, все-таки NUMA — 40% разницы не дают возможности назвать эту модель памяти SMP. А можно ли пользоваться моделью для SMP? Можно. Данная разница, хоть и заметна, под нагрузкой будет сглажена — у нас нет «твердых» цифр, но судя по некоторым данным, при нагрузке к этим временам надо добавить порядка 40 нс… Тогда эта разница превращается в 140 нс против 180 нс — а это уже другое соотношение. Таким образом, можно считать, что название SMP для данной системы вполне можно употреблять — и, соответственно, вполне можно программировать как для «классического SMP», без оглядки на действительную архитектуру системы (NUMA). Впрочем, мы не исключаем, что в дальнейшем ОС будут отслеживать распределение памяти в подобных системах — благодаря этому можно будет рассчитывать еще процентов на 10% прироста быстродействия. Почти наверняка найдется некоторое количество пользователей, которые привыкли выжимать всю производительность из систем. Опять — же, напомним, что сама AMD для наименования этой «переходной» архитектуры использует термин SUMO.
Теперь напомним вкратце, каково устройство многопроцессорных систем на архитектуре Hammer.
Система на 2 процессорах:
Система на 4-х процессорах:
Кстати, если сделать не 4 канала ввода/вывода, а 2 — то две высвободившиеся связи Hyper Transport можно соединить друг с другом, вот так:
Тогда средневзвешенная скорость памяти составит 19,2 GB/sec вместо 12,8 GB/sec в классическом варианте, а средний «диаметр» системы (средняя длина пересылок данных в hop-ах) составит 1.17 hops, а не 1.33. В свою очередь, это приведет еще и к снижению задержек. Автору подобный вариант даже больше нравится, нежели классический симметричный — редко когда в действительности для ввода/вывода необходимо больше, чем 2 канала Hyper Transport суммарной производительностью более 12 гигабайт в секунду. А поэтому такой вариант будет даже более интересен.
Кроме всего прочего, архитектура Hammer позволяет строить и 8-ми процессорные системы. При этом у крайних 4-х процессоров по одной шине Hyper Transport отдано для ввода/вывода, а у центральных — все три задействованы в качестве межпроцессорных связей. Правда, надо отметить, что, по-видимому, задержки в такой системе сильно увеличатся — впрочем, поскольку точные данные у автора отсутствуют, все сказанное суть только наше предположение. «Классический» вариант такой системы выглядит так:
Теперь применим такую же идею — пару связей Hyper Transport, задействованных для ввода/вывода, соединим друг с другом. Задействуем диагональные крайние процессоры. Получаем средневзвешенную скорость памяти 32 GB/sec вместо 25,6 GB/sec в классическом варианте, а средний «диаметр» системы 1.64 hops, а не 1.71. Приятная прибавка, не правда ли?
Правда, есть некоторые сведения, что все три шины Hyper Transport не могут быть когерентными — только две. Если так, то в 4-х процессорной архитектуре несимметричный вариант невозможен, а в 8-ми процессорной не будет связей между центральными процессорами, что резко увеличит среднее число hop-ов между процессорами, и, как следствие, сильно увеличит латентность. Автор надеется, что этот пессимистический слух не оправдается — к тому же в других источниках прямо указано, что один из контроллеров может переключаться между режимами coherent и non-coherent Hyper Transport.
Нельзя не заметить, что 4-х и 8-ми процессорным архитектурам отчаянно не хватает пропускной способности именно межпроцессорных связей — и с ускорением шины Hyper Transport производительность многопроцессорных систем сделает новый рывок. Но это дело уже будущих модификаций Hammer — мы не испытываем ни малейшего сомнения, что данная архитектура еще неоднократно будет модифицироваться и улучшаться. Как очевидный вариант, к тому же косвенно подтвержденный AMD — следующая модификация ядра Hammer будет поддерживать память DDRII (это, кстати, по оценкам автора, должно дать довольно значительный прирост производительности). Так что есть твердая уверенность в том, что данная статья об ожидаемых процессорах AMD — не последняя :-). Теперь, когда многопроцессорная архитектура AMD озвучена, дело за рынком — дальше именно он решит успешность/неуспех архитектуры.
Интересно, а можно ли сделать больше, нежели 8 процессоров? Оказывается, можно! Правда, теперь не удастся обойтись средствами только процессоров, необходимы еще и коммутаторы Hyper Transport. При их помощи систему можно сделать поистине гигантской…. Впрочем, судите сами:
Подобные Hyper Transport switch уже существуют и доступны (на четыре шины). Объявлены также коммутаторы на 8 шин. Осталось понять, что это за Interconnect Fabric…. Но стоп — пора бы и остановиться :-). Тем более, что здесь самое время вспомнить, что не кто иная, как компания Cray объявила сравнительно недавно о том, что она будет строить суперкомпьютер производительностью порядка 36 TFlops на процессорах Opteron (с возможностью увеличения производительности до 54 TFlops позднее). Интересно, будет ли архитектура суперкомпьютера похожа на эту картинку? :-) Довольно долгое время мы сможем об этом только догадываться. Но возможности архитектуры действительно впечатляют. Кроме того, ходят слухи, которые автор не берется ни подтвердить, ни опровергнуть. Но слухи интересные: говорят, что для фирмы Cray AMD будет производить специальную версию Opteron — с 4-мя линками Hyper Transport. Процессоры вроде бы будут составлять трехмерную сеть. Собственно, принципиальных сложностей для добавления 4-го линка вроде бы нет — но тогда непонятно, в каком же форм-факторе будут производиться эти процессоры. Фото 4-х процессорной материнской платы с Opteron-ами.
