Тестирование
Для тестирования я решил использовать кусок 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)
|