2013-02-25 2 views
1

У меня есть простой дешевый dualcore intel-3ghz-debian и доступ к сверхдорогой powerPc7-Aix.x264 библиотека скорость - Altivec vs SSE4 -

И через несколько дней strugle, я скомпилирован libx264 и протестировал его на обоих компьютерах:

  1. GCC: библиотека x264 на разведданные (с возможностями SSE2) и
  2. GCC 16 ядра PowerPC (с altivec).

... и результат в том, что дешевый intel является x2 раз быстрее! (с отключенным altivec, интеллект в 10 раз быстрее)

Мой вопрос: это нормально? Имеют ли все остальные пользователи PowerPC одинаковые результаты? Может ли PowerPc-altivec-оптимизация библиотеки x264 работать с такой же скоростью с помощью intel ... или MMX/SSE-оптимизации, официально, по крайней мере, в 2 раза быстрее для этой библиотеки?

Меня не интересуют многопоточные варианты. Количество ядер и нитей не имеет значения. Простое однопотоковое кодирование x264 со стандартным «предварительным предварительным заданием» с использованием rawvideo в качестве источника, sse vs altivec.

Возможно, собственный компилятор Aix XLC обеспечивает лучшие результаты? (мне удалось только gcc работать)

... mac-powerpc-пользователи, возможно, знают об этом.

powrPc7-Aix:$ time (cat raw10sec.y4m |x264 --input-res 720x576 --fps 50 -o /dev/null -) 
x264: 64-bit XCOFF 
x264 [info]: using cpu capabilities: Altivec 
time: real 0m33.559s 
--- 
intelDebian:$ time (cat raw10sec.y4m |x264 --input-res 720x576 --fps 50 -o /dev/null -) 
x264: ELF 32-bit LSB executable 
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64 
time: real 0m16.503s 
+1

КПП не могла идти в ногу с ростом производительности x86, что является одной из причин, по которой Apple отказалась от PPC для x86. Рынок просто не был достаточно большим для PPC, чтобы заплатить за затраты на разработку, необходимые для того, чтобы не отставать от Intel. –

+0

... так что, вероятно, официально, что использование ibm-powerPC для платформы кодирования x264 - плохая идея. –

+0

Не только кодировка x264. Как правило, использование PPC для вычисления интенсивных задач - плохая идея. – hirschhornsalz

ответ

1

Несколько вещей приходит на ум:

  • НКУ, скорее всего, было гораздо более усилия, приложенные в оптимизации x86 (в частности, товар Intel/AMD части) по сравнению с другими архитектурами, возможно, все другие архитектуры в сочетании ,
  • x264 также может потребовать больше усилий для оптимизации x86/SSE.
  • В вашем вопросе говорится SSE2, но x264 говорит, что использует SSE4.1. Там большая разница!
  • MMX/SSE первоначально был нацелен на то, что Intel считала важным, со многими специализированными инструкциями и причудами (например, существуют разные инструкции для плавающих и целых нагрузок, несмотря на то, что они загружают одну и ту же память в «тот же» регистр) , AltiVec кажется намного более ортогональным, но, как результат, может быть менее хорошим в том, что MMX было разработано так, чтобы быть хорошим.
  • Даже если предположить, что AltiVec/SSE в значительной степени эквивалентны, вы не указали тактовую частоту и инструкции на часы.
  • PPC частично дорогой, потому что вы платите за 16 × 4 темы —, что не так уж редко можно упаковать как можно больше на один чип для приложений сервера/HPC. Немного стыдно, что сбор товарных частей часто быстр и дешевле (иногда даже учитывает затраты на электроэнергию на протяжении всей жизни), но так обстоит дело.

Более интересное сравнение было бы против PS3 с кодом оптимизирован, чтобы воспользоваться всеми ядрами —, по-видимому PS3s являются большими в bruteforcing криптографию. К сожалению, они перестали их делать, и я не знаю, как легко запустить Linux в эти дни.

+0

, так как кажется, мой вопрос «это нормально» ... да, это нормально, это не связано с моей компиляционной версией ffmpeg/x264 ... PS3 звучит интересно, я не знал о возможности его использования с линукс. –

+0

Я не согласен с вашим утверждением о том, что AltiVec более ортогонален. Классическим определением CS ортогонального SSE (и вообще x86) является второй, вероятно, только для VAX. –

Смежные вопросы