Есть ли смысл на десктопе?
Некогда многопроцессорность была популярна не только в серверах, но и в старших моделях рабочих станций, и даже в самосборных компьютерах. Особенно массовое применение данной технологии связано с тем, что компания Intel обеспечила поддержку SMP в системах на базе процессоров Pentium (до двух процессоров без специальных архитектурных ухищрений) и усилила ее в Pentium Pro (можно было использовать до четырех процессоров). Настольные Pentium II вернулись на более низкий уровень (до двух процессоров), зато и стоили они недорого (причем в паре могли работать даже совсем бюджетные Celeron после небольшой доработки), что быстро сделало соответствующие системные платы пусть и не массовым в полном смысле этого слова, но широко распространенным товаром. Затем в гонку включилась и компания AMD, предложив пользователям свои двухпроцессорные решения для рабочих станций. И тут история в очередной раз повторилась — потребный для SMP-конфигураций Athlon MP можно было не приобретать, а самостоятельно «изготовить» из массового Athlon XP, что быстро привлекло пристальное внимание многих пользователей к двухсокетным платам на базе чипсетов AMD 760MP и 760MPX.
Позднее производители пришли к выводу, что простота получения SMP-систем из недорогих комплектующих сильно бьет по их же доходам, так что начали постепенно разделять массовое (один сокет, один процессор) и высокопроизводительное направление, вплоть до того, что бывали иногда моменты, когда они оказывались совершенно несовместимыми. Впрочем, делалось это во многом для получения дополнительной прибыли, но совсем не для того, чтобы совсем «придушить» направление. Так что часть энтузиастов к двухсокетным системам охладела, но лишь та, которой интересны были «переделки ради переделок» — пользователи, имеющие реальную потребность в высокой производительности, продолжали активно приобретать рабочие станции с двумя процессорами. Пик пришелся на первые Xeon и Opteron. А дальше — как отрезало.
Виной тому явился выпуск двухъядерных, а затем и четрехъядерных настольных процессоров. По сути своей для большинства задач CMP и SMP не сильно-то отличаются, зато сохранялась возможность использования «нормальных» настольных комплектующих. Опять же — и цена получалась более низкой. Разумеется, на каждый момент времени два сокета могли обеспечить вдвое больше ядер, чем один, однако требовалось это далеко не многим. Пользователи быстро убедились, что два ядра это практически всегда лучше, чем одно — даже если использовать однопоточные приложения, система как минимум становится куда более «отзывчивой» на действия пользователя, поскольку второе ядро как раз и обеспечивает необходимый запас ресурсов. А вот пользу из наличия четырех ядер на десктопе долгое время можно было извлечь лишь при использовании весьма специфического ПО, да и сейчас-то ситуация не сильно изменилась. Но даже если четырех ядер вам мало, не обязательно бежать за системой с двумя сокетами — в ближайшее время и Intel, и AMD собираются начать выпуск настольных шестиядерных процессоров. Ну можно будет (или, в случае AMD, уже сейчас можно) таких пару поставить, ну и что? Что вы собрались делать с двенадцатью вычислительными ядрами? :) В общем, подводя итог, рост количества ядер был крайне важен при переходе от одного к более чем одному, но чем дальше, тем менее интересен. Соответственно, и SMP-конфигурации были крайне нужны тогда, когда других способов получить более одного ядра не было, но быстро растеряли свою привлекательность по мере совершенствования CMP. Из сегодняшних успешных SMP-систем на десктопе на ум приходит разве что Apple Mac Pro, да и то — пол-года назад компания наступила на горло собственной песне, выпустив модификацию всего с одним «односокетным» Xeon серии 3500.
Однако все знают о существовании приложений, существенно ускоряющихся при любом увеличении количества ядер — просто потому, что некоторые задачи прекрасно распараллеливаются (часть — вообще на уровне алгоритмов, для некоторых же положительный эффект достигается за счет одновременного запуска одинаковых и не зависящих друг от друга кусков кода). Правда процент таких задач среди обычного «десктопного» ПО весьма мал. Или, все же, не мал? Вопрос интересный и до конца все еще не исследованный. Поэтому мы решили им заняться. Благо наша текущая методика тестирования процессоров на данный момент существенным образом ориентируется на настольные приложения как раз. И в рамках этих самых настольных систем демонстрирует неплохой прирост производительности при увеличении количества потоков вычисления (как путем использования CMP, так и, пусть в меньшей степени, за счет SMT в процессорах Intel). А что будет, если мы попробуем задействовать все существующие на данный момент технологии увеличения производительности: и SMT (т.е. возможность выполнять на одном ядре более одного потока вычислений — именно этим занимается Hyper-Threading), и CMP («многопроцессорность» за счет увеличения количества ядер в одном приборе), и SMP (установку нескольких процессоров)? Давайте посмотрим.
Конфигурация тестовых стендов
| Процессор | Core i7 860 | Core i7 Extreme 975 | Xeon L5520 | Xeon X5570 |
| Название ядра | Lynnfield | Bloomfield | Bloomfield | Bloomfield |
| Технология пр-ва | 45 нм | 45 нм | 45 нм | 45 нм |
| Частота ядра (std/max), ГГц | 2,8/3,47 | 3,33/3,6 | 2,26/2,53 | 2,93/3,33 |
| Стартовый коэффициент умножения | 21 | 25 | 17 | 22 |
| Схема работы Turbo Boost | 5-4-1-1 | 2-1-1-1 | 2-1-1-1 | 3-3-2-2 |
| Кол-во ядер/потоков вычисления | 4/8 | 4/8 | 4/8 | 4/8 |
| Кэш L1, I/D, КБ | 32/32 | 32/32 | 32/32 | 32/32 |
| Кэш L2, КБ | 4 x 256 | 4 x 256 | 4 x 256 | 4 x 256 |
| Кэш L3, КБ | 8192 | 8192 | 8192 | 8192 |
| Частота UnCore | 2,4 | 2,66 | 2,13 | 2,66 |
| Оперативная память | 2 x DDR3-1333 | 3 x DDR3-1066 | 3 x DDR3-1066 | 3 x DDR3-1333 |
| QPI | 4,8 ГТ/с | 6,4 ГТ/с | 5,86 ГТ/с | 6,4 ГТ/с |
| Сокет | LGA1156 | LGA1366 | LGA1366 | LGA1366 |
| TDP | 95 Вт | 130 Вт | 60 Вт | 95 Вт |
| Цена | Н/Д(3) | Н/Д(2) | $293(6) | $596(7) |
Почему именно эти процессоры? Core i7 860 можно считать ныне разумным базовым уровнем — более дешевый процессор человек, реально заинтересованный в получении высокой производительности приобретать не станет, а более дорогие и на самом деле более дорогие (причем существенно). Core i7 Extreme 975 — на данный момент максимум для настольных систем. Да, достаточно дорого (хотя вполне сравнимо с ценой одного Xeon семейства 5500), зато быстрее пока никак не получить. Ну и два Xeon, протестированных как по одному, так и в паре — основные герои сегодняшнего тестирования. Почему именно эти модели? X5570 это старший из «неэкстремальных Зионов» — с TDP 95 Вт. Впрочем, два процессора дают нам уже 190 Вт (что как-то многовато для настольного компьютера), но при попытке применения более быстрых процессоров (которых пока ровно два — W5580 и W5590) для одних лишь процессоров уровень TDP составит астрономические 260 Вт! Собственно, именно поэтому для многих систем именно Х5570 продолжает оставаться максимально-допустимым. L5520 же не хватает звезд с неба по производительности, зато укладывается в 60 Вт, т.е. пара таких процессоров экономичнее одного Extreme 975, например. Замечу, что в конце лета компания анонсировала уже и немного более быструю модификацию с низким потреблением, а именно L5530, но он (равно как и W5590) еще даже не появился в «Spec Finder» на сайте Intel :) Да и не может увеличение тактовой частоты на 133 МГц привести к кардинальному приросту производительности, так что для наших нужд вполне подойдет и L5520.
| Системная плата | Оперативная память | |
| LGA1156 | Intel DP55WG (P55) | 4 x 2 ГБ (1333; 9-9-9-24) |
| LGA1366 | Intel DX58SO (X58) | 3 x 2 ГБ (1333; 9-9-9-24 для 975 ЕЕ/Х5570, 1066; 8-8-8-19 для L5520) |
| Dual LGA1366 | Intel S5500HCV (5500) | 6 x 1 ГБ (1333; 9-9-9-24 для Х5570, 1066; 8-8-8-19 для L5520) |
Мы приводим результаты Core i7 860 с 8 ГБ памяти — как мы уже установили, для некоторых приложений нашей методики установка 4 ГБ резко снижает производительность, а вот между 6 и 8 ГБ такой разницы нет. В системах с одним и двумя LGA1366 формально характеристики памяти вообще одинаковые, но набраны они по-разному: либо три модуля по 2 ГБ, либо шесть по 1 ГБ, поровну «розданные» процессорным сокетам. Возможно, что на практике такая конфигурация вызовет снижение производительности, однако «забивать» дуальную систему вдвое большим количеством ОЗУ, на наш взгляд, еще менее корректно.
Также необходимо сказать еще пару слов о настройке серверных платформ с точки зрения энергопотребления. Дело в том, что последняя имеет куда большие возможности, нежели принято для настольных компьютеров (например, иногда допустимо вообще жестко зафиксировать общий уровень энергопотребления на любой границе, после чего система будет невзирая ни на какие обстоятельства пытаться в него уложиться), что иногда способно доставить определенные проблемы. В частности, для задействования Turbo Boost недостаточно просто включить данную технологию в BIOS (благо включена изначально) и на этом успокоиться — приходится «подкручивать» и некоторые другие настройки. Упоминаем мы об этом на всякий случай, поскольку, очевидно, человек, собирающий систему на подобной платформе, должен разбираться в вопросе, однако... Имейте это ввиду, если вдруг производительность сервера или двухпроцессорной рабочей станции оказывается ниже положенной :)
Тестирование
Базовая методика тестирования производительности (список используемого ПО и условия тестирования) подробно описана в статье. Для текущего тестирования мы ее несколько модифицировали. Во-первых, волевым решением были исключены игровые тесты — нечего им тут делать. Тем более что слабые способности большинства игр по утилизации дополнительных ядер давно всем известны. В свое время компания Intel, конечно, имела полное право продвигать Skulltrail в качестве игровой платформы, но это ее личные проблемы — мы в таком надувательстве не участвуем :) Две-три видеокарты — да, полезно, более одного процессора — не для игр.
Во-вторых, пришлось избавиться и от еще двух приложений, что уже не радует. Используемый нами кодек XviD стабильно «рушился», увидев возможность поработать с 16-ю потоками вычисления, прямо при запуске. SPECjvm2008 в свою очередь работал (во всяком случае, в процессе тестирования все выглядело как обычно — без каких-либо ошибок), однако выдать результаты ему не удавалось. Это тем более печально, что оба теста (в особенности второй) очень положительно относились к увеличению как количества ядер, так и вообще потоков вычисления, так что их поведение на двухпроцессорной системе было крайне интересно. Но что есть — то есть.
Для удобства восприятия, результаты на диаграммах представлены в процентах (за 100% принят результат Intel Core i7 860 в каждом из тестов — поскольку баллы все равно «несовместимы» с теми, что получаются при тестировании односокетных систем, мы решили для наглядности провернуть такую замену базового уровня). Подробные результаты в абсолютных величинах доступны в виде таблицы в формате Microsoft Excel.
3D-визуализация
Давно установленный факт, что для этой группы достаточно «быстрого» двухъядерного процессора, а большее она задействовать просто не сможет, получил очередное подтверждение. При этом накладные расходы на межпроцессорное взаимодействие и разницу в материнских платах нельзя сбрасывать со счетов, так что вместо увеличения производительности имеем ее падение.
Рендеринг трёхмерных сцен
В Конференции как-то была высказана идея, что, при распределении задач в 3D-пакетах по двум компьютерам имеет смысл использовать более производительный для интерактивной работы (поскольку при этом задержки реально напрягают пользователя), а финальный просчет можно сбрасывать и на относительно медленный «числогрыз» (стоит себе в углу и считает, никому не мешая; когда досчитает — тогда и нормально). Однако пара диаграмм сразу показывает ее несостоятельность: для интерактивной работы слишком уж производительный компьютер просто не нужен (начиная с определенного разумного уровня, конечно), а вот рендеринг — такая задача, которой сколько ресурсов не дай, все равно лишними не будут. Особенно если речь идет не об индивидуальном работнике, а о фирме, в которой разработчиков несколько — можно сэкономить (в разумных пределах — опять же) на непосредственно рабочих компьютерах, зато закупить рендер-сервер, который и будет за всех все просчитывать. Вполне логичная связка получается, да и с финансовой точки зрения вполне оправданная. А вот если нужен ровно один компьютер ровно для одного пользователя, то, пожалуй, лучше ограничиться обычным настольным процессором, при наличии достаточного количества денежных средств — экстремальной модификацией последнего, но с двумя процессорами не связываться: пара Х5570 обгоняет одного 975 ЕЕ почти на 25%, но и стоимость у них внушает уважение. Причем востребована данная мощность будет только при рендеринге, но компьютер попросту будет «простаивать» при интерактивной работе. Куда интереснее тогда уж подождать пару-тройку месяцев до начала продаж Gulftown.
Кстати, ожидали мы от этой группы приложений большего. Изучение подробных результатов быстро показывает, кто все портит — Maya. Предъявлять слишком уж серьезные претензии к разработчикам, впрочем, не совсем верно. Программа отлично оптимизирована под восемь вычислительных потоков (это пара «старых» Xeon или Opteron). И даже 12 потоков ей под силу (два Xeon серии 7400 или два новых шестиядерных Opteron). Но вот появление в апреле этого года двухпроцессорных систем на базе Xeon 5500 оказалось для программы несколько неожиданным :) «Загрузить» работой 16 потоков вычисления она, увы — не в состоянии пока. Может быть, в будущем проблема будет исправлена. А пока Maya еще один идеальный потребитель будущих шестиядерных процессоров под LGA1366, но и только. Либо, опять же, выделенный рендер-сервер для нескольких человек: на нем может одновременно считаться более одной задачи, так что ядра простаивать не будут.
Научные и инженерные расчёты
Как и в первой группе — никаких приростов, только падения. Впрочем, результат неожиданным не назовешь: пары ядер достаточно, больше не требуется — это мы знали и по предыдущим тестам.
Растровая графика
Определенный прирост есть, причем немалый. Однако если посмотреть подробные результаты тестов, то видно, что в первую очередь он обусловлен почти двукратным улучшением результатов Paint.NET. В общем, это совсем не то приложение, ради которого кто-то будет приобретать более мощный компьютер :) Более важно то, что немного выиграл от двухпроцессорности и Adobe Photoshop. Но важно лишь с академической точки зрения — такой прирост не стоит таких вложений. А остальные программы группы вместо роста демонстрируют падение результатов.
Если отвлечься от конкретных приложений, то мощный рывок Paint.NET уже вряд ли вызовет смех — основной ее причиной, наверняка, являются особенности самой по себе .NET Framework. А теперь вспоминаем, что эта среда выполнения по логике чем-то схожа с виртуальной Java-машиной, причем не в классическом ее варианте (с интерпретацией байт-кода), а в современном (с использованием JIT-компиляции). И предназначена она не только для клиентских компьютеров, но и для серверов. Так что прекрасная масштабируемость Paint.NET на деле означает прекрасную масштабируемость .NET в принципе, а вот это уже вполне может оказаться востребованным в ряде условий.
Сжатие данных
Падения нет — есть даже немного неожиданный прирост. Или не совсем неожиданный? Вспоминаем, что при тестировании особенностей работы контроллера памяти в процессорах под LGA1366 на архиваторных тестах конфигурация 3 х 1 ГБ оказалась более быстрой, нежели 3 х 2 ГБ. Вот, собственно, и ответ на вопрос — почему производительность как минимум не падает и в этом случае.
Компиляция (VC++)
Четыре ядра хорошо, а восемь — лучше. Масштабируемость на 40% это случай не идеальный, но очень хороший.
Кодирование аудио
А вот вам и идеальный — 85% прироста. Как такого удалось достигнуть? А очень просто — вспоминаем методику тестирования. Сама по себе процедура аудикодирования распараллеливается относительно неплохо (если вспомнить Lame MT и GOGO-no-coda), однако в современных кодерах это используется редко. Однако мы используем для тестирования утилиту dBpoweramp, которая просто умеет запускать несколько процессов кодирования одновременно. Поэтому прирост производительности и должен быть близким к идеальному случаю.
Впрочем, с точки зрения абсолютных результатов кодирование аудио давно уже не показательно для частных пользователей, поскольку даже один Core i7 860 способен перегонять из формата в формат сотню-другую альбомов в час. Таким образом, уже с его помощью вполне можно преобразовывать аудиодиски в файлы со скоростью, превосходящей скорость их выхода в свет :)
Но есть и другая точка зрения. Помнится, на AllOfMP3.com была такая любопытная услуга, как онлайн-кодирование: на самом сервере музыка хранилась в формате без потерь, а каждый пользователь мог скачать песню в том формате и с тем битрейтом, какой ему был нужен. Этот музыкальный портал почил в бозе (совсем не по техническим причинам), однако сама идея, как нам кажется, как минимум имеет право на жизнь. Все-таки тупо держать музыку в одном формате с потерями (например, AAC 128 или 256 Кбит/с в iTunes Music Store или WMA 192 Кбит/с как в отечественной «Yote.Музыке») в XXI веке это значит обрекать себя на изначально проигрышную конкуренцию с пиратскими P2P-сетями — платные сервисы просто обязаны быть более удобными, чем нелегальные способы добычи контента, а онлайн-кодирование степень этого самого удобства повышает. Но мощности при этом должен быть соответствующими — при высокой популярности одновременно кодирование может заказать и тысяча-другая человек, которым совсем не понравится длительное ожидание начала закачки.
Кодирование видео
Ожидаемый прирост, но всего на треть. Не так уж мало, однако от задач кодирования хотелось бы получить больше. В чем проблема? В том, что XviD (который в предыдущих тестирования хорошо относился к увеличению количества потоков вычисления) пришлось убрать, зато древний как окаменевшие экскременты мамонта Canopus ProCoder, неспособный загрузить работой даже двухъядерный процессор, остался на месте и вовсю портит результаты. Что будет, если мы попробуем его временно убрать?
Ну вот — совсем другое дело: полуторакратный прирост на лицо. Видно, что в современных кодеках пара L5520 догоняет один Core i7 975 EE, несмотря на куда более низкую тактовую частоту, а Х5570 вне конкуренции (из протестированных процессоров).
Итого
Комментарии, как нам кажется, излишни — в свете выбранной методики тестирования («улучшенной» за счет отказа от игр, но «ухудшенной» из-за проблем с Java и XviD — примерный паритет, в общем) двухпроцессорные системы, конечно, обгоняют однопроцессорные при использовании одинаковых процессоров, но и только-то. Тех денег, что за них просят, они не стоят, а вместо сборки системы на двух младших или средних Xeon можно спокойно приобрести средний или старший Core i7: дешевле выйдет, возни меньше, потенциальных проблем — еще меньше, шума — тоже меньше, а производительность не хуже. И даже если приложений, способных эффективно задействовать более четырех ядер процессора, в вашем «арсенале» много, совсем не обязательно ориентироваться именно на двухпроцессорную рабочую станцию — шестиядерные настольные процессоры в ближайшее время будут выпущены обоими производителями (а предложение от Intel так и вовсе поддерживает 12 потоков вычислений на шести физических ядрах).
Но есть, конечно, сферы применения, где многопроцессорность все еще «на коне», да и, скорее всего, никогда с него не слезет :) Вот только лежат они где-то далеко от традиционных «изолированных» десктопов — на уровне серверов сетей. Долгое время для массового пользователя сервер был обычно «файлопомойкой» или способом совместного использования принтеров и факсов, однако клиент-серверная модель давно уже прочно вошла в нашу жизнь, принеся с собой рендер-серверы, серверы для видеокодирования и прочее, и прочее, и прочее... В конце-концов, как несложно заметить, наиболее полную утилизацию многопроцессорности проще всего получить при одновременном исполнении нескольких однотипных задач (каждая из которых может быть даже чисто последовательной), а это, например, терминальные серверы, позволяющие в ряде случаев вообще уйти от обычных десктопов в сторону «тонких» клиентов. Так что для разнообразных серверов приложений возможность установки двух (а то и четырех, шести или восьми) процессоров остается актуальной и будет такой всегда (во всяком случае, определенный тренд на дальнейшую дистрофию клиентов с соответствующим «ожирением» серверов наблюдается уже пару десятилетий как минимум). Однако на десктопе звезда SMP-систем, ярко вспыхнувшая в середине 90-х годов прошлого века, закатилась окончательно и бесповоротно.
