Оптимизация. Как еще улучшить внутренние циклы? Масштабирование CSR-спрайтов (13 стр)
Страницы:
1 …
12 13 14 15 16 Следующая »
samrrr
>Ничё не знаю, моя игра на плюсах спокойно 60 фпс играла на том-же ноуте.
Поздравляю. Но на свой ноут много тратить не желаю. Видео на всех ядрах без тормозов и онлайн игру с тормозами тянет, с него и хватит.
>Угу только вот по дефолту они настроены через жопу и постоянно что-то отваливается и неработает. Хоба и сеть накрылась вообще без причин. Начал копать и оказалось что это баг ещё 10 летней давности и никто его и не собирается фиксить. И примерно тоже самое с другими вещами "замечательного" линукса.
А в винде вообще вместо настроек шишь без масла. Старые баги там также исправляют - только те, которые волнуют граждан в жёлтых штанах. Зато анальный зонд всё толще и толще.
>Если ты лубишь по часу в день копаться в оси и пытаться её починить то тебе норм.
Всё что надо было починить, починено давно. В следующий раз чинить и настраивать придётся после апгрейда железа. Сейчас же чинить приходится винду в ноуте. Она такая тупая, что при старте не умеет полечить ошибки на нтфс дисках, потому часто приходится грузить бубунту и запускать диспетчер разделов КДЕ чтобы полечить все нтфс разделы. Лечит он быстро, что и на каком разделе исправляет, по логам так и не понял, влом полчаса его изучать, винда после этого грузится, но однажды процедуру приходится повторять.
>Ты вообще понимаешь, что установки в линуксе идут через компил сорцов с помощью гцц?
Это ты не понимаешь, что кроме гентообразных дистрибутивов, есть дистрибутивы с пакетами, в которых компилировать нужно лишь недостающее и если хочешь пропатчить. А через какое-то время почти ничего нового в линукс через гцц невозможно установить пока не поменяешь обновлениями почти весь линукс - тупо версии будут не совпадать.
>Впервые вижу чтобы кто-то хвастался тем, что либа это целиковый кусок.
Это же замечательно с точки зрения производительности и удобства применения - базовые функции поддерживают максимум базовых типов переменных. А для уменьшения веса бинаря есть умная линковка, которая шинкует скомпиленный код на мелкие кусочки, выбирает нужные и потом линкует - те самые опции -XX -CX в fpc. Время компиляции они удлиняют на копейки. Если кому-то это потом мешает понимать чужую дизасемблированную программу, то это его личные проблемы, у авторов же исходники есть.
>Это тот бенчмарк где кто-то спецом отрубил оптимизацию плюсов? Ты вообще вкурсе как делать бенчмарки?
Это не оптимизация, а лохонизация. В паскале тоже оптимизация было на включена. Цикл выполнялся миллиард раз специально чтобы можно было заметить разницу в производительности просто посмотрев на часы или запустив обе программы разом. Весь миллиард выполнений задуман по сценарию. Если бы нужно было схимичить, то и в паскале мог написать вот такой цикл:
i:=1000000000;
for i:=i to 1000000000 do бла-бла-бла;
А если тебе так нужна эта опция оптимизации, то для подсчёта реальной скорости в код пришлось бы добавить лажу, которая не дала бы ей сработать - компилятор просто не смог бы угадать какие витки цикла понадобятся в будущем. А без этой лажи подсчёт скорости работает более чисто. В том хелловорде оптимизация лишь исправляет то, что компилятор считает невнимательностью программиста, а там невнимательности нет, потому это уже порча кода.
>Я я бы не отказался, хоть прямо сейчас) Только вот пускать русских не хотят.
А кто-то хотел бы на большую землю, вот только тоже не очень пускают и с голой жопой под мостом сидеть не интересно.
#181 (Правка: 9:20)
8:57, 2 окт 2022
Ну у вас тут и дискуссия).
Вынес все циклы в функции избавился полностью от даблов. Из оставшихся оптимизаций это замена div на обращение к precalculated таблице, но после все предыдущих оптимизаций, можно будет выиграть всего лишь 10 миллисекунд).
Еще одна серьезная оптимизация может снять, по моим расчетам, еще 30-40 секунд, но это нужно уже через ассемблерные вставки векторизировать надо те выражения, о которых упоминал ранее, в посте #52. Заменял даже такие куски на процедуры, как советовал invis, но потеря производительности на 10 мс. в лучшем случае, так что решил просто захардкодить.
В итоге удалось сократить время с 404 миллисекунд до 253, то есть почти в 1.6 раз, что уже довольно таки неплохо в поставленных задачей рамках:
Кто там говорил, что нужно полагаться на компилятор, а ручная оптимизация ничего не решает? И это еще без ассемблера!
Ну и получившийся код несколько "сократился":
+ Показать
− Скрыть
procedure TFastImageProc.FilNTColorScaleDownMip3; {$ifdef Linux}[local];{$endif} {$region -fold}
var
nt_pix_intr_cnt_arr_ptr : PInteger;
nt_pix_intr_sht_arr_ptr : PInteger;
nt_pix_intr_ccl_arr_ptr : PInteger;
bmp_bkgnd_ptr2 : PInteger;
scl_mul_x , scl_mul_y,d1_,d2_,x,y,v1,v2,v2_,v3,r1,s1_,s0_mul_2_div_alpha,bmp_ftimg_left_ : integer;
_scl_mul_x ,_scl_mul_y,d1 ,d2 ,alpha,g1,g2,px,py ,s0,k1,k2,alpha_sqr,bmp_ftimg_top_,sqr_mul: integer;
sqr_mul_0_1, sqr_mul_0_5 : double;
const
mul : integer=1<<15;
begin
with fast_image_data_ptr0^ do
begin
sqr_mul := mul* mul;
sqr_mul_0_1 :=0000000.1* sqr_mul;
sqr_mul_0_5 :=0000000.5* sqr_mul;
_scl_mul_x :=Trunc(mul* scl_mul.x);
_scl_mul_y :=Trunc(mul* scl_mul.y);
bmp_ftimg_left_ := mul* bmp_ftimg_left;
bmp_ftimg_top_ := mul* bmp_ftimg_top ;
d1 := (mul- _scl_mul_x)*bmp_ftimg_left;
d2 := (mul- _scl_mul_y)*bmp_ftimg_top ;
d1_ :=Trunc(65536*( d1/mul));
d2_ :=Trunc(65536*( d2/mul));
scl_mul_x :=Trunc(65536*(_scl_mul_x/mul));
scl_mul_y :=Trunc(65536*(_scl_mul_y/mul));
r1 := scl_mul_x* ( bmp_ftimg_left)+d1_;
v3 := scl_mul_y* (nt_pix_arr_row_mrg_top+bmp_ftimg_top )+d2_;
g2 := _scl_mul_y* nt_pix_arr_row_mrg_top+bmp_ftimg_top_;
bmp_bkgnd_ptr :=Unaligned(@bmp_bkgnd_ptr [0000000000000000000000]);
nt_pix_intr_cnt_arr_ptr:=Unaligned(@nt_pix_intr_cnt_arr[nt_pix_arr_row_mrg_top]);
nt_pix_intr_sht_arr_ptr:=Unaligned(@nt_pix_intr_sht_arr[0000000000000000000000]);
nt_pix_intr_ccl_arr_ptr:=Unaligned( nt_pix_intr_arr_ptr);
alpha :=Trunc(mul*Exp(((_scl_mul_x+_scl_mul_y)/(mul<<1))*LN_0_95));
alpha_sqr :=alpha*alpha;
for y:=0 to bmp_ftimg_height-nt_pix_arr_row_mrg_top-nt_pix_arr_row_mrg_btm-1 do
begin
v2 :=v3>>16;
v2_ :=v2*bmp_bkgnd_width;
for x:=0 to nt_pix_intr_cnt_arr_ptr^-1 do
begin
v1 :=(scl_mul_x*nt_pix_intr_sht_arr_ptr^+r1)>>16;
g1 :=_scl_mul_x*nt_pix_intr_sht_arr_ptr^+bmp_ftimg_left_;
px :=(Min2(v1<<15+mul,g1+_scl_mul_x)-Max2(v1<<15,g1));
py :=(Min2(v2<<15+mul,g2+_scl_mul_y)-Max2(v2<<15,g2));
s0 := px*py;
k1 :=alpha*px ;
k2 :=alpha* py;
bmp_bkgnd_ptr2 :=bmp_bkgnd_ptr+v1+v2_;
s0_mul_2_div_alpha :=(s0<<1) div alpha;
if (s0>sqr_mul_0_1) then
begin
(bmp_bkgnd_ptr2+00000000000000000)^:=(PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.r+(s0_mul_2_div_alpha*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.r-PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.r))>>16)<<00+
(PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.g+(s0_mul_2_div_alpha*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.g-PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.g))>>16)<<08+
(PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.b+(s0_mul_2_div_alpha*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.b-PRGBA(bmp_bkgnd_ptr2+00000000000000000)^.b))>>16)<<16;
end;
if (k2-s0>sqr_mul_0_1) then
begin
s1_ :=py<<1-s0_mul_2_div_alpha;
(bmp_bkgnd_ptr2+000000000000000+1)^:=(PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.r+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.r-PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.r))>>16)<<00+
(PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.g+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.g-PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.g))>>16)<<08+
(PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.b+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.b-PRGBA(bmp_bkgnd_ptr2+000000000000000+1)^.b))>>16)<<16;
end;
if (k1-s0>sqr_mul_0_5) then
begin
s1_ :=px<<1-s0_mul_2_div_alpha;
(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^:=(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.r+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.r-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.r))>>16)<<00+
(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.g+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.g-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.g))>>16)<<08+
(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.b+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.b-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^.b))>>16)<<16;
end
else
(bmp_bkgnd_ptr2+bmp_bkgnd_width+0)^:=nt_pix_intr_ccl_arr_ptr^;
if (alpha_sqr-k1-k2+s0>sqr_mul_0_5) then
begin
s1_ :=(alpha-px-py)<<1+s0_mul_2_div_alpha;
(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^:=(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.r+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.r-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.r))>>16)<<00+
(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.g+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.g-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.g))>>16)<<08+
(PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.b+(s1_*(PRGBA(nt_pix_intr_ccl_arr_ptr)^.b-PRGBA(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^.b))>>16)<<16;
end
else
(bmp_bkgnd_ptr2+bmp_bkgnd_width+1)^:=nt_pix_intr_ccl_arr_ptr^;
Inc (nt_pix_intr_sht_arr_ptr);
Inc (nt_pix_intr_ccl_arr_ptr);
end;
Inc (nt_pix_intr_cnt_arr_ptr);
Inc(v3, scl_mul_y);
Inc(g2,_scl_mul_y);
end;
end;
end; {$endregion}
procedure TFastImageProc.FilNTColorScaleDownMAll; {$ifdef Linux}[local];{$endif} {$region -fold}
label
l1;
begin
with fast_image_data_ptr0^ do
begin
if (scl_mul.x<0.15) and (scl_mul.y<0.15) then
FilNTColorScaleDownMip0
else
if ((scl_mul.x<0.2) and
(scl_mul.y<0.2)) or
((scl_mul.x>0.5-0.01) and
(scl_mul.x<0.5+0.01) and
(scl_mul.y>0.5-0.01) and
(scl_mul.y<0.5+0.01)) or
((scl_mul.x>0.5-0.01) and
(scl_mul.x<0.5+0.01) and
(scl_mul.y>1.0-0.01) and
(scl_mul.y<1.0+0.01)) then
begin
l1:
FilNTColorScaleDownMip1;
Exit;
end
else
if (scl_mul.x<0.25) and
(scl_mul.y<0.25) then
FilNTColorScaleDownMip2
else
if (scl_mul.x<0.75) and
(scl_mul.y<0.75) then
FilNTColorScaleDownMip3
else
if (scl_mul.x<1.00) or
(scl_mul.y<1.00) then
goto l1;
end;
end; {$endregion}
Всем спасибо за помощь!
P.S. Это еще без клиппинга кстати. С ним простыни кода будут более монструозными, но оно того стоит, так как идет проверка не всех пикселей, а только начала и конца скан линии.
ArtProg
> 0.5-0.01
повторюсь, компилятор FPC вернее всего не преобразует такие данные и они будут каждый раз вычисляться.
Mirrel, ага, забью в константы тогда. Спасибо за заметку!
P.S. Теперь еще осталось подождать, когда добавят в Лазарус SIMD-интринсики).
ArtProg,
+ часть из того что не оптимизировано.
но на самом деле больше. Позже я ещё много чего нашёл.
Mirrel, спасибо за видео! А есть еще, что то на тему SIMD-векторизаций в Лазарусе?
Mirrel>Позже я ещё много чего нашёл
Хоть и не настаиваю, но если будет время, было бы неплохо, если бы Вы рассказали об этом немного подробнее.
P.S. Можете еще накидать ссылок по SIMD оптимизациям?
(Если будет, что-то по векторизации в Лазарусе, то будет вобще круто).
P.S.2.Теперь надо бы и отдохнуть как следует. Так что, если долго не буду отвечать, то либо вижу десятый сон, либо занялся очередной оптимизацией).
ArtProg
форум 1
форум 2
а вообще, просто по поиску сделай на форуме Lazarus, там немало поднималось тем.
Skvoznjak
> запустив обе программы разом
Ясно, всё понял, ты живёшь в мире своих иллюзий и необучаемый. Продолжать с тобой диалог бессмысленно.
ArtProg
> В итоге удалось сократить время с 404 миллисекунд до 253, то есть почти в 1.6
> раз,
Лучшеб опенжл изучил, проще, быстрее и рендерит он треугольнички быстрее.
ArtProg
> Можете еще накидать ссылок по SIMD оптимизациям?
Я уже кидал, если рейтрейсер сам по себе не интересен, см. начало разделов 2 и 3:
https://habr.com/ru/post/685228/
В FPC пытались сделать некое подобие векторных расширений:
http://forum.lazarus.freepascal.org/index.php?topic=32741.0
Но когда я пробовал пару лет назад, оно работало только на элементарных примерах вроде a=b+c, на более сложных падало.
В FPC с бэкэндом LLVM (а также в Oxygene) должна работать автовекторизация.
Но конкретно спрайты рисовать и правда проще через OpenGL. Всякие доп. операции типа поворота/масштабирования/блендинга/сглаживания, которые на CPU нужно отдельно прикручивать, там практически бесплатны. И абсолютно пофиг, на Паскале или Си написано.
samrrr
>Ясно, всё понял, ты живёшь в мире своих иллюзий и необучаемый. Продолжать с тобой диалог бессмысленно.
У тебя плюсы мозг съели и на парсер большого текста мощностей не хватает, увидел понятный фрагмент текста и сделал по нему вывод о значении всего логического массива. Вот потому на плюсах игры и не пишу - не смогу потом нормально мыслить о чём-то кроме написания кода на плюсах, а рабов художников и дизайнеров у меня нет.
>Продолжать с тобой диалог бессмысленно.
Обмануть не получается, проблема.
invis
> Но когда я пробовал пару лет назад, оно работало только на элементарных
> примерах вроде a=b+c
Попробовал сейчас - увы, прогресс там скорее отрицательный, в FPC 3.2.2 даже простой пример работает только так:
https://gcc.godbolt.org/z/vqfKh7er5
А например без const уже не компилируется. Из типов поддерживается только Single/Double c командами SSE.
invis
> которые на CPU нужно отдельно прикручивать
А просто реализовать их так-же как и на видюхе не пробовал?
invis
> прогресс там скорее отрицательный
movq %rdi,%rax
vmovups (%rax),%xmm0
addps (%rsi),%xmm0
vmovups %xmm0,(%rdx)
retчто не так?
samrrr
> А просто реализовать их так-же как и на видюхе не пробовал?
Так я о том и пишу, что нужно ручками реализовывать. А на видюхе уже есть.
Mirrel
> что не так?
Очень легко ломается, легче, чем в предыдущих версиях компилятора. Убрал const при передаче параметров - уже Internal Error.
Если тебе интересно - ты же топишь за могучий Паскаль - попробуй более сложный пример, у меня раньше ломалось именно на более сложном, компилировалось, но в результате AV.
invis
> Так я о том и пишу, что нужно ручками реализовывать. А на видюхе уже есть.
Я тебя огорчу, но на видюхе этого нет, видюха не умеет поворачивать масштабировать итд. Она умеет только рисовать треугольники и вычислять текстурные координаты. Ну есть ещё мипмапы и дд.
