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

Второй и третий тесты с кодированием, сильнее грузят процессоры и тут виден реальный прирост от работы 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 и тем самым сократить общее время рендеринга проекта в целом. При этом , на машине можно комфортно работать , открыв второе или третье окно Вегаса, в то время, как в фоновом режиме будет происходить просчет другого проекта.

Получается, что второй процессор прибавляет мощности, которая не всегда может быть реализована в скорости на одном приложении, но всегда может быть использована другими задачами.

Поэтому следующие тесты будут посвящены теме оптимизации проектов под использование в двухпроцессорной конфигурации и оптимизация железа под использование в задачах видеомонтажа и кодирования.
  [--pagebreak--]

Опимизация дисковой подсистемы В плане продолжения оптимизации тачки решил не останавливаться на достигнутом и прикинуть, что мне даст дисковый массив 0 уровня, т.е. STRIPE. А то все говорят, что вот сделай этот массив и будет тебе счастье. В пятницу вечером ехал домой с сумочкой, в который лежала пара SATA Hitachi 80Гб (они были в тесте на Fcenter). Там низкое время доступа и высокие скорости, хотя большинство винтов сейчас имеют высокие скорости линейного чтения (60-65 mb/c). Выбор пал на небольшие диски по нескольким причинам. Потому что я не доверяю, в смысле надежности, массиву с чередованием и потому что диски дорогие покупать, тоже не хотелось. Зная себя, купи я 2х200Гб и установи в STRIPE , то обязательно бы забил свободное место, сначала чем-то ненужным, а потом чем-то нужным. Поэтому 2х80Гб - это самое то, что нужно. Первым дело я протестировал при помощи программы Drive и выделил, в процентном соотношении, область с максимальной скоростью. Получилось более 40% диска. Далее я разбил диск на разделы, последние 60% емкости пошли на хранилище объемной, но маловажной информации, место для скидывания образов DVD дисков, для последующей записи и тому подобного. К первым 40% - это около 60Гб я отнесся более трепетно. Первые 10Гб отвел под TEMP диск, куда положил Page File основной операционки, и перенес каталоги Temp и Tmp. Остальные 50Гб отделил под хранение видеофайлов текущих проектов, чтобы обращение к ним происходило быстрее. В отличие от максторов, IBM (а хитачи - этот тот же IBM) всегда имели меньшие параметры потребляемой мощности. поэтому я надеялся, что БП выдержит. Пришлось отрубить SCSI 20Гб винт, т.к. не было свободного места в корпусе для новых винтов. Получилось 2хHitachi 80Гб + 2хMaxtor 200Гб+ еще 2 макстора по 200Гб отдельно. Итого 6 винтов и 3 CD-ROM. Питалово не просело, но все равно я хочу в перспективе купить новый блок питания, ватт эдак на 500-700. Тестирование Для оценки производительности я решил прогнать старый тест по кодированию DV в mpeg2 и в DV сцены с несколькими переходами, когда соединяются часто одного и того же файла друг с другом и когда для работы используются два разных файла и переходы происходят всегда между разными файлами, лежащими на разных дисках. В качестве места размещения видеофайлов проекта выбирал по очереди отдельный диск Maxtor и логический диск массива STRIPE. Разница во времени рендеринга оказалась в пределах погрешности, тут трудятся только процессоры, причем все 4 работают только когда заканчивается обсчет перехода. Средняя загрузка в обычно режиме около 72%, смена винтов не влияет на время рендеринга. Т.е. кодирование DV операция, где достаточно обычной линейной скорости одного современного винта 60 мб/c. Но сильнее всего удручает другое. Просчет переходов при кодировании в DV и Mpeg2 происходит с загрузкой на 100% только одного из 4х процессоров. Т.е. средняя загрузка бывает в диапазоне 25-30%, а это говорит о плохой оптимизации программы Vegas 5 для работы с мультипроцессорными системами и опцией HT на процессорах Intel. Выводы Создание дискового массива 0 уровня дало большой прирост в работе с фотошопом, когда я поместил файл подкачки на диск Temp, так же шустрее стал работать Adobe Audition 1.5, но в случае с Вегасом 5, прирост при рендеринге составил менее 3%. Т.е. прироста никакого, тут все уперлось во что-то другое.