Topic: Оптимизации avisynth

выделено из темы конфиг пк под svp

%username% wrote:

У i5 4 ядра 4 потока - SVP ставит 6 потоков
У i7 4 ядра 8 потоков - SVP ставит 10 потоков

Именно так.

%username% wrote:

Как бы 66% разницы

Разница в потоках, а не выч. ядрах. По этому рост в 20% - это вполне даже неплохо.

%username% wrote:

Владельцы i7 могут замерять потребление памяти в тяжелых случаях? не SD конечно.

Да, есть проблема. Я пока разбираюсь с внутренностями avisynth (как рекомендовал Chainik) и может быть что-то улучшу... а может и нет.

%username% wrote:

Видел я твой 21%, с комментарием with some code optimizations

Это простые оптимизации avisynth: незначительные и не влияющие на относительную расстановку Core i5 vs Core i7 в SVP.

Re: Оптимизации avisynth

yartat
Это простые оптимизации avisynth: незначительные и не влияющие на относительную расстановку Core i5 vs Core i7 в SVP.

Кстати да. Не надо такие результаты в базу данных вносить.
Понятно, что владея навыком компилятора можно элементарно нарисовать любую цифру результата теста.
SVPmark использует вполне конкретные бинарники, одинаковые для всех.

Re: Оптимизации avisynth

Chainik wrote:

Кстати да. Не надо такие результаты в базу данных вносить.
Понятно, что владея навыком компилятора можно элементарно нарисовать любую цифру результата теста.
SVPmark использует вполне конкретные бинарники, одинаковые для всех.

В том то все и дело: я не на уровне протокола обмена в GoogleDoc оптимизировал, а вносил реальные улучшения в код avisynth (mvtools2 пока не трогал, т.к. на CPU+GPU самым тяжким является SAD16x16, которая оптимизирована для текущих процессоров. Вот для процессоров с AVX2 ее можно ускорить - к сожалению AVX инструкции (1-е поколение) не дают никакого прироста, даже наоборот).

Re: Оптимизации avisynth

yartat
Даже если скорость внезапно увеличится вдвое, такой результат в этой конкретной базе не нужен, он не будет адекватен. Это тест железа, а не SPEC, и, как тест железа, подразумевает одинаковость софтовой части.

Re: Оптимизации avisynth

Chainik wrote:

yartat
Даже если скорость внезапно увеличится вдвое, такой результат в этой конкретной базе не нужен, он не будет адекватен. Это тест железа, а не SPEC, и, как тест железа, подразумевает одинаковость софтовой части.

Вы одновременно и правы, и не правы: с одной стороны - да - это тест совтовой части, которая должна быть идентичной для всех платформ, с другой стороны вы произвели оптимизации в самом svpflow, создав разницу в исполнении между mvtools2_svpmark.dll и svpflow1.dll. На разных платформах разница может варьироваться. Таким образом имеем марк, который не отражает реальной производительности svpflow.
Я извиняюсь за свое поведение и удалю (если вы еще не успели) данные о моих замерах. Я их использовал для сохранения данных о тестировании на разных машинах (у меня две рабочие лошадки - дома и на работе) и выбора оптимального решения. Извините если ввел в заблуждение остальных пользователей SVP.

Re: Оптимизации avisynth

yartat
Таким образом имеем марк, который не отражает реальной производительности svpflow.
SVPmark использует реальные "боевые" скрипты и библиотеки от SVP 3.0. Да, он отстал от SVP 3.1, но если развивать SVPmark дальше, то новые результаты тестов будут уже несравнимы с результатами, накопленными за это время.
Ваш опыт ценен для нас и для остальных пользователей SVP, но вот оформить бы Ваши результаты в виде графиков (какая доработка какой прирост дает) и создать бы обсудждение доработок avisynth в этой теме.
Насчет удаления "твикнутых" результатов из общей базы. Я считаю, что правильнее удалить, но обязательно перед этим сохранить для себя и будущих поколений wink В табличном виде. Результаты оптимизаций постить здесь, на форуме. Если опишите что и как оптимизировали и приведете результаты, то наверняка найдутся сочувствующие, благодарные и желающие посоревноваться в оптимизациях товарищи. Это будет на пользу и Вам и нам всем. Будем оптимизировать Avisynth вместе.

А то что происходит сейчас: Вы что-то там подкрутили, какой-то там прирост получили, а общественности ничего не сказали. Результаты в базе по большому счету никому ничего не говорят. Туда очень мало народу заглядывает. В результате все Ваши оптимизации мимо SVP. А ведь есть реальный шанс включить Ваши изменения в очередную версию SVP. Сделать и Вам приятно, и народу дать пользу в виде ускорения работы SVP. wink

Re: Оптимизации avisynth

yartat
В том то все и дело: я не на уровне протокола обмена в GoogleDoc оптимизировал, а вносил реальные улучшения в код avisynth (mvtools2 пока не трогал, т.к. на CPU+GPU самым тяжким является SAD16x16, которая оптимизирована для текущих процессоров.

Оптимизации ....
Chainik некогда , смотрит 3 телевизора и проектор  smile 
Может вам все же посмотреть mvtools2 ?
Дело в том , что при построении кадра используется матрица векторов вполне определенного размера . Матрица целочисленная .
Сегодня свп умеет :
1 Построить пирамиду . Где имеет место быть уровень построения=реальному кадру (0 уровень).
2 Используются все возможные уровни для поиска векторов , т.е. уровень построения деленный на 2 (1 уровень) . Деленный на четыре (2 уровень) и т.д.
3 СВП имеет механизм полу-четверть пиксельного поиска . Что интересно - Chainik уверяет , вычисления всегда целочисленные .

Таким образом можно получить пиксельную точность матрицы векторов , используя полупиксельную точность поиска по вдвое меньшему изображению (1 уровень пирамиды) .
Можно получить пиксельную точность , используя вчетверо меньшее изображение и четвертьпиксельную точность поиска (2 уровень) .
По тому же вчетверо меньшему изображению можно уточнить до полупиксела и получить двухпиксельную точность .

Теперь вывод :

Можно вполне избавиться от построения 1 уровня пирамиды (вдвое меньшие линейные размеры основного изображения)
Тем самым уменьшить нагрузку от поиска в 2-3-4 раза .
И возможно , будет хватать скорости обмена математика-данные . Ибо затраты на поиск векторов на 1  уровне больше затрат на все остальные меньшие уровни вместе взятые .

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

Если что-то непонятно - попробую разъяснить . Но в программировании я уже ничего не смыслю  roll

Re: Оптимизации avisynth

gaunt
Может вам все же посмотреть mvtools2 ?
lol ну хоть кому-то...

попробую разъяснить
это будет крайне интересное зрелище!

9 (edited by gaunt 16-10-2012 15:29:45)

Re: Оптимизации avisynth

Chainik
Мне иногда , вернее всё чаще , кажется ...что тебе доплачивают амд и интел . И почему-то совсем не смешно  sad


Если уже самому не интересно поэкспериментировать , например, с поиском движения в двух последовательных кадрах , поискать зумм или вращение , добавить штраф САД от контраста ....да мало ли чего ещё ...
Не отбивай желание людям . Уверяю , логику происходящую внутри свп , объяснить смогу .

Re: Оптимизации avisynth

gaunt
Уверяю , логику происходящую внутри свп , объяснить смогу

вот и справку бы сделал, полную, исчерпывающую.

11 (edited by gaunt 17-10-2012 12:46:37)

Re: Оптимизации avisynth

%username%
вот и справку бы сделал, полную, исчерпывающую.
Справку к чему ?
Для тех настроек , что выведены в профиль , справка ненужна .
Те настройки , что есть в override нужно менять комплексно .

Даже те , кто числится в бета-тестерах ...не имеют такого кол-ва времени ...чтобы предложить свои настройки . Увы .
Сегодняшнии настройки - это плод железобетонного терпения MAG79 .

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

Re: Оптимизации avisynth

Вот я не понимаю...
Почему нельзя делать собственную сборку Ависинта и МвТулс твикнутую и оптимизированную. И пусть будет отдельный релиз для желающих на свой страх и риск. Без нытья потом что чтото не работает. Реально потестим и посмотрим. А то получается что позиция такова "Мы не будем использовать ваши машины потому что на них тонировка не заводская".

Re: Оптимизации avisynth

LordMerlin
Почему нельзя делать собственную сборку Ависинта

наверное потому что нельзя иметь в системе два разных ависинта
Уже были претензии по поводу версии, а если она будет еще и твикнутая - совсем нехорошо будет.

Re: Оптимизации avisynth

gaunt
Справку к чему ?
Для тех настроек , что выведены в профиль , справка ненужна

нужна, я ни в зуб ногой в них, не говоря про override
И судя по по кол-ву пользователей выставляющих блок 32 и думающих что это круче - таки нужна дважды.

Re: Оптимизации avisynth

%username%
Уже были претензии по поводу версии, а если она будет еще и твикнутая - совсем нехорошо будет.

Все будет прекрасно . Твикать ничего не придется , ибо здесь чистая логика .
В свп поиск векторов и построение разделены . Ничего не мешает применить механизмы масштабирования векторов .
Существенные отличия в поиске 3.0 и 3.1 ...Далеко не факт , что все нововведения приносят реальную пользу .
Именно огромная нагрузка от поиска тормозит развитие свп . Шутка что ли , топовые камни едва справляются . Неговоря уже о проблемах с рендерами , дропами .

Про шаг поиска рассказываю , для тебя лично :
1 Все , что больше шага 16 пикселей - зло для поиска . Невозможно обеспечить нормальную подвижность пирамиды (механизм поиска векторов). В результате невозможно получить максимальную подвижность векторов .
2 Шаг 8 пикселей и меньше - наоборот , имеют излишнюю подвижность . Практически нереально удержать такую картинку "в рамках приличия"
3 Использовать следует блоки (шаг) 16 пикселей . Можно с минимальным перекрытием (14) . С перекрытием (12) - не всегда лучше , ибо само перекрытие блоков вносит ограничения на взаимную подвижность векторов .

Таким образом следует использовать шаг 16,14,12 пикселей . Но для мелких ПАЛ разрешений результирующая картинка , увеличенная до размеров монитора рендером, при таких блоках будет выглядеть недоуплавненной . Решение есть - это кратное увеличение картинки (в 2-3 раза) , или кратное физическому размеру монитора (ресайз до 1080р очень тяжелая нагрузка) .

По радиусу - отдельная песня , в большинстве случаев - на вкус и цвет товарища нет . Сейчас из интерфейса недоступно , но 3 пиксела будет оптимально для блоков 12-14 , 4 пиксела для 16 .

Вопросы у тебя есть ?

Re: Оптимизации avisynth

gaunt

как много словей, вроде русским по белому написано, а не понятно
Хорошая у тебя справка получилась бы  wink

Вопросы у тебя есть ?

по порядку:
- что такое шаг поиска? почему больше 16 - зло?
- что такое пирамида?  ее подвижность?
- что такое перекрытие?
- что такое радиус?
- почему перед знаками препинания ты ставишь пробел?

Re: Оптимизации avisynth

%username%
Видишь как интересно  smile
Меня MAG79 не один год учил , и вместе учились  smile
Конечно , если собрать в кучу картинки , которые сделал MAG79 , и раскоментировать как следует , то может дойдет за пару дней . А может совсем не дойдет - здесь Chainik прав .

Можешь просто принять на веру .
шаг поиска :
1 Входящее изображение режется на кусочки - расстояние между этими кусочками (блоками) и есть ШАГ поиска .
2 На сегодня движение можно искать лишь блоками - никаких шестиугольников , окружностей и т.д. недоступно .
3 Из интерфейса 3.1 доступны блоки (квадратные кусочки) - 8*8  , 16*16 , 32*32 . Размер указан в пикселах изображения .
4 Шаг поиска на сегодня - размер блока и перекрытие этих блоков . Т.е. вовсе не обязательно резать изображение ровно по границам этих блоков (кусочков) , изображение можно порезать с перекрытием этих блоков . Перекрытие - кусочки наползают друг на друга , края этих кусочков общие для соседних блоков (кусочков)
Пример :
шаг 16*16 - это порезанное изображение на блоки 16*16 без перекрытия .
шаг 14*14 - это порезанное изображение на блоки 16*16 с перекрытием 2 пиксела по краям этих блоков .
шаг 12*12 - это порезанное изображение на блоки 16*16 с перекрытием 4 пиксела по краям этих блоков .

И т.д.

Из входящего изображения строится пирамида , которая представляет собой :
1 Основание пирамиды = реальное изображение
2 Каждый следующий этаж(уровень) меньше предыдущего в 2 раза . Т.е. линейные размеры меньше в два раза . По площади высота*ширина=2*2=4 т.е. в каждом следующем этаже пикселей в 4 раза меньше .
3 Основание пирамиды принято за 0 уровень
соответственно уровень выше (меньше) будет 1 уровнем .

Каждый из этих этажей делится на кусочки - блоки .

Поиск движения начинается с самого верхнего этажа , постепенно опускаясь вниз - к уровню построения (0 уровень) .

Дальше нужна наглядность , с этим у меня туго .

Re: Оптимизации avisynth

gaunt
не-не-не
Без картиног нещитово  sad

Re: Оптимизации avisynth

gaunt, зачем ставить пробелы там где не надо и не ставить там где надо?

Re: Оптимизации avisynth

NightFox
gaunt, зачем ставить пробелы там где не надо и не ставить там где надо?
Точно такой же вопрос : зачем тыкать мышью в экранную клаву , когда есть блютуз ?
Ответ - незабываем , мой монитор Пион 50 дюймов , с расстояния примерно 3 метра . Признаюсь честно - точку сразу после буквы вижу плохо . Отдельностоящую хорошо . Или так , или без знаков препинания совсем .
Ещё вопросы есть ?

Re: Оптимизации avisynth

gaunt, а почему же тогда у «т.е.» и «т.д.» ты не ставишь пробелы? Да и не очень понимаю зачем это тебе надо видеть, просто ставишь и всё, или ты не сразу понимаешь где их надо поставить, а где нет? (потом удаляешь лишние). Не очень понимаю логику. Кроме того можно было бы шрифт увеличить и не заморачиваться так.

22 (edited by %username% 19-10-2012 10:42:48)

Re: Оптимизации avisynth

gaunt
А что, CTRL + колесико мышки вверх/вниз уже не меняют масштаб в окне?
Сам так же сижу за плязмой фулкой и как видишь нормально пишу
К тому же у тебя плазма HDR, буквочки должны быть покрупнее

Re: Оптимизации avisynth

%username%NightFox

А что, CTRL + колесико мышки вверх/вниз уже не меняют масштаб в окне?
Хватит флудить , я обхожусь мышкой - ибо прекрасно читаю в родных размерах . При этом особо не напрягаюсь . С ХР шрифтами совсем прекрасно . Но в ХР нет возможности нормально декодировать вс-1 , как нет возможности вернуть декодированное до процессора ....
Т.е. и т.д. не являются знаками препинания , но какой-нибудь деепричастный оборот ....способен перевернуть смысл сказанного с головы на ноги .