Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Sep 21, 2019 6:49 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 78 posts ]  Go to page Previous 1 2 3 4 5 6 Next
Author Message
 Post subject: Re: Flood-it! fv2.3
PostPosted: Wed Oct 19, 2011 1:33 am 
Leency wrote:
как узнать размер стека я не знаю, но он ведь всегда равен 100, или нет?

Шедевр! Я даже под стол валиться не буду, так в подвал загляну.


Top
   
 Post subject: Re: Flood-it! fv2.3
PostPosted: Wed Oct 19, 2011 2:05 am 
Offline

Joined: Sat Aug 13, 2011 1:48 pm
Posts: 49
Leency wrote:
а) как узнать размер стека я не знаю, но он ведь всегда равен 100, или нет? Заменил CreateThread(#help,#stak); на CreateThread(#help,#stak+100); ничего не изменилось. Всё работает и я решил оставить как было раньше. Тут пусть lev разбирается, он круче))

Ну размера стека будет таким, какой тебе нужен :) А то, что ничего не изменилось, это только на первый взгляд. Ведь по идее в случае CreateThread(#help,#stak) обращение к стеку будет портить данные, которые находятся перед stak, а сам stak вообще никак не будет использоваться. В данном случае перед stak расположен буфер proc_info Form, старшие (1024-72) байт которого никак не используются, поэтому никаких ошибок не возникает. Но ничто не мешает компилятору расместить неиницализированный stak в каком-нибудь другом месте (например, в конце исполнимого кода программы), тогда оба потока могут дать дуба.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Wed Oct 19, 2011 2:16 am 
Про то что указатель надо ставить в конец области, а не в начало, я уже в чате писал - но зачем обращать внимание на комментарии какого-то хуя с горы. "Нам" ЯВУшникам море по колено.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 9:02 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
IgorA wrote:
Code:
rand_x dd 0

align 4
rand_next:
;x(k+1) = (a*x(k)+c) mod m
; a=22695477, c=1, m=2^32
push eax
        mov eax,dword[rand_x]
        imul eax,22695477
        inc eax
        mov dword[rand_x],eax
pop eax
        ret


Это есть плохо. Код
Code:
        push eax
        mov eax,dword[rand_x]
        imul eax,22695477
        add eax,1
        mov dword[rand_x],eax
        pop eax

Работает (по крайней мере в linux) на 50% быстрее. Если всё это загнать в цикл, то код с inc/dec проиграет сишному коду (с -O3) в скорости в четыре раза. Не знаю как для других, а мне очень интересно писать код на ассемблере и Си, компилировать, и затем сравнивать, что быстрее работает, и изучать, почему.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 7:30 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1620
В смысле, проинлайнить вызов крохотной функции? Естественно, это ускорит жизнь, но раздует код. Или заменить inc на add? На фоне imul это не может дать 50% выигрыша. Если последнее, то наверняка дело в том, что из-за изменения размера плывут все дальнейшие адреса, и какие-то переменные или функции - align 4 для функции недостаточно - становятся выровненными.

_________________
Сделаем мир лучше!


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 9:25 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
inc и dec модифицируют только часть флагов, что создаёт зависимость от всех предыдущих записей в регистр флагов. Поэтому Интел рекомендовала заменять их add и sub.
Quote:
The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence on all previous writes of the flag register. This is especially problematic when these instructions are on the critical path because they are used to change an address for a load on which many other instructions depend.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 9:54 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Serge wrote:
inc и dec модифицируют только часть флагов, что создаёт зависимость от всех предыдущих записей в регистр флагов. Поэтому Интел рекомендовала заменять их add и sub.
Quote:
The INC and DEC instructions modify only a subset of the bits in the flag register. This creates a dependence on all previous writes of the flag register. This is especially problematic when these instructions are on the critical path because they are used to change an address for a load on which many other instructions depend.

Только совсем гремучие чайники могут путаться с флагами inc/dec
Ну еще наверное разработчики х86 из Интела :lol:
А вообще (с железячной точки зрения) inc/dec не только короче, но еще и экологичнее чем add/sub. Потому что при прочих равных условиях меньше вентилей требуется переключать в ALU и в конвейере -- экономьте электроэнергию!

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 10:00 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
CleverMouse wrote:
В смысле, проинлайнить вызов крохотной функции? Естественно, это ускорит жизнь, но раздует код. Или заменить inc на add? На фоне imul это не может дать 50% выигрыша. Если последнее, то наверняка дело в том, что из-за изменения размера плывут все дальнейшие адреса, и какие-то переменные или функции - align 4 для функции недостаточно - становятся выровненными.

Ох, ты права. Дело в выравнивании. Поправил align, скорость из-за этого падала.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 10:20 pm 
Вообще-то я встречал упоминание, что на части процессоров add быстрее чем inc. В компиляторах также почему-то часто встречается замена sub на add, если работа идет с одним из постоянных значений. Например, когда в стеке под хранение локальных переменных место выделяется.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Thu Dec 22, 2011 11:44 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
на суперскалярных процах add может распараллеливаться с некоторыми другими командами, но не со всеми. И в любом случае инкремент счетчика цикла требует ровно 1 такт, что с inc, что с add.

Но все это распараллеливание загибается раком, если ломается кэш. А кэш имеет обыкновение ломаться даже в Колибри. Потому что WinMap сильно раздутый.

Когда весь цикл умещается на одну кэш-страницу - тогда он будет крутиться с максимально возможной скоростью, причем вероятность этого при inc/dec существенно выше, чем с add/sub.

diamond wrote:
Колибри - не только очень быстрая, но еще и очень маленькая ОС


Потому и очень быстрая, что очень маленькая.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Fri Dec 23, 2011 1:30 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Оптимизация по размеру не всегда даёт выигрыш в скорости. Для P4 с его мизерным кешем это может быть критично, а декодер Атлонов например очень любит выравнивание кода на 4 байта в циклах и ветвлениях. Ещё AMD до вторых Феномов не умела рассчитывать esp в цепочках push/pop и
sub esp, ...
mov [esp],
mov [esp+4]
mov [esp+8] работало быстрее нескольких push.
А Интел не любили команду loop. У каждой микроархитектуры свои заморочки.
art_zh
Чайники или нет, но ложные взаимозависимости создают серьёзные проблемы для суперскалярных архитектур. Не случайно Интел и АМД рекомендуют использовать обнуляющие xor reg, reg или sub reg, reg для сброса ложных зависимостей между отдельными частями кода.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Fri Dec 23, 2011 3:03 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Serge wrote:
У каждой микроархитектуры свои заморочки.

И я про то же. Как можно вручную оптимизировать код и сравнивать время выполнения команд, если их суперскалярный микрокод на каждой кривой козе реализован по-своему?

Зато я точно знаю, что dec eax всегда в 5 раз короче, чем sub eax, 1 (про энергопотребление пока замнем для ясности). Поэтому даже если я поставлю выравнивание кода на 4 байта - то всегда выиграю и в размере, и в эффективности кэширования.

Правда, в некоторых (редких!) случаях возможен проигрыш в скорости - не более чем на 1 такт и то при очень удачном распараллеливании регистровых команд. Но что такое 1 такт по сравнению с десятками холостых тактов при промахе кэша?

Выравнивание адресов - да, нужно. Невыравненный адрес - это 1-2 лишних процессорных тактов в кэше, или несколько "длинных" шинных тактов при промахе.


Top
   
 Post subject: Re: Flood-it!
PostPosted: Sun Dec 25, 2011 2:30 pm 
Offline
Just Flooding

Joined: Sat Jan 06, 2007 2:30 pm
Posts: 269
в 5? Иногда в 3, емнип.
Code:
83 c0 01                add    $0x1,%eax
83 c3 01                add    $0x1,%ebx


Top
   
 Post subject: Re: Flood-it!
PostPosted: Sun Dec 25, 2011 3:44 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Да, твоя правда -
Code:
add eax, byte 1

весит только 3 байта.
Так что поправлюсь: inc дает выигрыш при 4-байтовом выравнивании не каждый раз, а только в 50% случаев.
А вероятность вылета с отдельной кэшируемой страницы при этом уменьшается не на 6%, а только на 3%


Top
   
 Post subject: Re: Flood-it!
PostPosted: Mon Oct 07, 2013 4:01 pm 
Offline

Joined: Sat Mar 16, 2013 9:13 am
Posts: 72
Небольшой недочёт. Для начала новой игры нужно жать кнопку, вопрос - зачем? Отрисовали win, подождали 2 сек и вывели новое поле.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 78 posts ]  Go to page Previous 1 2 3 4 5 6 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited