Тестирование
Для тестирования я решил использовать кусок DVD диска . Т.е. создал проект, продолжительностью меньше минуты, в которую поместил наиболее употребляемые переходы и эффекты.

Исходником является Mpeg2 файл. В таком виде решил произвести следующие тесты.
Зависимость времени рендеринга в разные форматы от частоты процессора
На данном этапе я кодирую поочередно в DV, Mpeg2 и WMV форматы, причем DV идет как Interlace, так и прогрессив. Каждый тест проводится для вариантов процессоров 2400(133х18) МГц, 2666(133х20) МГц, 2800 Мгц, 3066(133х23)МГц и 3630МГц (165х22). Последний вариант - это режим разгона по шине, который выдерживает мой компьютер без ущерба для стабильности.
В настройках системы стоит однопроцессорное ядро, т.е. тестируется вариант, если бы у нас был только один процессор. В качестве настроек, выбирались стандартные профили для кодирования.
| Профиль \ Частота процессора |
3.63 ГГц |
3.06 ГГц |
2.8 ГГц |
2.66 ГГц |
2.40 ГГц |
| Рендеринг в PAL DV Interlace |
5:32 |
6:37 |
7:02 |
7:25 |
8:07 |
| Рендеринг в PAL DV Progressive |
3:05 |
3:37 |
3:54 |
4:11 |
4:34 |
| Рендеринг в DVD PAL Progressive |
3:21 |
4:01 |
4:16 |
4:31 |
4:57 |
| Рендеринг в WMV |
4:59 |
5:56 |
6:30 |
6:54 |
7:23 |

На графиках видно как уменьшается время рендеринга в зависимости от увеличения частоты процессора. В текущей конфигурации даже если процессор будет около 4ГГц, время рендеринга Mpeg2 в случшем случае выйдет за отметку не более 3 минут, при условии отсутствия тормозов в видео жесткого диска или других. Дальнейшее увеличение частоты процессора не даст революционных изменений, разве что частота увеличится в 2-3 раза. Или произведите в уме расчет, если вычесть, к примеру из цены Intel Xeon 3.6 ГГц, цену Intel Xeon 3.6 ГГц.(сделайте это сами в качестве домашнего задания). Для владельцев обычных Intel Pentium 4, будут похожие результаты по зависимости.
Зависимость времени рендеринга в разные форматы от частоты шины
Увеличивает частоту шины с 133 до 166МГц, одноврменно уменьшая множитель, чтобы получить 3ГГц. Сравниваем время рендеринга 3ГГц процессора с шиной 133 и с шиной 165 МГц, меняя множитель.
| Профиль \ Частота процессора (шины) |
3.06(133) ГГц |
2.97(165) ГГц |
| Рендеринг в PAL DV Interlace |
6:33 |
6:37 |
| Рендеринг в PAL DV Progressive |
3:42 |
3:37 |
| Рендеринг в DVD PAL Progressive |
4:00 |
4:01 |
| Рендеринг в WMV |
5:57 |
5:56 |
В таблице видно, что разница во времени рендеринга находится в пределах погрешности, а значит в данном случае такого вида разгон нам не поможет, поднимать нужно частоту процессора.
Зависимость времени рендеринга в разные форматы от количества процессоров, исходник Mpeg2
Самый интересный тест, который является одним из важных для понимания, даст ли мне прирост второй процессор при выполнении моих задач или не даст.
| Профиль \ Кол-во процессоров |
One CPU w/o HT |
Dual CPU w/o HT |
Dual CPU with HT |
| Рендеринг в PAL DV Interlace |
6:37 |
6:19 |
6:28 |
| Рендеринг в PAL DV Progressive |
3:37 |
3:30 |
3:33 |
| Рендеринг в DVD PAL Progressive |
4:01 |
3:36 |
3:39 |
| Рендеринг в WMV |
5:56 |
4:41 |
4:55 |

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

Увеличение производительности от использования нескольких процессоров небольшой, ровно такой, как должен быть у неоптимизированной программы для SMP, о чем свидетелствуют графики загрузки процессоров. Вот такой эффект дают пресловутые 5-8% дополнительной мощности от двух процессоров по сравнению с одним.
Зависимость времени рендеринга в разные форматы от количества процессоров, исходник DV
Предыдущий тест дал понять, что добавив второй камень не всегда можно сократить время рендеринга процессора не то чтобы в 2 раза, а хотя бы на 20-30%. Но рано было падать духом, захотелось продолжить эксперименты и я решил заменить исходник на PAL DV.
В конце концов, приходится работать не только с Mpeg2 исходниками, да и мало кто с ними вообще работает, зато с DV работают все, кто монтируют собственное любительское видео и я тоже вхожу в число этих людей.
Поэтому я взял обычный материал в DV камеры и сделал простенький проект. Один кусок видео, порезан на 3 части, соединенные двумя плавными переходами.

Выполняем рендеринг в PAL DV, т.е. просчитываем переходы, выполняем рендеринг в Mpeg2, т.е. просчитываем проект сразу в Mpeg2 и еще кодируем , предварительно просчитанный DV в первом тесте в Mpeg2, но в последнем случае происходит только кодирование DV в Mpeg2, без применения эффектов, т.е. тестим сам кодер от Mainconcept при работе с DV материалом.
| Кол-во процессоров \ Профиль |
Рендеринг в PAL DV Interlace |
Кодирование PAL DV в Mpeg2 |
Рендеринг PAL DV в Mpeg2 |
| Dual CPU with HT |
0:35 |
0:48 |
1:48 |
| Dual CPU w/o HT |
0:39 |
0:56 |
1:59 |
| One CPU w/o HT |
0:42 |
1:31 |
3:08 |

Результаты получились весьма интересные, учитывая тот факт, что загрузка процессоров достигала 90% при всех трех тестах.

Первый тест имеет небольшой прирост и зависит в основном не от работы процессоров, а от скорости жестких дисков исходного материала и куда пишется результат. Но загрузка обоих процессоров и прирост скорости присутствует.
Второй и третий тесты с кодированием, сильнее грузят процессоры и тут виден реальный прирост от работы 2х и 4х процессоров. Т.е. технология HT реально работает при кодировании в Mpeg2, в случае если у нас в качестве исходного материала используется DV.
На графике загрузки процессора, который относится к рендерингу в Mpeg2 видно небольшой провал в начале графика первого процессора. (В этом тесте HT был отключен, т.е. у нас работают рельно 2 процессора.) Этот провал произошел в момент, когда просчитывался очередной переход между фрагментами файла.
Попробуем определить причину такого провала. Без анализа графиков загрузки это сложно, а графики я пока не строил, но сделаю такое допущение, что в момент перехода, который представляет собой процедуру, когда программа считывает поочередно 2 куска одного и того же файла в разных местах, происходит падение производительности жесткого диска и один из процессоров, (а иногда и 2) оказывается недогруженным. Отсюда провал на груфике и реальное падение скорости рендеринга.
Влияние размещения файлов на жестком диске на время кодирования
Совершенно обычное явление, когда вы производите захват видео с DV кассеты на жесткий диск в виде одного куска или нарезанием на сцены, не важно, потом все это переносится в проект в Вегасе и начинается процесс удаления всего лишнего. В результате остается набор сцен, связанных между собой переходами, а физически они как были, так и есть - куски одного файла лежащие на одном жестком диске.
Начинается рендеринг, доходит дело до места, где нужно аккуратно наложить один край сцены на другой и тогда начинается веселье для вегаса. Он одновременно читает один файл на одном жестком диске в разных местах. Это сразу отражается на производительности и времени рендеринга проекта.
Для проверки, можно провести такой опыт. Берем DV файл открываем в вегасе и создаем проект такого типа (А).

Рендерим этот проект в DV и в моем случае получим время 1:14.
Берем две копии первого DV файла, размещаем их на двух разных жестких дисках, создаем проект такого типа(В).

Рендерим проект типа В и получаем время всего 0:43. Т.е. потери на переходы составили 31 секунду, что почти сопоставимо с временем рендеринга варианта В.
Мне стало интересно, с какой скоростью просчитался бы проект будь он вообще без переходов. Убрал все переходы, получилось 0:18, т.е. тут у нас прямая зависимость от скорости жесткого диска.
Я пока не готов делать комплексные выводы по этому тесту, но в целом, тенденция видна хорошо. Жесткий диск, а точнее его скорость и время поиска, являются такими же важными составляющими формулы времени суммарного рендеринга видеофайлов, как и процессор. От неспособности диска дать вовремя кусок файла для просчета, процессор, каким бы он не был мощным, будет простаивать и файл будет просчитываться дольше, чем если бы у нас был более быстрый жесткий диск.
Выводы
Основной темой тестирования было выяснение вопроса, оправдана ли трата денег на второй процессор для задач видеомонтажа, в частности в Vegas Video 5. Однозначно ответить на этот вопрос не представляется возможным потому что, в одних операциях прирост не более 5-9%, в других чуть меньше чем в два раза. Кроме этого, время рендеринга, которое я пытался сократить, зависит от многих параметров, кроме процессора и комбинации этих параметров дают разные результаты.
В любом случае, второй процессор позволяет запустить одновременно вторую задачу, например кодирование звука в AC3 и тем самым сократить общее время рендеринга проекта в целом. При этом , на машине можно комфортно работать , открыв второе или третье окно Вегаса, в то время, как в фоновом режиме будет происходить просчет другого проекта.
Получается, что второй процессор прибавляет мощности, которая не всегда может быть реализована в скорости на одном приложении, но всегда может быть использована другими задачами.
Поэтому следующие тесты будут посвящены теме оптимизации проектов под использование в двухпроцессорной конфигурации и оптимизация железа под использование в задачах видеомонтажа и кодирования.
oLGol
(09.03.2005)
|