Проведенное недавно исследование производительности топовых десктопных процессоров от Intel и AMD при кодировании видео, не скроем, оставило нас в тягостном недоумении — разгромные для процессора Pentium 4 результаты кодека XviD что называется «на голову не налезали». Оно-то понятно, что разный код по-разному исполняется на разной архитектуре, и девиации производительности от программы к программе — это неизбежное зло, с которым все уже давно привыкли мириться. Но, простите, не в два же раза! Никто не сомневается (надеемся), что с точки зрения быстродействия и Athlon XP 3200+, и Pentium 4 3.2 ГГц — вполне пристойные процессоры. Следовательно, если один из них оказывается в два раза быстрее другого — это ненормально. И даже неважно, какой именно выиграл, а какой проиграл. Просто такой ситуации в случае с нормально написанным программным обеспечением быть не должно в принципе. Следовательно, что-то не так именно с ПО.
Решив озадачиться данным вопросом всерьез, мы сперва проверили самые простые предположения. Первым из них было: что-то не то с исходным файлом для кодирования. В конце концов, компрессия видео — процесс сложный, и чисто теоретически можно предположить, что комбинация некоего конкретного исходного видеоряда с конкретной процессорной архитектурой, может каким-то странным образом вводить оную архитектуру в ступор. Проверить это было несложно: взяв наш стандартный тестовый пакет и просто заменив в скрипте для VirtualDubMod TEST.MPG на TEST.VOB, мы провели кодирование другого исходника с помощью той же версии XviD и при тех же параметрах кодека:
Как видите, ситуация кардинально не изменилась: да, некоторые различия присутствуют — если в случае с нашим стандартным MPG-файлом (формата MPEG2) Pentium 4 3.2 ГГц проигрывал Athlon XP 3200+ примерно в два раза, то теперь проигрыш увеличился до 2.1-кратного. Однако принципиальным изменением ситуации это назвать никак нельзя. Значит, дело не в исходнике.
Следующее логичное предположение — виновата данная конкретная версия XviD. Его было достаточно легко проверить: в той же стандартной методике, мы заменили версию кодека, выставили ему (насколько это возможно, учитывая различия в настройках разных версий) те же параметры кодирования, и произвели соответствующие измерения. Для тестов были взяты два билда — предыдущий от того же билдера (Koepi build 24.06.2003) и самый свежий от другого — Nic’s build 16.07.2003. Последний, кстати, компилировался с помощью Intel C Compiler 7.1, что по идее должно было сказаться благоприятно на его производительности применительно к процессорам Intel. К слову о билдерах: являются ли Koepi и Nic девелоперами XviD нам, честно говоря, понять так и не удалось. По заявлениям самого Koepi, он для XviD что-то писал, но в списке разработчиков его нет. Относительно Nic — еще запутанней. Но поскольку именно эти двое являются основными поставщиками готовых бинарников (особенно Koepi, именно его билды чаще всего можно обнаружить в кодек-паках), мы посчитали, что «полномочно представлять XviD» в нашей статье они вполне в состоянии. Что ж, посмотрим на результаты.
Прослеживаются две закономерности. Первая: билд от Nic действительно намного более лоялен к процессору Pentium 4. Вторая: билды от Koepi к процессору Intel подчеркнуто нелояльны: если производительность Athlon XP на новом билде по отношению к старому увеличилась весьма значительно, то Pentium 4 как был «тормозом», так и остался. Однако все равно данные результаты нас не удовлетворили, оставалось впечатление, что с билдами от Koepi что-то не то, и дело не только в коде.
Поэтому мы решили проверить еще одно шальное предположение: а вдруг просто неправильно подбираются параметры оптимизации? Многие, наверное, помнят, как Microsoft Windows Media Encoder пытался определить наличие поддержки SSE, проверяя производителя процессора (он, видите ли, считал, что если это не Intel — то SSE там быть не может). Благо, за исключением автоматического определения, в настройках кодека XviD можно указывать используемые наборы SIMD-команд вручную. Поддерживаются (в терминологии разработчиков): MMX, 3DNow!, 3DNow! 2 (видимо, имеется в виду Extended 3DNow! процессоров на ядре K7), SSE, Integer SSE (?) и SSE2. Ввиду того, что Athlon XP поддерживает SSE в полном объеме, равно как и «3DNow! 2», мы объединили в рамках данного тестирования опции 3DNow! и 3DNow! 2 в просто «3DNow!», а также Integer SSE и SSE в просто «SSE». Что ж, посмотрим для начала на то, как себя ведет последний билд XviD от Koepi (1.0 beta 2, 05.12.2003) с различными выставленными вручную оптимизациями на Athlon XP 3200+.
Легко заметить, что наибольшее действие оказывает включение MMX-оптимизации — фактически, это можно назвать применительно к Athlon XP решающим моментом. Оптимизация для 3DNow! существенно проигрывает по эффекту SSE, но даже обе они вместе не приводят к такому эффекту как задействование набора инструкций MMX. В общем-то, возникает законный вопрос: а что ж это за такая странная оптимизация, что лохматой давности MMX «уделывает» 3DNow! + SSE вместе взятые? Странно… По меньшей мере очень странно. В общем-то, уже этот факт достаточно хорошо свидетельствует о том, что дела с оптимизированным кодом в проекте обстоят не очень хорошо. Однако это еще цветочки! Ягодки впереди — смотрим на результаты Pentium 4!
Так вот ты какой, оказывается, северный олень… Включение поддержки MMX к некоему эффекту приводит, да. Но только по сравнению с отсутствием какой бы то ни было другой оптимизации вообще! А вот если мы начинаем задействовать MMX, к примеру, вместе с SSE — то это дает на Pentium 4 совершенно фантастический эффект: производительность резко падает! Причем более чем в полтора раза! Также можно заметить, что никакой реально видимой оптимизации под SSE2 кодек не содержит: сравните столбики «No Optimization» и «SSE2», а также «MMX» и «MMX+SSE2», «SSE» и «SSE+SSE2». Кроме того, видно, что ругаемая нами в предыдущем абзаце оптимизация под SSE действительно присутствует, и сделана она хорошо, просто на Athlon XP она блекнет перед эффектом от включения поддержки MMX, а вот в случае с Pentium 4 видна на фоне остальных более зримо. По крайней мере на данном процессоре SSE — это единственный вид SIMD, использование которого вообще дает эффект. Что мы имеем в результате? А просто-напросто то, что производительность процессора Pentium 4 при работе с кодеком XviD 1.0 beta 2 (Koepi) в случае использования автоматических настроек параметров оптимизации получается искусственно заниженной. Причем на колоссальную величину: в 1,6 раза!
Для того чтобы ощутить это более грубо и зримо, приведем такой пример: даже если предположить, что производительность Pentium 4 будет расти пропорционально частоте, для того чтобы достичь результата, обеспечиваемого правильным выбором оптимизационных параметров, при параметрах по умолчанию, нам понадобился бы процессор с частотой… 5 гигагерц! А вот они, гигагерцы, под боком лежат. Нужно только немного компенсировать custom-настройками чьи-то корявые ручки… Если, конечно, знаешь о существовании самой проблемы. А если нет? Теперь давайте посмотрим на те же данные немного с другой стороны, чтобы подвести итоги.
Итак, предметом рассмотрения является SIMD-оптимизация в кодеке XviD 1.0 beta 2 Koepi build. Странная оптимизация, нужно сказать. Наибольший эффект для Athlon XP обеспечивает самый древний набор SIMD — MMX (при том что он же, как выяснилось, губит на корню производительность Pentium 4), SSE сделан довольно хорошо (прирост по сравнению с отсутствием оптимизации для Athlon XP — двукратный, для Pentium 4 — в 1,9 раза), SSE2 заявлен, но его не удается обнаружить вообще. Оптимизация же для 3DNow! позволяет Athlon XP догнать… Pentium 4, работающий вообще без какой-либо оптимизации! Однако, может все это — просто особенность данной версии XviD? Проверять так проверять — и мы снова взялись за Koepi build 24.06.2003 и Nic’s build 16.07.2003. Понятно, что исследовать работу различных версий XviD, судя по всему, можно до бесконечности, поэтому на этот раз наш интерес ограничился только одной проверкой: приводит ли запрещение MMX-оптимизации в других версиях кодека к тому же «магическому эффекту» на системах с процессором Pentium 4?
Что ж, к чести проекта в целом, нужно сказать, что настолько корявая версия, кажется, является исключением. Более того — убийственная для Pentium 4 MMX-оптимизация может заслуженно считаться эксклюзивной фишкой именно XviD 1.0 beta 2 от Koepi. Хотя две нижние строчки (Koepi build 24.06.2003) показывают, что движение в сторону торможения Pentium 4 с помощью MMX-кода началось уже довольно давно — почти полгода назад. А вот Nic's build 16.07.2003 ведет себя как и положено нормальной, честной программе: без MMX — хуже, с MMX — лучше.
Общие выводы
Они будут краткими:
- Использование дополнительных наборов инструкций само по себе отнюдь не является гарантией ускорения работы приложения. В умелых руках :) этот же способ оптимизации может превратиться в замечательный инструмент для достижения обратного эффекта. Причем иногда еще и не на всех CPU, а только на некоторых: определенных процессорных архитектур (что намного труднее отследить).
- Автоматические параметры оптимизации, выставляемые кодеком XviD версии 1.0 beta 2 (Koepi build), являются убийственными для процессоров Pentium 4 с точки зрения быстродействия. Всем пользователям с системами на базе этого CPU категорически рекомендуется выставлять параметры оптимизации вручную, запрещая использование MMX.
- Несмотря на это, последний билд XviD от Koepi все-таки является наилучшим выбором с точки зрения скорости кодирования, причем даже для владельцев компьютеров на базе Pentium 4. Но только после ручной настройки!
- Гигантский проигрыш Pentium 4 при кодировании XviD, замеченный в недавно вышедшей статье, на самом деле не является столь уж гигантским, и составляет не 100%, а гораздо более скромные 32%. Тоже немало, конечно, но все же не так фатально.
- В борьбе мегагерцев с корявыми руками программистов (или билдеров? впрочем — нам-то какая разница?), победа всегда остается за программистами. Ну а в проигрыше, как обычно — рядовые пользователи. Которые (вот ведь незадача!) не могут себе позволить потратить пару суток на выискивание глюков в очередной бете.
На этой оптимистической ноте, пожалуй, и закончим.
