Оптимизация кода

← →
Sha © (2013-08-24 19:51) [200]

> ведь никто ж не ценит твоего времени и не показывает как

Пример чтения четырех пикселей за три операции в приведен [81].
Там же показано, как развернуть цикл и сэкономить на проверках.
В [12] и [119] разжевано кеширование результата функции.
По ходу обсуждения немного разобраны битовые операции.
В [193] в 100й раз повторено, что *ВСЯ* твоя задача решается
за один проход без предварительного копирования, переворотов и т.п.

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

← →
Вова (2013-08-24 21:07) [201]

если цель программы научить кого то чему то, то там в изобилии должны быть комментарии объясняющие процесс. Ибо в 100 раз повторяю я не понимаю что происходит в [81]. Благодаря тем же причинам я не понимаю, что написано в твоем блоге, который я честно пытался читать, потому что там также стены кода в которых можно что либо понять, только если ты итак уже это знал.

имеет смысл учить на языке понятном обучаемому. Так что я выучил то что сумел понять.

← →
Sha © (2013-08-24 21:17) [202]

значит, нам придется поработать над собой )

← →
Вова (2013-08-24 21:18) [203]

равно как и в [119]

> Каждую из них усекаем до старших 4х битов:
> i:=i and $F0F0F0;

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

> Формируем число от 0 до 16*16*16-1 - будущий индекс цвета
> в таблице:
> i:=(i shr 12 and $F) + (i and $F0) + (i shr 12 and $F00);
>

ну тут тоже все понятно ваще...и так далее )

← →
Плохиш © (2013-08-25 00:31) [204]

Зачем оно тебе, это программирование? Тебе всë-равно не интересно.

PS. Вместо обид остановись, успокойся и подумай, что ты хочешь сделать.

← →
Sapersky (2013-08-25 03:26) [205]

> Вова (24.08.13 21:18) [203]

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

Нужно преобразовать один набор цветов в другой с помощью таблицы. Вариант в лоб - создаём таблицу для всех возможных цветов: ColorMap = array [0..255, 0..255, 0..255] of Integer, прописываем в ней результирующие цвета и выполняем простую как мычание операцию:
Color = ColorMap[Color.r, Color.g, Color.b]
Всё работает, но размер таблицы получается 64 мб, как-то многовато.

Далее, наша операция - огрубление цветов, поэтому нам не очень-то нужны тонкие оттенки. Создадим таблицу не для каждого возможного цвета, а с шагом 16, 256 / 16 = 16 значений на канал.
ColorMap = array [0..15, 0..15, 0..15] of Integer.
Соответственно, чтобы выбрать из такой таблицы, цвета нужно делить на 16:
Color = ColorMap[Color.r div 16 , Color.g div 16, Color.b div 16].
Деление на 16 - это на самом деле и есть "взять старшие биты", точнее, "сдвинуть старшие биты на место младших", фактически компилятор заменяет его на shr 4. Можно заменить самостоятельно, вроде так оптимальнее:
Color = ColorMap[Color.r shr 4, Color.g shr 4, Color.b shr 4].

Если оставить всё именно так - о битах можно не думать. И это неплохой вариант, памяти много не жрёт и по скорости гораздо лучше расчёта на лету. Но если оптимизировать до упора, нужно заменить трёхмерный массив на одномерный:
Color = ColorMap[(Color.r div 16) * 16*16 + (Color.g div 16) * 16 + (Color.b div 16)].
и убрать обращения к отдельным компонентам Color, учитывая, что:
Color.r = Color shr 16 and $FF
Color.g = Color shr 8 and $FF
Color.b = Color and $FF
Подробно мне расписывать не очень хочется, но в общем, в результате всех подстановок и упрощений мы должны получить строчку из [175]. У Sha ещё чуть заковыристее, но принцип тот же.

Вот для этого последнего уровня оптимизации и нужно понимание битовых операций. А так, таблица она и есть таблица, с какими заклинаниями её ни вызывай.

← →
Sapersky (2013-08-25 03:39) [206]

Строго говоря, таблица в первом и втором вариантах не of Integer, а of TRGB из [160], хотя я думаю и так можно сообразить, но кто ж Вову знает...

← →
Sha © (2013-08-25 12:30) [207]

> Sapersky (25.08.13 03:26) [205]

вот, оказывается, где талант педагога скрывается )

← →
Вова (2013-09-02 01:58) [208]

кстати хорошо или плохо если создать много потоков? ну там например 100? )) вообщем дело в том, что когда все делается в основном потоке, то делается это последовательно, и нельзя какое то звено тормознуть, т.к. этим ты тормознешь и тех кто идет следом. В то же время когда это делается в потоке, то процедура выполняется и ставится на паузу - т.е. во втором случае во первых никто не ждет пока процесс себя выполнит, т.к. он сам обновляет результат с необходимой переодичностью, во вторых процессор не шарашит как оголделый по 20 раз одно итоже и следовательно меньше нагружается. Я б даже сказал по опыту разница загрузки проца огромна. Хотя с другой стороны цикл основного процесса все равно будет носится и грузить проц. А во вторых в одно время выполняется только одна из веток программы, т.е. часть процедур может минут по 20 не использоваться, а если они в потоке будут крутиться, то постоянно, т.к. нужны они становятся по событию, а не по таймеру. вообщем сколько потоков юзать оптимально? особенно учитывая, что желательный режим работы на одном ядре (виртуальном) процессора?

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

1. А что в книжках про это пишут?
2. Новые обсуждения лучше затевать в новых ветках.
3. А про коней в вакууме лучше в разделе "Прочее"

> забоялся делать много потоков (таки может и зря?) и только
> несколько процессов туда поместил

Осторожнее с понятиями: таки слово процесс уже зарезервировано для обозначения кой-чего другого, чем кусок кода, и в том значении как раз несколько потоков в процессе, а не наоборот :)

Оптимизация кода Найти похожие ветки