Теперь небольшое отступление на околопроцессорную тему
Следует сразу заметить, что основные тесты, используемые посетителями данного сайта, не смогут
показать возможностей вашего РС в обработке видео и анимации. Ваш РС может выдавать до 70 fps на
игрушках, но при работе с графикой выдавать 5-10 fps, или часами считать несложный эффект. Тут
нет ничего особенного. Дело в том, что все игрушки, в том числе и c 3D графикой оптимизированы
под команды конкретныx ЦП и видеокарт. Это возможно благодаря тому, что алгоритм игры известен
заранее, так же как и используемые 3D объекты и текстуры. Зная это, программисты оптимизируют
программный код для достижения максимальной производительности ЦП.
Тоже можно сказать и о тестах. Как правило, они включают в себя стандартный набор инструкций,
которые выполняет РС при тестировании. При реальной работе с графикой и видео, заранее
прогнозировать алгоритм работы невозможно, слишком много случайных факторов, определяемых
творческими замыслами человека. Это предопределяет неоптимальное использование возможностей как
ЦП так и системы в целом. Поэтому для достижения хорошей производительности в обработке видео и
анимации, вовсе не надо гнаться за новейшими технологиями, особенно в области игрушек и
прельщаться возможностями "крутых" видеочипов за $100-200.
Как правило, окончательный просчет, в программах 3D графики и анимации, возлагается на центральный
процессор, а не на процессоры видеокарты. Даже при работе на станцияx SGI, позволяющих в реальном
времени манипулировать сложными 3D объектами, окончательный просчет выполняется с использованием
многопроцессорного расчетного суперсервера или нескольких сразу, которые могут и не иметь крутых
видеоакселераторов, зато позволяют пропускать через себя огромные числовые потоки. Это позволяет
получать выходной материал с существенно более высоким качеством, чем обеспечивают видеоакселераторы.
Основное назначение видеоакселератора, это помощь художнику на этапе создания сцены, для возможности
визуального ее восприятия. Поэтому, имея карту, выводящую в играх 70 fps, при работе с 3D
анимацией, вы получите практически тот же результат, что и при использовании менее
"навороченной" карты, дающей 30 fps.
Теперь немного о КЭШ памяти ЦП. Существует мнение, что чем больше КЭШ у ЦП, тем быстрее он
работает. Это верно, но далеко не всегда, особенно в обработке изображений. Рассмотрим типичный
ЦП, содержащий КЭШ команд и КЭШ данных. Максимальной производительности данный ЦП достигнет при
минимальном изменении потока данных и команд при условии, что все данные и команды помещаются в
КЭШе. Данный режим работы, характерен для оптимизированных приложений, например текстовых
процессоров и электронных таблиц.
Действительно, стандартный набор действий, особенно в текстовом процессоре, малый объем
занимаемых данных и невысокая скорость их обновления, позволяют практически обращаться к ОЗУ
компьютера очень редко. Здесь требования к КЭШу минимальны, возможна работа даже без него.
Следующий режим, менее благоприятный, это постоянный набор инструкций и изменяющиеся данные. Этот
режим характерен для СУБД, когда стандартный набор команд (поиск, чтение и др) применяется к
изменяемому потоку данных. Здесь на скорость работы ЦП, уже будет влиять изменение запрашиваемых
данных и тем больше, чем более разные данные необходимы. Соответственно эффективность КЭШа
данных снижается. Здесь оптимально увеличение КЭШа данных по сравнению с КЭШем команд. Обратный
вариант, постоянные данные, переменный поток команд. Данный режим возникает, например, при
обработке картинки разными эффектами. При условии, что картинка помещается в КЭШе, на скорость ЦП
будет влиять изменение потока команд, обрабатывающих данные. Соответственно, чем сложнее эффект,
тем менее эффективен КЭШ команд, поскольку будет тратиться время на пересылку данных из ОЗУ в КЭШ.
Для повышения эффективности необходимо увеличение КЭШа команд. Самый неблагоприятный режим,
изменяемый поток данных и команд. Этот режим характерен для обработки аудио/видео данных и в
программах 3D моделирования и анимации. Действительно, при обработке видео (и анимации) очень
редко подряд идут одинаковые кадры и соответственно неизменяемые данные. Объем одного кадра даже
в разрешении 384х288 при 24 бит/пикс более 300 Кбайт. Таким образом ЦП нужно дважды осуществлять
обмен данными между ОЗУ и КЭШем для ее полной пересылки и обработки.
Учитывая, что даже простейшие эффекты требуют большого числа инструкций ЦП, поскольку обработка
идет на битовом уровне, можно предположить, что КЭШ команд ЦП будет интенсивно обмениваться с ОЗУ.
Может наступить такой момент, когда при большом потоке данных и команд, КЭШ будет тормозить работу
ЦП. Выход из данной ситуации оптимизация КЭШей, причем динамическая. Учитывая, что все ЦП имеют
фиксированный КЭШ данных и команд и потоки данных связанные с обработкой изображений существенно
перекрывают объемы КЭШ, можно сделать вывод о том, что в большинстве случаев объем КЭШа не
существенно влияет на скорость обработки изображений. Большее влияние оказывает скорость
выполнения инструкций самим ЦП, и скорость пересылки по шине ЦП-ОЗУ. Поэтому решающим фактором,
при выборе компьютера для задач обработки изображений, является выбор максимальных значений этих
параметров, которые, как правило, зависят от тактовой частоты и внутренней архитектуры ЦП.
Автору удалось убедится в этом при работе на ЦП iP-150 и AMD K6-200. Так, несмотря на то, что
практически все тесты показывали практически 1,5-2 превосходство АМD, реально ЦП от Intel при
просчете в Premiere 4.2 (без ММХ инструкций) работал на 5%-10% быстрее AMD. Очень неплохо
показали себя процессоры iPPro. Так РС с Ppro-200 256 Кбайт КЭШ при работе с Premiere 4.2
(c ММХ!) практически не уступал, а иногда и превосходил P-II 300. Правда надо заметить, что
использовалась NT 4.0, для которой оптимизирован PPro. Жаль, что Intel отказалась от дальнейшего
развития этой линии, мне кажется что PPro 450 под NT не оставил бы шансов Xeon'у.
Ну вот, вроде и все о чем я хотел рассказать посетителям данного сайта. К сожалению, вполне
возможно, что я что то пропустил, где-то повторялся, а где-то допускал неточности. Заранее прошу
извинить.
Данное направление бурно развивается и сложно проследить все нюансы этой темы. Все дополнения,
полученные по данной статье будут обязательно опубликованы. Более того, возможно будут даны
ответы на наиболее часто задаваемые вопросы. К сожалению, отсутствие известных мне конференций и
сайтов посвещеных данной теме и расчитаных на обычных пользователей, не позволяет оперативно
обмениваться информацией по данному вопросу. Для желающих могу дать свой номер ICQ 6184995 и буду
рад, если где то найдется сайт или конференция по данному вопросу.
