Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Nov 13, 2019 1:04 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 114 posts ]  Go to page Previous 1 2 3 4 58 Next
Author Message
 Post subject:
PostPosted: Wed Apr 12, 2006 3:06 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Довольно интересный результат. Как предположение:
команды inc и dec меняют не все арифметические флажки поэтому процессор не может заранее определить флажки в команде jnz .l1 и вынужден ждать исполнения последенй команды inc.
Процессор максимально может выдавать три инструкции за такт, реально перед jnz .l несколько тактов
теряются впустую. чем длиннее цикл тем меньше должны быть потери


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 4:27 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Бывает оптимизация по скорости, а бывает оптимизация по размеру. Причём во многих случаях имеет смысл именно оптимизация по размеру - ну не всё ли равно, будет некоторый код исполняться 2 мс или 3 мс? Если быстрый вариант занимает 200 байт, а медленный 50?
Во многих программах главный цикл обработки сообщений выглядит примерно так:
Code:
still:
mov eax,10
int 40h
cmp eax,1
jz redraw
cmp eax,2
jz key
cmp eax,3
jz button
jmp still

При том, что могут приходить события только 1,2,3. Вот как стоит писать этот цикл:
Code:
still:
push 10
pop eax
int 40h
dec eax
jz redraw
dec eax
jz key
button:

Первый вариант - 24 байта (если все переходы короткие), второй - 11 байт.
Далее, присутствующий код (пишу по памяти, так что в порядке сравнений могу ошибиться)
Code:
key:
mov eax,2
int 40h
cmp ah,'d'
jz ...
cmp ah,'D'
jz ...
cmp ah,'1'
jz ...
cmp ah,'2'
jz ...
cmp ah,'c'
jz @@clear
cmp ah,'C'
jz @@clear
jmp still
@@clear:

эквивалентен
Code:
key:
mov al,2 ; обратите внимание, что до этой команды eax=0
int 40h
mov al,ah
or al,20h
cmp al,'d'
jz ...
cmp al,'1'
jz ...
cmp al,'2'
jz ...
cmp al,'c'
jnz still
@@clear:

Пояснения. Команда "mov eax,xxxxxxxx" занимает 5 байт; вариант "push xx/pop eax" - 3 байта; "mov al,xx" - 2 байта. Арифметические операции с al/ax/eax имеют форму на байт короче: "cmp ah,'d'" занимает 3 байта, "cmp al,'d'" - 2 байта. Команда "or al,20h" переводит заглавные латинские буквы в маленькие, а цифры оставляет на месте.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 6:16 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
А нужна ли оптимизация по размеру? Понятно, что в 1976 году каждый байт был на вес золота, но через тридцать лет
что нам даст экономия 150 байт?

Медленный код заставляет процессор больше работать, а значит сильнее греться.
Экономьте электричество!


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 8:17 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Serge
Действительно, зачем это нужна оптимизация по размеру? Давайте здесь за счёт лишних 150 байт сэкономим миллисекунду, там за счёт 150 байт ещё миллисекунду... Перейдём на Си, современные компиляторы хорошо всё оптимизируют, с учётом кучи разных тонкостей, а что при этом используется куча кода для системных библиотек - так кого интересуют лишние килобайты?.. И получится вместо KolibriOS сначала BirdOS, потом СтраусОС, потом разрастётся куча проектов, весящих больше винды...
Ну это я конечно утрирую, до такого не дойдёт. Но всё-таки Колибри позиционируется как система, умещающаяся на дискете, так что разница начиная с сотен байт заметна.
Это я не к тому, что не нужно проводить оптимизацию по скорости в ущерб размеру. Нужно! В определённых ситуациях. Например, при реализации математических библиотек или работы с графикой и т.д. Но существуют и ситуации, в которых имеет смысл оптимизировать именно по размеру. Например, вряд ли кто-нибудь заметит, что приложение инициализируется на миллисекунду дольше, а вот 150 байт, сэкономленных на коде инициализации, заметить можно.
<Lrz>
Не рекомендуется использовать bt* с непосредственными операндами: bt можно заменить test, bts на or, btr на and, btc на xor. Это и меньше, и быстрее.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 8:28 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
diamond
А как долго Колибри должна помещаться на дискету? Размер сектора на дискете 512 байт. Сколько файлов из дистрибутива
точно укладываются в 512, 1024, 1536, 2048 и т.д. байт ?


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 8:42 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Мое мнение такое: - там где критично к скорости выполнения кода стоит сделать оптимизацию по скорости выполнения - где участки не критичны к скорости там стоит задуматься о размере. Я думаю что так будет правильнее. А вообще дело каждого как оптимизировать. Вообще было бы не плохо, если сделать статью как не стоит делать т.е. программировать в колибри.
OS Kolibri - не считаю дискеточной ОС. т.к. уже сейчас если поместить все приложения и игрушки которые были портированы или написаны для нее явно не хватит дискеты. Дискеты уходят в прошлое - это факт и с этим ничего не поделаешь.

(забыл сказать, что искользовал для теста 64 инструкции завтра попробую 2048 для наглядности и исключения влияния разных факторов


Top
   
 Post subject:
PostPosted: Wed Apr 12, 2006 8:43 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Дело не в дискете.
Чем меньшим числом команд будет записан алгоритм(естественно до разумного предела),тем меньше вероятность глюка.
Я делаю также как и diamond.Там где нужна оптимизация по скорости - делаю оптимизацию по скорости.А где она не важна - оптимизирую код по размеру(насколько умею).


Top
   
 Post subject:
PostPosted: Thu Apr 13, 2006 12:01 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Оптимизация не обязательно сводится к уменьшению числа команд. Интересно когда команда
mov eax, 3 заменяется на
push 3
pop eax ; команд больше а байт меньше - это оптимизация?

Когда запущено приложение с графикой загрузка процессора возрастает до 100%. В этот момент
медленный код начинает воровать время у всех программ, ведь система многозадачная.

В нынешнем дистрибутиве еще около 200 кБ свободного места. Насколько необходима экономия байтов?


Top
   
 Post subject:
PostPosted: Thu Apr 13, 2006 7:33 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Протестировал на машине CELERON 633 с количеством инструкций в цикле 1024, произвел 10 тестовых запусков по 32 в тесте для команды inc и add. По среднему скорость выполнения команд примерно одинаковая и порой сильно отличается от запуска к запуску. Скорее всего с достаточной точностью не возможно подтвердить какая инструкция быстрее или медленне. Имеет смысл тестить не отдельную команду а реализацию алгоритма и смотреть с какими командами он выполнятся быстрее или медленне. Можно сделать вывод: при оптимизации смотреть в документацию, какие команды выполняются быстрее.


Top
   
 Post subject:
PostPosted: Thu Apr 13, 2006 9:14 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
На время выполнения могут влиять аппаратные прерывания, если они не замаскированы и переключения задач.


Top
   
 Post subject:
PostPosted: Thu Apr 13, 2006 10:23 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Это очень сильно влияет на результаты теста, на сегодня не возможно точно сказать какая команда выполняется быстрее, тестируя скорость выполнения кода в Kolibri.


Top
   
 Post subject:
PostPosted: Thu Apr 13, 2006 11:22 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Можно попробовать замаскировать аппаратные прерывания записав маски в порты 0х21 и 0хА1, если к этим портам можно получить доступ.


Top
   
 Post subject:
PostPosted: Sat Apr 15, 2006 8:39 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Дописал статью, произвел оптимизацию в коде. Доступна по старому адресу http://test-kolibri.narod.ru/d/less1.7z


Top
   
 Post subject:
PostPosted: Sat Apr 15, 2006 3:40 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Молодец!
Полезная статья.
Надо будет её потом на kolibrios.org закачать,если там будет раздел для закачки программ и статей(чтобы потом любой человек мог скачать).


Top
   
 Post subject:
PostPosted: Sun Apr 16, 2006 3:07 pm 
<Lrz>
Пара замечание по статье (надеюсь, я еще не задолбал тебя):
1) Нету подписи - надо либо внизу, либо вверху статьи указывать, кто ты есть и желательно контактные данные.
2) А не проще ли нарисовать рамку методом рисования прямых линий? Мне так кажется это будет быстрей если прикинуть все затраты системы на время в целом. Хотя я могу ошибаться.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 114 posts ]  Go to page Previous 1 2 3 4 58 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