Масштабируемость процессора 2s что это

Рейтинг и сравнение серверных процессоров Intel Xeon

Процессоры Intel Xeon неразрывно ассоциируются у большинства с мощными многоядерными монстрами. Они поддерживают на плаву деятельность дата-центров, ЦОД, NAS, коммерческих рендер-станций и прочих объектов, где требуются высочайшая производительность на ядро, огромный размер кэш-памяти, стабильность и длительный рабочий ресурс. Как минимум до того момента, пока владелец оборудования не решит перейти на обновленное железо.

Но какой процессор подойдет для вашей деятельности? Как отличить стандартный многоядерный чип от масштабируемого. Почему они так маркируются, и как понять поколение чипа, включая техпроцесс, технологии, поддержку определенных комплектующих и разъемов. Давайте во всем этом разбираться, потому что вводных чрезвычайно много.

Достоинства серверных решений от Intel

Однажды кто-то решил, что правильное название чипов — Зион, а не Ксеон, Ксенон и далее по списку. От обычных процессоров эти решения отличаются по следующим пунктам:

Многие полагают, что между Intel Core и Xeon нет никакой разницы, и переплата, по сути, бесполезна. Другие же напирают на то, что Core i7 c индексом «K» еще и разогнать можно, потому что это сильно повысит максимальную частоту и, следовательно, производительность.

Вот только в бизнесе это совершенно бесполезный функционал по нескольким причинам:

По факту, внушительная переплата за Xeon обусловлена их надежностью и безотказной работой на протяжении месяцев, а то и лет. Если ваш бизнес напрямую зависит от стабильной работы оборудования в серверной — экономия в этом случае не только вредна, но и опасна.

Как ориентироваться в линейках серверных процессоров Intel Xeon

Итак, как же разобраться в изобилии интеловских решений для серверов? Как выяснить, какой Xeon нужен именно вам? Давайте ответим на эти вопросы.

У производителя есть 2 линейки серверных CPU:

Маркировка чипов Intel Xeon Scalable

Для второго поколения масштабируемых процессоров Scalable в пределах каждой серии характерны следующие черты:

Номер каждой модели состоит из четырех цифр. О том, к какой серии принадлежит модель процессора говорит первая цифра номера:

Стоящая на втором месте цифра говорит о поколении чипа. В случае с семейством Scalable это поколения с кодовыми именами:

Помимо этого, номер модели может дополняться латинскими буквами, которые описывают индивидуальные особенности процессора.

Теперь, увидев номер модели 6262V, мы будем знать, что это модель серии Gold, с поколением чипа Cascade Lake, который хорошо покажется себя при развертывании виртуализации высокой плотности, а 5218R предназначена к установке на платформе с числом сокетов не больше двух.

Надеемся, вам стало гораздо проще ориентироваться при подборе конфигурации.

Маркировка Xeon E/W/D

Если описать эти процессоры вкратце, имеем следующее:

Xeon E — сервера начального уровня для малого бизнеса. Поддержка технологии Intel SXG для увеличения конфиденциальности данных в рабочих задачах. До 8 физических ядер, встроенная графика, Intel Smart Cache, низкий теплопакет до 95 Вт.

Xeon W — творчество, дизайн, VFX, 3D-рендер, CAD-программы, работа с ИИ. Обеспечивают ускорение моделирования, рендера и прочих операций за счет поддержки AVX-512, до 38 физических ядер, высокой базовой и Turbo-частоты и 2 ТБ ОЗУ. Чипы предоставляют до 64 линий PCI-E, технологию глубинного машинного обучения DL Boost, доступ к скоростной памяти Intel Optane и Wi-Fi 6.

Xeon D — высокая производительность в стесненных условиях при низком энергопотреблении. Сфера деятельности однокристальных систем — сетевые вычисления, облака высокой плотности, безопасность. Наличие многохостовых Ethernet-контроллеров, интеллектуальное управление трафиком, развертывание IoT (интернет вещей), управление неструктурированными данными, повышение плотности оборудования в ЦОД.

Как видите, у Интел все четко структурировано по сферам деятельности, поэтому каждый потенциальный партнер может подобрать платформу с CPU с оптимальным количеством ядер/потоков. Вопрос лишь к типу задач и свободному пространству в серверной.

Топ-10 серверных процессоры Intel Xeon

Довольно сложно составить объективный рейтинг серверных чипов. Во-первых, у них очень высокая сегментация и дифференциация под потребителя, тип выполняемых задач и прочие сферы деятельности. Во-вторых, один процессор может быть полностью провальным в классических вычислениях с плавающей точкой, но покажет себя идеально для настройки облака и интернета вещей. Вы и сами видели, насколько неоднородны устройства серии Xeon.

Но если использовать шаблон «Топ за свои деньги», то наибольшей любовью среди клиентов пользуются такие модели, начиная с серии Intel Xeon E:

10. E-2126G

Модель предоставляет конфигурацию 6/6 с частотой до 4.5 ГГц и умный кэш до 12 МБ, а также поддержку до 128 ГБ ОЗУ DDR4 за счет архитектуры Coffee Lake. Еще и графика предусмотрена для вывода изображения.

Для небольших офисов это практически идеальный вариант. Еще бы Hyper-Threading ему и вообще шикарно.

9. E5-2660

А это пусть и старенький, но мощный чип, в составе которого 8 ядер и 16 потоков с частотой до 3 ГГц. Хороший выбор для масштабируемых систем типа 2S.

До 384 ГБ ОЗУ DDR3 1600 на сокет, 40 линий PCI-E 3.0, невысокий TDP.

8. E5-2680 v4

Даже сегодня эта модель лидирует в бюджетном сегменте, предоставляя 14 физических ядер и 28 потоков с частотой до 3.3 ГГц. А заодно и 35 МБ умного кэша и конфигурацию до 2S.

Фишка модели — до 1.5 ТБ ОЗУ DDR4-2400 МГц и Intel vPro для поиска ошибок в системе.

Далее эстафета рейтинга передается представителям семейства Intel Xeon Scalable:

7. Silver 4214

Одно из самых доступных решений Intel Scalable 2-го поколения с конфигурацией 12/24, кэшем 16.5 МБ и парой UPI-каналов. Конфигурация — до 2S.

Работает с DDR4-2400 до 1 ТБ на сокет и предлагает до 48 линий PCI-E 3.0.

6. Silver 4216

Нужно больше сырой мощности? Пожалуйста. Здесь 16 ядер/32 потока, 22 МБ и кэша L3. Остальные характеристики как у Xeon 4214.

5. Gold 5220

Много ядер — всегда интересно. Тут их сразу 18 и еще 36 потоков. Учтите, что модель собирается в трансформер из 4 чипов в систему 4S, что позволяет водрузить до 4 ТБ ОЗУ DDR4-2667.

В Gold уже есть DL Boost, RDT, vPro, VT-x и TSX-NI. Пусть тут и ни рекордный кэш, но очень низкий теплопакет в 85 Вт, потому заморачиваться с охлаждением не придется.

4. Gold 6240

Лучший выбор в средней ценовой категории с прекрасной частотой до 3.9 ГГц (18/36). Поддержка AVX512 и vPro в наличии.

3. Gold 6240R

Еще больше ядер (24/48) и выше частота в 4 ГГц, но здесь 2 UPI-линии вместо 3, как у 6240. Зато кэш 35.75 МБ. Если не планируете использовать более 2 чипов в системе — проблем не будет.

2. Gold 6258R

Действительно огромная производительность за счет конфигурации 28/56 с частотой до 4 ГГц. Кэш — 38.5 МБ и все прелести «Золота» топ-сегмента. Ограничение — 2S, т.е. не более 2 сокетов в системе.

И завершает рейтинг топ-лидер.

1. Platinum 8280

По характеристикам — близнец 6258R, однако Platinum — это до 8 сокетов, 3 линии UPI и стоимость в 4 раза ниже конкурента из серии Gold.

Тренды для серверных процессоров Intel на 2021-2022 год и чего ждать в будущем

В третьем поколении Intel утратила привилегии на фоне AMD EPYC, которые лучше по всем фронтам. Но это не говорит, что «синие» совсем уж опустили руки.

Очень интересно выглядят грядущие Sapphire Rapids, которые преподнесут PCI-E 5.0 и поддержку 8-канального контроллера памяти DDR5. И самое главное — 10 нм, что сулит сильное снижение тепловыделения.

Также в числе грядущих достижений компании Интел значится память HBM и шина Compute Express Link 1.1, которая сильно сократит задержки обращения между CPU, графикой и памятью.

И если верить заявлению самих производителей, все это богатство ждет нас уже в 2022 году.

Ждем, надеемся и верим. Конкуренция — идеальный двигатель бизнеса. Но если все еще затрудняетесь с выбором системы — всегда можно обратиться к специалистам компании HPE.Марвел. Мы всегда подскажем правильное решение, полностью соответствующее вашим требованиям. Отправьте запрос на консультацию, и мы ответим на все ваши вопросы.

Рейтинг и сравнение серверных процессоров Intel Xeon

Источник

Что такое Intel Xeon Scalable?

Обновление модельного ряда процессоров Intel Xeon в этом году стало самым значительным событием на рынке серверных платформ Intel начиная с 2011 года – тогда были выпущены так привычные нам линейки Е3, Е5, Е7. И вот снова четырехзначные индексы, вдобавок серии Platinum, Gold, Silver и Bronze, а также обобщающий бренд Xeon Scalable. С первой попытки оказалось трудно понять логику происходящего, и в заинтересованных кругах подвис вопрос: зачем это вообще понадобилось? Об идеологической подоплеке создания семейства Xeon Scalable и самых интересных новшествах в нем мы расскажем в этом посте.

Быстрее, совместимее, гибче

Итак, для начала идеологический аспект. В последние годы жизнь в семействе Intel Xeon шла по накатанному. Постепенно щелкали счетчики поколений, происходило это несинхронно и беспорядочно. Каждая линейка Е3, Е5, Е7 жила своей жизнью, в своем сокете, несовместимая с соседями. Сервера проектировались под конкретную линейку и только под нее.

Шло время, Е7 менялись медленно, Е3 побыстрее, но все равно значительно, на несколько лет, опаздывали по техпроцессу от Intel Core. А нереализованный потенциал – это упущенная выгода. Проанализировав ситуацию, в Intel выделили ключевые проблемы, которые должен решить выход принципиально новых Xeon:

Какие области более всего нуждаются в комплексах с подобными характеристиками? Самые динамично развивающиеся, такие как облачные хранилища и сервисы, программно определяемые системы и так далее. Ну а что делать, если требуются сервера под традиционные нагрузки, скажем, для телекома (к слову сказать, показывающего в последнее время отрицательную динамику роста серверных мощностей)? Тогда Xeon Scalable можно считать следующим поколением Intel Xeon, партнеры Intel без проблем предоставят вам консультацию о соответствии старых и новых линеек.

Новые возможности

Теперь о функциональных новшествах Xeon Scalable – они также служат цели превращения платформы в идеально масштабируемую ноду.

Scalable и не только

Означает ли нынешняя реформа то, что все Intel Xeon станут теперь Scalable? Отнюдь. В целом линейка будет выглядеть следующим образом:

Сервера с Intel Scalable уже доступны для заказа. Вот, например, HP DL360 Gen10. Обратите внимание, если предыдущее поколение DL360 строилось только на процессорах Intel Xeon E5 (как и положено двухсокетному серверу), то теперь в вашем распоряжении весь набор линеек от 3000 до 8000 (от Bronze до Platinum). Вот такая скалабильность получается.

Источник

Поиск и решение проблем масштабируемости на примере многоядерных процессоров Intel Core 2 (часть 1)

Что есть масштабируемость?

Прежде чем начать изучение проблем масштабируемости программного обеспечения в среде параллельных вычислений, нам необходимо определиться со значением самого термина. Идеальная масштабируемость означает, что полное время выполнения задачи будет линейно уменьшаться с увеличением количества ядер, используемых приложением. Однако в соответствии с законом Амдаля для параллельного исполнения алгоритма, полное время выполнения программы может быть сокращено только на отрезке оптимизированного соответствующим образом кода. Таким образом, первый пункт в нашем поиске заключается в определении достигнутой степени параллелизма алгоритмов.

События производительности процессора на основе микроархитектуры Intel Core2 предоставляют нам удобные метрики для этих целей. Каждое ядро имеет Блок Мониторинга Производительности (Performance Monitoring Unit или PMU), а событие CPU_CLK_UNHALTED.CORE позволяет определить число рабочих циклов на каждом ядре. Если для сбора информации используется VTune™ Performance Analyzer, то это число суммируется для всех ядер, исполнявших интересующий нас процесс. То есть это число есть количество эффективных циклов потраченных на исполнение приложения. Назовем это число «effective_cycles».

Полезной особенностью PMU является возможность сравнивать на каждом цикле значение события с некоторым заданным числом (cmask) и определять, является ли оно большим или равным (inv=0) или же оно меньше этого числа (inv=1). Если такое условие задано, PMU будет считать циклы только в случае его соблюдения. Однако, это возможно только для счетчиков общего назначения. Фиксированные счетчики, например, для событий CPU_CLK_UNHALTED.CORE, INST_RETIRED.ANY и CPU_CLK_UNHALTED.REF, не могут подвергаться этой операции. Если значение события CPU_CLK_UNHALTED.CORE_P (обобщенная версия счетчика рабочих циклов) сравнивать с числом 2 с условием «менее чем» (inv=1), то счетчик будет считать все циклы. Если это число просуммировать для всех процессов и поделить на количество ядер в системе, мы получим полное время исполнения процесса. Назовем это число «total_cycles».

Для обеспечения корректности полученных значений необходимо, что бы функция Speed Stepping была отключена в BIOS и ОС, иначе незагруженные ядра могут работать на пониженной частоте, что исказит полученное значение полного времени. Отношение effective_cycles/total_cycles будет равняться числу использовавшихся ядер для отлично масштабируемого кода, и равняться 1 для абсолютно последовательного кода. Причем результат не зависит от того, какая часть из всех ядер системы была задействована во время исполнения. Однако ценность этой техники может быть нивелирована, если в коде встречаются пожирающие процессорное время циклы активного ожидания, так что циклы ожидания должны быть реализованы корректно. Для более детального анализа рекомендуется использовать Intel Thread Profiler.

Отклонения от идеальной масштабируемости могут быть обусловлены особенностями структуры кода и синхронизационной логики, но также они могут быть вызваны высокой конкуренцией за общие ресурсы системы. Целью данной статьи как раз и является системный поиск подобных проблем и их решение.

Ограниченность ресурсов

Последний компонент списка имеет несколько иное влияние на производительность, чем все остальные, так как синхронизация потоков (threads) и процессов зависит от блокируемого доступа к линиям КЭШа. Различие это наиболее очевидно с той точки зрения, что более быстрый / более объемный кэш не всегда способен обойти влияние падения масштабируемости, как в случае с другими элементами этого списка.

Для этих ограничений есть два основных сценария масштабирования приложения, которые будут рассмотрены ниже, разбиение фиксированного объема работы между ядрами и линейное увеличение количества работы, выполняемой всеми ядрами. Эти два сценария имеют несколько разный смысл, если говорить о проблемах масштабируемости, и, следовательно, различаются по искомым признакам.

Пропускная способность

Чтобы понять какой вклад в падение производительности вносит трафик по шине, необходимо определить, какой, собственно, трафик проходит по шине во время выполнения программы (суммарный и по отдельным компонентам) и какова пиковая пропускная способность платформы используемой при анализе. Пиковая пропускная способность платформы зависит от большого числа сторонних факторов. Это и конфигурация аппаратных блоков предвыборки данных (hardware prefetchers), и количество, тип и расположение в слотах планок оперативной памяти, и частота системной шины, частота процессора, и условия, позволяющие достигнуть когерентности КЭШей. Поэтому ни одна метрика не может считаться определяющей пропускную способность платформы на основе Intel Core 2. Единственный приемлемый метод определить ее – провести синтетический тест пропускной способности. Одиночный длительный цикл алгоритма TRIAD похоже наилучшим образом подходит для этих целей. Так как предел пропускной способности для многоядерного расчета скорее всего будет отличен от одноядерного, вышеозначенный тест должен поддерживать параллельный счет либо за счет потоков, либо за счет разбиения на отдельные процессы.

Предел пропускной способности системы влияет на производительность несколько иначе, чем большинство замедляющих факторов. Влияние большинства растет линейно с ростом их определяющей метрики, как в случае кэш-промахов на последнем уровне КЭШа, где влияние на производительность определяется как соответствующее количество событий ожидания. В этом же случае производительность падает, как бы натыкаясь на барьер, который не заметен до тех пор, пока приложение не исчерпает все ресурсы платформы. То есть зависимость производительности от использования пропускной способности системы скорее ступенчатая, чем линейная, как в случае с другими событиями. Так, например, время доступа к памяти нелинейно возрастает, так как достигнут предел пропускной способности. Пронаблюдать за этим эффектом можно замеряя задержку доступа к шине при увеличении количество одновременно рассчитываемых триад. Задержка доступа к шине может быть измерена событиями производительности в счетном режиме (в противоположность сэмплированию) как отношение:

В большинстве случаев компонент ifetch (instruction fetch, выборка инструкции) маловажен, особенно в ситуации с пиковой пропускной способностью, а, следовательно, может быть проигнорирован.

Существует множество источников, вносящих свой вклад в трафик по системной шине. События производительности процессоров Intel Core 2 позволяют использовать множество методик для определения как полной, так и индивидуальной загрузки шины этими компонентами. Насыщенность системной шины определить очень просто. Она может быть представлена как часть циклов шины использовавшихся для передачи данных:

Или напрямую, как количество байт переданных по шине в составе кэш-линий:

Удобной метрикой в этом случае является просто количество кэш-линий на цикл, так как аппетит N параллельных версий данного приложения / потока составит N раз от этого значения. Так что если предел платформы определен в этих значениях, наиболее вероятная загруженность шины при параллельном счете может быть легко определена во время анализа единичного потока.
События BUS_TRANS_* можно использовать иерархически, чтобы вычленить компоненты, использующие шину. Их краткое описание представлено в нижеследующей таблице, а также они очень подробно разобраны в онлайн справке VTune Performance Analyzer.

Существует множество стандартных способов сократить трафик по шине, которые могут быть применены в случае достижения предела платформы. Сюда можно отнести следующие методы:

Вышесказанное ни в коем случае не претендует на роль исчерпывающего списка возможных вариантов, это скорее список самых очевидных. Любой, кто на самом деле пытался, скажет, что последнее вообще проще сказать, чем сделать.

Извиняюсь за многобукав и некоторую сумбурность, но материал действительно несколько суховат. Перевод делал еще в прошлом году, так что извиняюсь за некоторую потерю актуальности.

Источник

Масштабируемость: что это такое?

Как-то передо мной встал вопрос, что такое масштабируемость и как это связано с зависимостью/независимостью от центрального процессора? В результате получилась небольшая статья, которую и предлагаю Вашему вниманию.

Как процессорная зависимость связана с масштабируемостью, т.е. возможностью роста производительности карточки с ростом производительности процессора? В большинстве случаев имеется некоторый отрезок процессорной мощности, при котором карточка демонстрирует почти линейный рост производительности. Связано это с тем, что процессор не успевает готовить данные для графического ускорителя, и любые данные обрабатываются до поступления следующей порции. При этом, очевидно, что чем больший участок тракта вычислений берет на себя графический акселератор, тем меньше нагрузка на процессор, а значит, CPU быстрее готовит данные, и, в результате, сужается участок линейного масштабирования. Отсюда следует, что чем менее процессорно-зависима карточка-ускоритель, тем она обычно менее масштабируема.

Начиная с какого-то момента, графический акселератор начинает все больше и больше тормозить процессор, и при неограниченном росте производительности последнего скорость рендеринга становится постоянной, стремясь к пиковой производительности ускорителя.

Конечно, эта модель несколько упрощенная. В реальных системах процессору всегда найдется, чем заняться, к тому же пропускные способности шин, передающих данные, на сегодня весьма ограничены. Что, кстати, является еще одним узким местом на пути достижения максимальной производительности.

В качестве оценки предельной производительности карточки можно использовать известные характеристики количества треугольников, которые она может обработать в секунду, и скорость закраски (fill-rate), т.е. количество текстурированных и отфильтрованных пикселов, выводимых в одну секунду. Возьмем для примера две карточки: 3Dfx Voodoo и nVidia Riva TNT.

Как видим, теоретические данные очень неплохо согласуются с практическими (эти параметры приблизительно соответствуют Quake 2).

Что следует из этих цифр? Очень простой вывод. Начиная с какого-то уровня, производительность 3D-ускорителя уже не играет роли (глазу все равно, 160 или 60 fps он видит). Все теперь упирается в процессорную зависимость, т.е. в то, какой процессор нужен, чтобы достичь подобных пиковых значений. Вот почему я с большим скепсисом читаю характеристики вновь появляющихся 3D-ускорителей. Также легко видеть, что приведенные ускорители (как и подавляющее большинство остальных) ограничены именно скоростью закраски, тогда как для процессора основная нагрузка исходит от процесса геометрических преобразований, т.е., усилия разработчиков сосредоточены несколько не в том месте, где надо бы.

Источник

Влияние различных характеристик на быстродействие процессоров современных архитектур

Мы продолжаем серию материалов, посвящённых исследованию производительности современных процессоров в реальных задачах и влиянию различных их характеристик на производительность. В этой статье мы затронем тему, которую ранее не исследовали: влияние на производительность частоты работы ядра. Теоретически данный вопрос в достаточной степени проработан: в любой конкретной архитектуре при росте частоты работы ядра, производительность процессора должна сначала практически линейно расти, потом, на определённом этапе, темпы роста должны замедляться, и, наконец, начиная с некой частоты, дальнейшее её наращивание становится уже бессмысленным т.к. перестаёт приводить к росту производительности процессора. Причина этих явлений также давно обозначена: производительность «упирается» в подсистему памяти, которая просто не успевает доставлять данные и код с такой скоростью, с которой их обрабатывает ядро CPU.

Нас же, как практиков, заинтересует простой вопрос: где именно наступают эти «переломные частотные моменты» в случае с конкретными процессорными архитектурами? Сегодня мы исследуем данный вопрос применительно к процессору Intel Core i7.

Конфигурация тестовых стендов

Множитель внеядра* (да простят нас читатели за этот новояз, но попробуйте сами перевести одним словом англоязычный термин «uncore») у всех процессоров серии Core i7 одинаков — x16 (частота работы внеядра, соответственно — 2,13 ГГц). Технология Hyper-Threading была включена, а вот Turbo Boost пришлось выключить т.к. в данном исследовании нам был нужен процессор, работающий на строго определённых частотах.

* — Часть процессоров Core i7, находящаяся «снаружи ядра», и работающая на своей, отличной от ядра частоте. Две наиболее значимые части внеядра — контроллер памяти и контроллер процессорной шины.

На первом графике приведена кривая роста производительности, построенная на основании баллов производительности каждого «процессора», вычисленных, согласно нашей методике тестирования (красная линия). Синяя же линия олицетворяет собой «идеально масштабируемую» производительность, которая вычисляется, исходя из предыдущего результата и предположения о том, что следующий результат будет настолько же больше, насколько выросла частота процессора. Т.е. если 1,86 ГГц CPU продемонстрировал в некой группе производительность X, подразумевается, что «идеальная» производительность 2,26 ГГц CPU будет равна Y=X*2,26/1,86. Соответственно, производительность 2,66 ГГц процессора будет равна Z=Y*2,66/2,26. Зачем эта линия на графике? Нам кажется, что она позволяет сделать результаты данного тестирования существенно более наглядными. В конце концов, конкретные цифры всегда можно взять из таблицы с подробными результатами, а вот степень расхождения между практикой и идеалом проще оценивать визуально.

На втором графике (если в нём есть необходимость) линии олицетворяют прирост производительности по мере увеличения частоты для каждого приложения из данной тестовой группы в отдельности. Отсчёт начинается с системы с частотой CPU 1,86 ГГц, производительность которой, соответственно, принята за 100% — поэтому все линии выходят из одной точки. Этот график позволяет нам более точно отследить поведение отдельных программ.

И, наконец — таблица с результатами тестов (также по каждому приложению в отдельности). Начиная со столбика «2,26 ГГц», в ней присутствуют не только абсолютные величины результатов, но и некие проценты. Что это? Это цифра, отражающая прирост производительности данной системы по отношению к предыдущей. Запомните, это очень важно: по отношению к предыдущей, а не к исходной. Таким образом, если мы видим в столбике «2,66 ГГц» цифру 22% — это значит, что система в данном приложении показала на 22% более хороший результат, чем при частоте процессора 2,26 ГГц.

Учитывая то, что разброс +/-2% у нас принято считать допустимой погрешностью измерений, мы получаем 3 диапазона: от +20 до +24%, от +16 до +20%, и от +13 до +17%. Хотя, впрочем, нижние границы нас не очень интересуют: масштабируемость запросто может являться неидеальной, и даже равняться нулю (отрицательной, теоретически, быть не может). А вот суперлинейный прирост с идеальной точки зрения невозможен — поэтому значения выше +24%, +20% и +17%, соответственно, придётся как-то объяснять.

Также, традиционно, мы даём любознательным читателям ссылку на таблицу в формате Microsoft Excel, в которой приведены все результаты тестов в самом подробном виде. А также, для удобства их анализа, присутствуют две дополнительные закладки — «Compare #1» и «Compare #2». На них, как и в таблицах, присутствующих в статье, произведено сравнение четырёх систем в процентном отношении. Разница очень простая: в случае с Compare #1, проценты вычисляются так же, как в таблицах в статье, — по отношению к предыдущей системе, а в случае с Compare #2, все системы сравниваются с базовой (1,86 ГГц).

3D-визуализация

* — здесь и далее в таблицах стрелочкой вверх (↑) помечены те тесты, где лучшим является больший результат, стрелочкой вниз (↓) — тесты, где лучшим является меньший результат.

Ждать от группы визуализации идеальной масштабируемости не стоило — всё-таки, по идее, в данном процессе не последнюю роль должна играть видеокарта. Однако, как оказалось, пакеты трёхмерного моделирования при интерактивной работе весьма существенно зависят от процессора, несмотря на использование различных 3D API (Lightwave и Maya — OpenGL, 3ds max — Direct3D). Собственно, чемпионом является как раз Lightwave, график которого представляет собой практически идеально прямую линию. Инженерные пакеты намного более скромны в аппетитах (то есть, получается, лучше используют видеокарту). Сверхлинейный рост производительности наблюдается при переходе с частоты 2,26 ГГц на частоту 2,66 ГГц (три раза) и при переходе с частоты 2,66 ГГц на частоту 3,06 ГГц (один раз). Пока что просто запомним это.

Трёхмерный рендеринг

Рендеринг, как и следовало ожидать, масштабируется практически идеально, причём независимо от пакета (и, соответственно, рендер-движка) — линии 3ds max, Maya и Lightwave на индивидуальном графике практически слились в одну толстую линию.

Научные и инженерные расчёты

Напомним, что в «вычислительной» группе участвуют приложения трёх типов: инженерные CAD, математические пакеты, и даже один пакет трёхмерного моделирования. Ситуация сложилась забавная: ни в одной группе, состоящей более чем из одного члена, «согласья нет». MAPLE и Mathematica возглавляют рейтинг самых хорошо масштабирующихся приложений (к ним присоединяется пакет трёхмерного моделирования Maya), однако у MATLAB с масштабируемостью скорости при росте частоты всё существенно хуже, особенно под конец. Инженерные CAD и вовсе разбрелись кто куда: у Pro/ENGINEER с масштабируемостью всё отлично, у UGS NX — похуже (его линия практически совпадает с MATLAB), а SolidWorks при переходе с 2,66 ГГц на 3,06 ГГц вообще практически никакого ускорения не получил. Соответственно, бессмысленно пытаться рассуждать о каких-то тенденциях при таком разнобое. Впрочем, благодаря приложениям-лидерам, средняя масштабируемость по группе вышла очень высокой (см. первый график — расхождение с идеалом весьма незначительно и начинается только под конец). И снова мы наблюдаем случаи сверхлинейного роста производительности, причём наиболее массовые при переходе с частоты 2,26 ГГц на 2,66 ГГц. Обратите внимание: учитывая количество случаев, это уже можно смело считать обозначившейся тенденцией.

Растровая графика

В группе растровой графики можно отметить поведение двух программ, выбивающихся из общей колеи: пакет ACDSee, который под конец перестал масштабироваться вообще (несмотря на то, что до этого у него всё было в норме и из общей группы он ничем не выделялся), и PaintShop Pro, у которого наблюдается резкий сверхлинейный скачок производительности. опять при переходе 2,26 → 2,66 ГГц! Чтобы не томить читателей, скажем сразу: увидим мы этот феномен ещё не раз и не два, а возможное объяснение ему мы дадим после комментариев ко всем тестам, т.к. по нашей версии оно универсальное, и от типа программного обеспечения совершенно не зависит.

Сжатие данных без потерь

Почти идеальная масштабируемость — и опять у WinRAR сверхлинейный рост в уже хорошо нам знакомой точке.

Компиляция

И снова мы наблюдаем «горб» на графике в районе 2,66 ГГц, где реальная производительность несколько превосходит идеальный прогноз. Однако расхождение не очень большое (см. таблицу с подробными результатами), около 2%, поэтому нельзя утверждать точно, имеем ли мы дело с вышеописанным феноменом, или же с банальной погрешностью измерений. Хотя, конечно, то, что эта «погрешность» опять возникла именно на точке 2,66 ГГц — конечно, наводит на определённые размышления. 🙂

Кодирование аудио

Достаточно странный результат, требующий дополнительных исследованний. Создаётся впечатление, что тест во что-то «упёрся», и это явно не процессор. Судя по данным предыдущих тестов, подозревать подсистему памяти не стоит. Быть может, жёсткий диск.

Кодирование видео

Одна из самых хорошо масштабируемых групп в этом тестировании, причём график по приложениям тоже очень плотный — все кривые, кроме одной, почти что складываются в одну толстую линию. Как ни странно, лидером группы является довольно старый Canopus ProCoder. Впрочем, данный феномен можно попытаться объяснить тем, что он же не очень хорошо использует многоядерность: более современные кодеки, умеющие задействовать все 8 ядер, должны создавать большую нагрузку на подсистему памяти — и, соответственно, зависеть ещё и от неё. А Canopus ProCoder остаётся зависеть исключительно от процессора.

Ситуация настолько похожа на предыдущую, что можно было бы сэкономить на диаграммах, использовав оба раза одну и ту же. 🙂 Впрочем, ничего странного в этом нет: коль SPECjvm способен создавать хорошую нагрузку для процессоров с любым количеством ядер — неудивительно, что он и масштабируется хорошо при повышении быстродействия CPU.

Трёхмерные игры

Тройка лидеров по процессорозависимости: Left 4 Dead*, Far Cry 2 и Unreal Tournament 3, причём Left 4 Dead идёт впереди всех с весомым отрывом. Следует заметить, что вхождение в тройку Unreal Tournament 3 может быть объяснено особенностью самого теста: в отличие от других игровых бенчмарков, бенчмарк для UT3 не воспроизводит заранее записанную демку, а имитирует реальную игру (CTF), с той только разницей, что всеми игроками на поле управляет компьютер. Потенциально, это действительно гораздо более сложная для процессора задача т.к. управление 8-ю игроками в режиме реального времени создаст хорошую вычислительную нагрузку даже при самом примитивном «искусственном интеллекте». Однако в целом всё плохо (или хорошо — зависит от того, с какой стороны смотреть): игровая группа демонстрирует самую низкую процессорозависимость, являясь по данному параметру «лидером наоборот» сегодняшнего тестирования.

* — мы привели результаты Left 4 Dead в таблице и на диаграмме т.к. они оказались самыми показательными с точки зрения зависимости от процессора, но не стоит забывать о том, что данный бенчмарк входит в группу «опциональных тестов», и, соответственно, не влияет на общий балл игровой группы.

Карты на стол!

Что ж, настала пора наконец-таки дать объяснения последнему неразгаданному феномену: массовым случаям сверхлинейного роста производительности при переходе от частоты 2,26 ГГц к частоте 2,66 ГГц. Быть может, мы кому-то покажемся несколько занудными :), однако давайте все вместе «станцуем от печки» — честное слово, так интереснее.

Итак: что нужно для того, чтобы на одном из «переходов» образовался сверхлинейный прирост производительности? Вопрос кажется дурацким (ибо ответ в первом приближении: «чтобы следующий по частоте процессор был сверхлинейно быстрее»), однако подождите делать преждевременные выводы: быстрее — отнюдь не единственный вариант. Если представить нашу гипотетическую идеальную производительность как функцию от частоты, т.е. быстродействие (S) = частота (F) * некий коэффициент (K), то сверхлинейный рост невозможен. Что нужно для того, чтобы он появился? Для этого нужно, чтобы следующему по частоте процессору спустился с небес некий бонус (+B) или. чтобы предыдущий процессор получил бонус отрицательный (-B) т.е. оказался бы медленнее, чем ему положено согласно его частоты. Итак, чувствуете, как изменилась наша задача? Теперь нам нужно найти ответ не на один вопрос, а на один из двух: либо на вопрос «почему 2,66 ГГц процессор такой быстрый?», либо «почему 2,26 ГГц такой медленный?» При этом также нельзя исключать того, что существуют ответы на оба вопроса*.

* — Вы правильно догадались: так оно на самом деле и есть. 🙂

Искали бы мы эти ответы, наверное, намного дольше, если бы не один счастливый факт: мы-то чётко понимали, что де-факто, физически, процессор был один и тот же. Изменялся только коэффициент умножения, с помощью которого получается частота работы ядра. Значит, если отбросить магию маленьких зелёных человечков, ответ может быть один: дело именно в коэффициенте умножения. Впрочем, это ещё не ответ. Это лишь область для поисков.

Ещё одно наше везение состояло в том, что коэффициенты умножения «быстрого» и «медленного» процессора уж очень сильно разнятся: 17 и 20. Первое число — вообще простое, т.е. делится только само на себя и на единицу. Второе — делится на 2, 4, 5 и 10. И вот как раз на цифре «4» прозвучала та самая «эврика!» — ну да, конечно же — коэффициент умножения внеядра во всех случаях был равен 16, а это число тоже делится на 4!

Подводя итоги: видимо, расходы на согласование между ядром и внеядром, когда они работают на разных частотах — действительно существенный фактор, способный влиять в том числе на быстродействие процессора. Соотношение между коэффициентами умножения ядра и внеядра в случае с частотой первого 2,26 ГГц, довольно «неудобное» — 17:16. И ввиду того, что 17 — простое число, сократить эту дробь невозможно. В случае с 2,66 ГГц процессором, соотношение составляет 20:16, что легко сокращается до 5:4. Судя по всему, универсальное правило «чем сильнее асинхронность — тем хуже», работает и в данном случае. Косвенным подтверждением этого служит вторая диаграмма, где сравнивается идеальный и реальный средний прирост производительности: чётко видно, что 2,66 ГГц процессор намного ближе к своему идеалу, чем 2,26 ГГц.

Разумеется, мы не можем сейчас настаивать на том, что изложенная гипотеза является доказанной: выявленный феномен требует дополнительного исследования, вполне возможно, с привлечением низкоуровневых тестов, которые в подобных случаях обеспечивают большую точность и больший разброс, нежели тесты с помощью реального ПО. Однако в рамках ныне проведенного исследования, гипотеза выглядит вполне непротиворечиво, и, к тому же, никакого другого объяснения вышеизложенным фактам, мы придумать пока не смогли.

Что же касается двух случаев сверхлинейного роста при переходе границы 2,66 / 3,06 ГГц — то их нам, увы, остаётся объявить «артефактами» данного тестирования т.к. с логической точки зрения они необъяснимы, а количество случаев настолько невелико, что списать всё на случайность ещё можно.

Конечно, несколько неожиданно наблюдать настолько стремительно возрастающую разницу между идеальным (под идеальным мы подразумеваем соответствующий росту частоты) приростом производительности и реальным уже на частоте 3,06 ГГц. Фактически, это означает, что даже в лучшем случае производительность гипотетического Core i7 3,46 ГГц будет равна примерно 156 баллов по нашей шкале (3,46 умножить на предполагаемую эффективность порядка 45 баллов за гигагерц) — и это ещё достаточно оптимистичный прогноз. С другой стороны — может, увеличение объёма кэша третьего уровня позволит поднять общую эффективность системы, так что бить тревогу ещё рановато. Собственно, это косвенно подтверждается достаточно спокойной позицией Intel, которая отнюдь не торопится с анонсами новых процессорных архитектур, предпочитая «подтягивать хвосты» в других областях — например, в области графических решений и их интеграции с CPU. Поэтому в целом, мы бы сказали, ничего удивительного нам сегодняшнее тестирование не открыло: да, как правило, в рамках одной и той же архитектуры, чем больше частота — тем меньше эффективность. Это давно всем известно, и блестяще подтвердилось практическими результатами.

Однако раз уж мы провели такое полномасштабное тестирование, грех было бы останавливаться на одной только процессорной тематике, не затронув сами программы. Давайте посмотрим: а какие группы ПО из используемой методики как реагируют на увеличение частоты работы процессорного ядра? Для начала, возьмём разницу между двумя крайними точками: 1,86 ГГц и 3,06 ГГц.

Распределение вполне ожидаемое: научные и инженерные вычисления, рендеринг, архивация, кодирование видео. Несколько правда, странно наличие в нижних строчках группы кодирования аудио. Самая нижняя позиция игровой подгруппы, наоборот, лишь подтверждает правильность нашего выбора опций для тестирования: с нормальными графическими настройками производительность в играх и не должна сильно зависеть от процессора.

А теперь давайте посмотрим на тот же рейтинг, но уже с точки зрения разницы между двумя последними позициями: 2,66 ГГц и 3,06 ГГц. Эта диаграмма позволит нам ответить на вопрос: какие приложения сохраняют хорошую масштабируемость даже на самом верхнем пределе частот?

Первый сюрприз связан как раз с первым же местом: лучше всего масштабируются на верхних частотах, как оказывается, Java-приложения. Больше сюрпризов не наблюдается: все те же рендеринг, кодирование видео, научные и инженерные расчёты. В целом, можно констатировать, что никаких расхождений с нашими интуитивными ощущениями две последних диаграммы не вызывают: даже не видя результатов, руководствуясь одними только логикой и здравым смыслом, пятёрку лидеров любой из редакторов процессорного раздела назвал бы легко.

Источник