Про векторные вычисления ничего не
Про векторные вычисления ничего не могу сказать, таких в нашем мире PC
от Интела нет.
Про обработку изображения можно добавить к сказанному в комментарии на
комментарий следующее:
Давайте спустимся на землю.
Я по молодости считал подобные "эффекты", делая расчеты двумерных и
трехмерных электрических полей с учетом сложной геометрии и
распределения объемных зарядов в пространстве. В некотором смысле это и
был сложный видео эффект. Я имел на экране одну исходную картинку
(граничные условия и распределение объемного заряда - типичная задача в
физике низкотемпературной плазмы), и мне надо было по алгоритму из нее
сделать другую - распределение поля.
Так вот, решение в одной точке зависело от очень многих точек исходной
картинки - плотности заряда, координаты, форма электродов, ... Типичный
случай сложного эффекта в видеомонтаже. Уверяю вас, что сложность
зависимости конечного результата от начальных данных не определяет длину
кода. В моем случае приходилось решать все итерационно, перебирая
"пикселы" и делая над ними вычисления. Размер "картинки" был от 30х30 до
1200х1200 точек. Но, весь код содержал несколько циклов по всем точкам,
в цикле было до полусотни ассемблерных команд. Делалось все на Паскале
7.0 в защищенном режиме, поэтому я мог в "куче" создать такие большие
псевдомассивы. На встроенный ассемблер я перешел только по причине
сильной тормознутости кода на Паскале. Там вообще никакой оптимизации не
делалось. Вся программа оперировала с данными до 20 Мб, а ее код был не
более 40-50 кб и исполняемый код ЦИКЛА заведомо помещался в кэш ПЕРВОГО
уровня. Не надо смешивать количество вычислений (проходов цикла) с
длиной кода. Это очевидно разные вещи.
Если алгоритм общения с кэшем сделан хоть немного разумно, то
последовательный перебор точек одной картинки с целью просчета их
координат и откладывания значений в другой массив работает эффективно и
без кэша второго уровня. Делается просто пакетное чтение из основной
памяти группы байт прямо в кэш первого уровня, поскольку перебор
последовательный, то все работает очень быстро. Я тогда специально
исследовал (3-6 лет назад) влияние кэша и его размера на скорость
счета.
Размер кэша в 386 машине ничего не значил, 64 и 128 к варианты работали
просто одинаково. Выключение кэша все тормозило вдвое, но это и понятно
для 386 DX40.
Размер кэша второго уровня у 486 машин тоже не имел значения. Его
отключение, или использование безкэшевого варианта (ноутбук 486 DX 2 50)
замедляло расчеты на 5-7 %. Отключение кэша первого уровня все сильно
тормозило. Здесь наличие кэша второго уровня сказывалось заметно, потому
что код цикла мог не вполне помещаться в кэш первого уровня из-за его
малой величины.
Лирическое отступление. Забавно, но из моих тогдашних опытов проистекло
следующее наблюдение: если и код и данные программки помещались в кэш
первого уровня, то на ноутбуке происходило следующее. В чистом ДОСЕ, в
обычном real паскале, цикл типа a:=b*c исполнялся быстро только первую
минуту. Затем все тормозилось втрое. Я не мог понять, почему не могу
измерить время исполнения одной команды умножения, написав цикл из
миллиона умножений и повесив сверху измеряющий время пять раз подряд
цикл. После первого прохода все жутко замедлялось. В защищенном режиме,
или в окне ДОС под Win3.1 все работало без тормозов. Если вместо
перемножения одной пары чисел я брал массив >8К (если 4к, то я не
виноват, половина полного размера кэша была) и перебирал его, то эффект
замедления пропадал. Граница сидела около размера кэша данных первого
уровня. Так вот, оказалось, что если весь исполняемый код и данные
находятся внутри кэша первого уровня, то система энергосбережения
ноутбука считала,что он просто ничего полезного не делает и снижала
частоту втрое.
Разницы во времени прохода цикла с большим массивом и с маленьким,
умещавшимся в кэш, в одинаковых protected code условиях я вообще не
заметил. Таким образом, производительность не зависела от того,
уместились все последовательно перебираемые данные в кэш или нет. Все
делалось, разумеется, на плавающей точке, довольно медленно работавшей на
386\486 машинах.
На пентиуме, выключение кэша второго уровня уменьшало скорость на 3%.
Размер этого кэша на скорость не влиял. Размер массива данных тоже.
Процессор просто обрабатывал 4 байта новых данных за большее число
тактов, чем это нужно для их извлечения в выровненном по границам в 4
байт и пакетном режиме.
На пентиуме про я с трудом смог свою старую программку запустить,
спасибо Борланду. Все уже слышали, что паскаль их падает на машинах
быстрее ППРО 180. Если процессор чем-нибудь отвлечь при загрузке кода, то
удавалось программку запустить. Никаких чудес не произошло, а Пентиум2
300 был в полтора раза быстрее, как ему и положено.
Я полагаю, что оба эффекта из примера в комментарии к моей заметке
работают-таки последовательно. Ведь это разные эффекты и написаны
разными кусками кода. Кто-то выполняется раньше. А что, надо много кода
для вычисления координаты точки при повороте? Мне казалось раньше, что
четырех строк хватит. Два десятка ассемблерных команд.
Потом, когда все повернется, можно запустить второй проход по
"облагораживанию" типа antialiasing. Это и программировать и проще
результат выходит предсказуемый. Для antialiasing опять кода надо мало,
только считать много.
А вот теперь и потитровать можно.
Гауссовы преобразования тоже последовательным перебором пикселов с
вычислениями делаются. Ничего особенного в этом случае тоже нет. Хотя
для экстремистских случаев гауссового размытия на всю картинку и
медленно все будет, но точка, из которой добавочки по всем другим
разлетаются - одна, а выходные перебираются последовательно. Опять
конвейер выходит, что для кэша равносильно его непризнанию.
Не вижу я ни одного примера из приведенных, где бы КОД был длинный. Про
данные я уже говорил, если над каждым пикселом надо потрудиться, то
обмен с основной памятью не есть замедляющий фактор.
Декомпрессия. Включается сторонний алгоритм, обычно поставляющий на
выход в память bitmap. Он работает медленнее, чем может память. Размер
исполняемого кода алгоритма декомпрессии/компрессии небольшой. Данные
обрабатываются последовательно, алгоритм вычислений сравнительно
простой, но может быть трудоемким по числу операций. Длина
последовательности команд в цикле почти наверняка небольшая.
Про векторные вычисления написано красиво. Но я в молодости лазеры
бо-о-льшие делал и разрабатывал, не понять мне красоты...
