Прямое сравнение производительности КПК и настольных систем

Современные КПК достигли внушительных характеристик. Это уже не чахленькие машинки с 8-МГц процессором и черно-белым экраном 160х160, способные только на то, что бы вести список дел и телефонную книгу. Сейчас КПК способен на большее - воспроизведение музыки и видео, 3D-игры, работа со сложными офисными приложениями, полноценный интернет и электронная почта. То есть практически все, на что способен большой десктоп. Абстрактный Топ-КПК 2005 года имеет следующие характеристики: процессор Intel PXA27X с частотой 624МГц; крупный (до 4-х дюймов) экран с разрешением 480х640; до 128 Мб оперативной памяти; видеоакселератор от фирмы ATI или Intel, 2 беспроводных интерфейса - WI-FI и Bluetooth, 2 слота расширения - Compact Flash и SD в которые суммарно можно установить до 10Гб flash памяти либо различную перфирию - GPS/GSM модули, сетевые карты, модемы, FM-тюнеры и т.д. Все это работает под управлением операционной системы Windows Mobile. Согласитесь, такими характеристиками еще лет 5 назад мог похвастаться далеко не каждый десктоп или ноутбук. При этом весь КПК собран в компактном корпусе весом менее 200 грамм, а энергопотребление, как правило, не превышает 1 Вт, что позволяет проработать устройству 7-10 часов от одного заряда аккумулятора. А цены на такие девайсы опустились ниже $600. Все это вывело уровень мобильности и удобства работы на недоступную ранее высоту.

Но возникает резонный вопрос - насколько же эти машинки реально быстры, как соотносится их скорость работы и скорость обычных х86 совместимых машин. Не поспешили ли некоторые журналисты с утверждениями, что современный КПК может полностью заменить ноутбук? Может ли КПК посоревноваться с х86-и машинами в плане быстродействия? Эта статья попробует пролить свет на данный вопрос. Собственно, то, что х86 процессора будут производительнее, ясно и так, но хотелось бы получить некоторые количественные характеристики. На сколько производительнее? В 2 раза, в 10, в 100?

Для ответа на этот вопрос, вместо теоретического анализа процессорных архитектур, воспользуемся тестовой программой - ведь нас интересуют прежде всего практические результаты. Так как процессорные архитектуры Intel StrongARM и Intel x86 несовместимы в плане бинарников, придется прибегнуть к некоторым допущениям. Так же, для простоты, ограничимся только сравнением вычислительной мощности процессоров, что, правда, неизбежно затронет и скорость подсистемы памяти. Итак, для данного сравнения я написал специальное тестовое приложение, которое выполняет различные вычисления, и, соответственно, замеряет время расчетов. Эту программу вместе с исходниками вы можете скачать здесь. Так что, при желании, можно проверить мои расчеты, модифицировать тесты и убедиться, что в программе нет "заточек" :-) Для платформы х86 программу нужно компилировать в MS Visual C++ 6.0, а для PocketPC - в MS eMbedded Visual C++ 4.0 Sp4. Так как мы сравниваем аппаратные платформы, а не компиляторы (даже не смотря на то, что оба компилятора от одного производителя и достаточно похожи), в обоих случаях в настройках проекта я отключал любую оптимизацию. Я долго думал над этим моментом, но так на мой взгляд правильнее, хотя этим мы ставим платформу PXA27X в менее выгодное положение, ведь это более новая RISC архитектура и, в отличии от x86, в ней анахронизмов и кривостей намного меньше, и соответственно возможностей для оптимизации больше (это подтвердили и мои пробные тесты). В любом случае, естественно, полностью эквивалентного кода получитьcя не может хотя бы потому, что у этих процессоров разная архитектура, разное количество регистров, не идентичный набор машинных команд и т.д. Хорошо хоть, что они оба 32-х разрядные. Вообще все мои вычисления достаточно приблизительные и оценочные, я ведь не использую многих возможностей архитектур, например Wireless MMX, MMX, SSE1-SSE3 и некоторые другие. С другой стороны, данные расширенные команды нужны только для специфических задач. В моих же задачах их эффективно использовать не удалось бы. Все-таки быстрее простого регистра общего назначения для работы с 32-х битными числами ничего нет.

Пара слов о процессорах семейства Intel PXA27X. Линейка состоит из 3-х процессоров: PXA270 - отдельный (дискретный) процессор, PXA271 - процессор вместе с 32MB Flash и 32MB низковольтной SDRAM, PXA272 - процессор вместе с 64 MB Flash. Частота внешней шины 104МГц. Внутренняя частота получается с помощью целого коэффицента. При отсутствии нагрузки, процессор может понижать свою частоту с шагом в 104МГц, путем уменьшения коэфф. умножения вплоть до 1. Максимальная частота процессоров семейства PXA27X - 624МГц (коэфф. умножения 6); минимальная - 312 (коэфф. 3)

Мой тестовый стенд состоит из следующих машин:

1. НР iPAQ hx4700 (процессор Intel XScale PXA270 624МГц);
2. Dell Axim x50v (процессор Intel XScale PXA270 624 МГц);
3. Dell Axim x30(процессор Intel XScale PXA270 312 МГц);
4. Toshiba E755 (процессор Intel XScale PXA255 400МГц);
5. PentiumIII 866 (чипсет i815G);
6. Ноутбук IBM ThinkPad 390X (процессор Intel PentiumIII 450);
7. PentiumII 350 (чипсет 440BX);
8. Celeron 1700 (чипсет i845P).

Я намеренно привожу не полные характеристики компьютеров - только те, от которых зависит результат. Как вы увидите дальше, единицы процентов не играют никакой роли и не влияют на общий результат. На время проведения тестов КПК, если у них есть такая штатная возможность, переводились в режим максимальной производительности. Каждый тест запускался по 3 раза, запоминался самый лучший результат. Так же прошу заметить, что в тестовом стенде участвуют одни из самых быстрых на данный момент КПК и достаточно устаревшие "писишки". С одной стороны, это неправильно, с другой - подчеркнет результат. Кроме того, было бы глупо сравнивать процессора, которые производитель позиционирует как решения для высокопроизводительных рабочих станций и серверов с мобильными процессорами. Хоть PXA270 и топ-процессора в линейке, но по цене они дешевле самых бюджетных процессоров архитектуры x86. Если бы мы тестировали производительность встроенной графики интегрированных чипсетов, то логичнее было бы сравнивать их с бюджетными видеокартами, а не с топовыми за $500. Если же вы не согласны с моим выбором тестового стенда, то никто вам не мешает запустить этот тест на вашей личной системе и сравнить результаты - моя методика полностью описана и максимально открыта. И вот еще один довод - это только на первый взгляд х86 и StrongARM не конкурируют между собой. На самом деле, StrongARM используется, кроме КПК, еще во множестве других устройств - в различной встраиваемой технике, банкоматах, игровых автоматах, терминалах, планшетах, промышленном оборудовании, а по слухам, даже в космических аппаратах. Для этой платформы есть хорошие операционные системы и замечательные средства разработки. PXA используются там, где нужны экономичные, дешевые и компактные решения при умеренной производительности. И именно в этой области PXA конкурирует с х86, причем не с Xeon-ами и P4XE, а скорее с VIA C3, С7 и Celeron-ами. Посмотрите, какие возможности PXA предоставляет разработчикам устройств - при использовании процессора PXA271 не нужно дополнительно думать, ни о жестком диске, ни об оперативной памяти - все встроено, а значит дешево и надежно. Так же Intel, в соответствии со своей новой идеологией, продавать не процессора, а готовые платформы, предлагает совместно с процессорами PXA семейство мультимедийных акселераторов 2700G, предназначенных для обеспечения аппаратного ускорения при отображении двумерной и трехмерной графики (интерфейсы OpenGL и JSR), воспроизведения видео с качеством DVD (форматы MPEG2, MPEG4, WMV), поддержки двух дисплеев. Конечно жаль, что на момент проведения тестов у нас не оказалось машин на процессорах от VIA. Ведь именно их сейчас все чаще используют во встраиваемой технике. Но, зная результаты для перечисленных выше х86 машин, можно приблизительно прикинуть результаты и для процессоров VIA. Кроме того, я надеюсь еще вернуться к данной теме. Как оказалось, в одной статье невозможно затронуть все аспекты. "За бортом" остались такие интересные мобильные процессора, как TI OMAP, Samsung S3C, PentiumM и т.д.

Все вычисления можно разделить на вычисления с вещественными(т.е дробными) числами и вычисления с целыми числами. Для представления вещественных чисел я выбрал тип double (8 байт), а для целых - DWORD (4 байта). Перейдем, наконец, собственно к тестам. Начнем с вычислениями над числами с плавающей точкой.

Итак, первая задача - вычисления числа PI с помощью ряда 1 - (1/3) + (1/5) - (1/7) + ... = (PI/4). Замечу, что все вычисления в этой программе проводятся не ради результата, а исключительно ради самих вычислений. Так что, не обращайте внимание на примитивизм используемых математических методов и упрощения.

Вторая задача - вычисление интеграла функции Sin(x) при 0 <= x <= PI методом прямоугольников.

Что мы видим? Отставание платформы PXA27X на вычислениях с плавающей точкой составляет десятки раз! Впрочем, этот результат объясняется очень просто. У процессора PXA27X нет ни математического сопроцессора (FPU - Floating Point Unit), ни других средств работы с вещественными числами. Все вычисления компилятор свел к цельночисельным, в этом можно легко убедиться, если дизассемблировать код. К слову, в отсутствии мат.сопроцессора нет большой проблемы. Числа с плавающей точкой используются только в специфических задачах, которые навряд ли кто-то выполняет на КПК. Так что, отказ от мат.сопроцессора в процессоре PXA27X это скорее правильное решение инженеров Intel. За счет этого удалось уменьшить площадь ядра, энергопотребление и цену. Есть мнение, что вычисления с дробными числами нужны в 3D играх. Это так, но эти вычисления реализованы таким образом, что FPU не задействован - он слишком медленный. Пытаться использовать мат.сопроцессор в играх, где нужны значительные объёмы вычислений - безумие. В старых играх для представления дробных чисел использовались собственные типы данных с фиксированным положением точки, работа с которыми сводилась к цельночисельным операциям, ведь в играх скорость важнее точности, да и диапазон значений известен заранее. А для получения значений различных математических функций, например, тригонометрических, использовались (да и сейчас используются) заранее расчитанные таблицы. В современных же играх, для вычислений с дробными числами используются наборы команд SSE, SSE2 или средства видеокарты. Мат. сопроцессор нужен для математических вычислений, когда важна точность расчетов, время же расчетов вторично. Для этих задач технологии SSE/SSE2 подходят плохо - у них недостаточная точность представления чисел (SSE - до 32-х битов, SSE2 - до 64-х, в то время как у FPU до 80-ти.) и к тому же они не умеют вычислять тригонометрические и логарифмические функции.

Теперь перейдем к тестам с целыми числами. При этом, тесты обрабатывающие массивы данных, я буду проводить для разных размеров массивов. Ведь, как известно, скорость выполнения таких задач зависит не только от вычислительной мощности процессора, но в не меньшей мере и от размера и скорости кэша, скорости памяти, эффективности реализации всей подсистемы памяти в целом. У процессора PXA27X кэш состоит за 3-х частей: 32Кb - кэш инструкций (i-cache), 32Kb - кэш данных второго уровня (d-cache), 2Kb - кэш данных первого уровня (Mini-data cache); имеется 13 32-х битных регистров общего назначения (R0-R12), причем каждая команда машинного кода занимает ровно 4 байта (в режиме "ARM instruction set" или ровно 2 в устаревшем и почти неиспользуемом режиме "Thumb"). Сравните с убогими четырьмя регистрами EAX, EBX, ECX, EDX процессоров х86 (ладно, пускай еще ESI, EDI, EBP) и длинной команды от 1 байта до 7 и более (понятно, почему в х86 так сложно организовать оптимизацию, распараллеливание выполнения, алгоритмы предсказания переходов).

Первая задача - возведение в квадрат единичной матрицы. Что бы можно было точнее измерить время для небольших матриц, тест выполняет расчеты по несколько раз (детали реализации можно посмотреть в исходниках). Буду рассматривать 3 размерности матрицы: 700х700 (размер используемой памяти ~1,87Мб); 70х70 (~20Кб); 10х10 (400б).

Следующая задача - сортировка псевдослучайной последовательности чисел пузырьковым методом. Как и в прошлой задаче, проведу операцию для последовательностей разной длины: 50000 элементов (~200Кб); 5000 (~20Кб); 100 (~0,5Кб).

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

Ну наконец-то нашелся хоть один тест, в котором самые мощные и дорогие КПК "сделали" старенький десктоп!

Ну и для размышлений приведу таблицу с "нормированными" значениями. То есть значения буду рассчитывать по формуле v = vt*(h/1000), где vt - время полученное в тесте, h - частота процессора. Таким образом, такое значение показывала бы данная система на частоте 1ГГц, при условии линейной зависимости производительности от частоты.

Из этой таблицы хорошо видно - чем меньше объем обрабатываемых данных, тем быстрее работает PXA27X, тем больше он догоняет x86. Это говорит об эффективности реализации ядра. Но у него не слишком быстрая шина памяти, да и кэша маловато. Так же стоит отметить следующий момент: когда все данные помещаются в кэш, процессора Xscale работают со скоростью пропорциональной частоте. Причем ядро PXA255 показывает такую же производительность, как и PXA27X. Но как только программа начинает использовать данные, которые не умещаются в кэши, картина сильно меняется: чем меньше коэффициент умножения процессора, тем эффективнее он работает. Так что и на этих процессорах нет смысла сильно увеличивать коэффициент умножения - для дальнейшего роста производительности нужно делать более быструю шину (и/или увеличивать кэш данных).

Теперь настало время сделать выводы. Процессора PXA27X работают значительно медленнее процессоров х86, даже работающих на меньшей частоте. Причем отставание составляет разы. Жаль, что я не смог провести тест на системах с процессорами Pentium, Pentium MMX - возможно удалось бы найти систему, которая наиболее соответствует по скорости процессорам серии PAX27X. Получается, что либо PXA27X слишком медленный, либо просто x86-е процессора слишком быстрые. Но зато они потребляют на порядки больше электричества. А ведь именно экономичность - одна из важнейших характеристик любого мобильного устройства. Кому нужен был бы КПК, если бы он мог бы работать от одной зарядки всего 2 часа? Если не считать модуля Wi-Fi, именно процессор самый большой потребитель энергии в КПК - во всяком случае, об этом говорят тесты на продолжительность работы от одного заряда аккумулятора - при полной нагрузке на процессор время работы уменьшается в разы, относительно минимальной нагрузки. Так что именно энергопотребление - основной ограничитель производительности. Ведь даже Крейг Баррет (председатель совета директоров Intel) заявлял, что нет никаких технических сложностей в изготовлении процессора для КПК с частотой 1 и даже 2ГГц, но потреблять электричества такой процессор будет столько, что никакой аккумулятор его долго не прокормит. К тому же, как известно, вся потребляемая электрическая мощность процессора преобразуется в тепло, а использовать большие куллера и радиаторы на КПК не представляется возможным. Архитектура же x86 наоборот, нацелена на бескомпромиссное увеличение производительности любой ценой. И эта цена действительно заплачена в виде огромного тепловыделения, превышающего на топ-моделях процессоров 100Вт и большущей площади ядра! В то время, как у процессоров PXA27X мощность не превышает 0.5Вт (для сравнения, по приблизительным оценкам, мощность мозга взрослого человека равна 5-8Вт). Про разницу в цене я молчу (PXA27X стоит меньше $30). Но вот если бы мы рассматривали соотношение производительность на ватт, то архитектура Intel StrongARM оказалась бы безусловным лидером. Вообще PXA27X архитектурно намного более грамотный процессор. Ведь архитектура Х86 несет в себе тяжким грузом необходимость бинарной совместимости со всем старым кодом, написанным с 70-х годов. Большая часть ядра (если не учитывать кэш) занята не исполнением кода, а транслированием из одной системы команд в другую и разными вспомогательными операциями. Даже такой маркетинговый прием как псевдо-64-х разрядность не поможет. PXA27X же первоначально разрабатывался как 32-х битный процессор на основе эффективной Superpipelined RISC технологии с 7-8 стадийным конвеером. При сравнении процессоров не стоит зацикливаться только на производительности - она не всем важна. Для меня, например, самое важное качество в компьютере - надежность. А для многих - мобильность, не зря ведь продажи ноутбуков почти догнали продажи десктопов, несмотря на более высокую цену и более низкую производительность. Фирма Intel не была бы лидером, если бы останавливалась на достигнутом. По недавним сообщениям, Intel-у удалось разработать новый 65нм техпроцесс со сверхнизким энергопотреблением, в котором токи утечки удалось снизить на несколько порядков. Так что, в ближайшие пару лет нас ожидают интересные сверхэкономичные процессорные новинки.

Примечание

Лично я, других исследований на тему сравнения производительности архитектур StrongARM и х86 не нашел, поэтому пришлось придумать собственную методику и написать тестовое приложение. Соответственно не обошлось без нескольких спорных моментов. Это ведь не очередной обзор коврика для мыши или тестирование мягкости нажатия кнопок мобильного телефона. Самый спорный момент в данной статье - отказ от оптимизации кода. Остановлюсь на этом моменте подробнее. Архитектуры х86 и StrongARM несовместимы на уровне машинного кода, соответственно мы вынуждены воспользоваться разными компиляторами. А разные компиляторы и оптимизируют по-разному. Одни "сообразительнее", другие менее сообразительные. Соответственно, возможна ситуация, когда более слабый процессор покажет лучшие результаты, чем более быстрый, за счет более сообразительного компилятора. А нас интересует сравнение именно самих процессоров. В принципе, можно было бы сделать данный тест и единым, если бы мы его написали на C#. Тогда бы, один и тот же exe-шник можно было бы запускать и на x86-х машинах, и на StrongARM. Но тогда мы, стали бы заложниками эффективности реализации .NET Framework на соответствующей платформе. А мне хотелось максимально контролировать получаемый код и быть как можно независимее от ОС, компилятора, версии .NET Framework и т.д - то есть всего, что не связано с железом. Естественно, это неосуществимо. Но снизить влияние других факторов вполне можно.

Несколько слов об оптимизации

Оптимизацию можно условно разделить на 3 вида:

1.Оптимизация машинного кода.

Дело в том, что одну и ту же программу, написанную на языке высокого уровня, в данном случае на С, перевести в машинный код можно множеством способов. Вот простой пример. Допустим нам нужно поместить в регистр AX - ноль. Это можно сделать следующими способами:

1. MOV AX, 0;
2. MOV AL, 0; MOV AH, 0;
3. XOR AX, AX;
4. XOR AL, AL; XOR AH, AH;
5. XOR AL, AL; MOV AH, AL;
6. PUSH 0; POP AX.

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

2. Использование специфических особенностей процессора.

Это, прежде всего, расширенные наборы команд MMX, SSE1-3 и другие (конкуренты Intel тоже не отстают в командотворчестве). Эти команды хороши, но не всесильны. Область их эффективного применения довольно ограничена. Их суть ясна из их общего названия - SIMD (Single Instruction - Multiple Data/Одна инструкция - Много данных). Другими словами, они позволяют выполнить за одну команду какое-либо действие сразу же над несколькими числами. Это достигается за счет того, что данные наборы команд работают со специальными длинными регистрами, в которые можно поместить целый набор чисел - до 16-ти. MMX предназначен для обработки целых чисел и использует регистры сопроцессора (только 64 бита), в то время, как SSE работает с вещественными числами и использует собственные 128-битные регистры. SSE2, SSE3 развивают идеи заложенные в MMX и SSE. Таким образом, данные команды хорошо подходят для алгоритмов, которые выполняют простые, однотипные действия над большим объемом данных. Причем, эти алгоритмы должны иметь поменьше условных переходов, а вычисления можно было бы "распараллелить" (т.е для каждого последующего вычисления не нужно было бы знать результат предыдущего). В качестве примеров таких задач можно привести MPEG-декомпрессию, шифрование, преобразование цветового пространства, наложение текстуры, работу с комплексными числами, быстрое преобразование Фурье, дискретное косинус-преобразование, обсчет 3-х мерных сцен. Это весьма ресурсоемкие задачи, которые постоянно встречаются при работе с мультимедийными данными и играми. Поэтому понятно, почему инженеры Intel ввели в архитектуру процессора механизмы ускорения подобных задач - имеет смысл ускорять то, что выполняется дольше всего. Задачи из моего тестового приложения очень плохо подходят для данного вида оптимизации. В них сплошные условные переходы, размерности массивов задаются переменными, вычисления не распараллеливаются, используются тригонометричекие функции.

3.Оптимизация алгоритма.

Его суть заключается в замене одного алгоритма, другим, более быстрым (или более коротким, если выбрана оптимизация на размер), но который делает тоже самое. Тоже небольшой пример. Пусть есть программа:

int a = 1;

for (int i = 0; i < 3; i++) a += i*a;

она может быть оптимизирована, например, следующим образом:

int a = 1;

a+= 0*a;

a+= 1*a;

a+= 2*a;

очевидно второй вариант будет сильно быстрее (этот метод оптимизации называется "развертывание цикла"). А более умный компилятор может вообще заменить эту программку одной строчкой:

int a = 6

или вот еще пример:

int i, j, a = 0;

for (i = 0; i < 10; i++) {

for (j =0; j < 10; j++) {

a += (i*15 + j*20);

}

}

можно оптимизировать, например, так:

int i, j, k, a = 0;

for (i = 0; i < 10; i++) {

k = i*15;

for (j =0; j < 10; j++) {

a += (k + j*20);

}

}

в первом случае имеем 200 операций умножения, во втором всего 110. Соответственно второй вариант сильно быстрее. (Этот метод оптимизации называется "вынос константы из цикла").

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

Именно что бы исключить влияние последнего вида оптимизации, я ее и отключил. Мне нужно было, что бы каждый процессор выполнил один и тот же объем вычислений на одном и том же алгоритме. Меня не устраивала ситуация, когда на одной архитектуре, благодаря хорошей оптимизации, могло выполняться в 2 раза меньше вычислений, чем на ее "сопернице". Собственно, это основное требование при проведении любых тестов - нужно что бы выполнялось строго одинаковое задание. Если бы я сравнивал не исключительно процессора, а платформу в целом, включая все приемущества и недостатки, то тогда, возможно, имело бы смысл оптимизацию и включить. Ведь существование хорошо оптимизирующего компилятора - большое приемущество платформы. Но я сравнивал только процессора и мне нужно было поставить их в одинаковые условия. К тому же, если бы я в своих расчетах использовал оптимизированную версию тестового приложения, то сразу же возникла бы масса вопросов: какие ключи оптимизации использовать, а какие нет? Что делать если с одними ключами оптимизации одна задача работает быстрее, а другая медленнее, относительно другого набора ключей? Почему выбран именно этот компилятор и эта ОС? Какой вариант теста использовать, если один компилятор лучше оптимизирует одни задачи, а другой компилятор - другие? Какой компилятор использовать, если один лучше оптимизирует архитектуру PentiumIII, а другой Pentium4? К сожалению, перепробовать все компиляторы со всеми ключами оптимизации, на всех ОС у меня не было возможности. А при выключенной оптимизации все компиляторы переводят программу в машинный код более-менее одинаково. Да и компиляторы я выбрал похожие и от одного производителя. Эти 2 компилятора, несмотря на свой возраст (особенно Visual Studio 6.0 - он был выпущен в 1998г; eMbedded Visual C++ 4.0 - 2004г.), до сих пор очень широко используются программистами. VC++ 6.0 стал своего рода классикой - он быстрый, компактный, с удобным интерфейсом. В нем есть все что нужно; многие С++ программисты просто не видят смысла переходить на что-либо другое. Если бы мы выбрали другие компиляторы, то вероятно, разброс результатов был бы немного другой, но общая картина осталось бы прежней. Для эксперимента я скомпилировал данный тест в появившемся всего лишь несколько недель назад и широко рекламируемом пакете разработки Visual Studio 2005. К счастью, он "съел" проект без малейшей модификации. Естественно, параметры компиляции я установил такими же. Вот результаты для компьютера с процессором PentiumIII 866:

Как видите, на новейшем компиляторе и компиляторе выпущенном уже 7 лет назад, код, в плане быстродействия, получился практически одинаковым! Конечно, по одному этому примеру еще ни о чем судить нельзя. Вообще, данная статья имеет и некоторый философский смысл - она наглядно демонстрирует невозможность полностью объективного сравнения. Любая методика тестирования неизбежно накладывает ограничения. Особенно это касается сравнений различных платформ. Понятие производительности многомерное и его нельзя однозначно спроецировать на плоскую шкалу. Пространство вычислительной мощности системы состоит из множества измерений (осей), в том числе из следующих:

• скорости работ с целыми числами;
• скорости работы с дробными числами;
• скорости работы с большими объемами данных;
• скорости работы с маленькими объёмами данных;
• скорости работы на сильноветвящихся алгоритмах;
• скорости работы на линейных алгоритмах.

Увеличение производительности по одному измерению не всегда ведет к увеличению по другим измерениям.

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

По многочисленных просьбам приведу таблицу, которую я получил, включив в компиляторах оптимизацию (пресет Maximize Speed). Только замечу, что учитывая все вышесказанное, эта таблица не имеет никакого особого практического смысла. Разве только подтверждает моё предположение, что на StrongARM есть больше возможностей для оптимизации.

Строка "Ratio" - ускорение работы после оптимизации. Жирным выделен лучший результат. Как видим, эффект от оптимизации оказался весьма значителен. В большинстве случаев PXA показал более сильное ускорение работы. Но все-равно, до х86 еще далеко. Забавный момент - после включения оптимизации тест "Prime" на PIII стал работать даже медленнее - такие "баги" иногда случаются.

Ну и "нормированные" значения: