Board.KolibriOS.org

Довольно интересный результат. Как предположение:
команды inc и dec меняют не все арифметические флажки поэтому процессор не может заранее определить флажки в команде jnz .l1 и вынужден ждать исполнения последенй команды inc.
Процессор максимально может выдавать три инструкции за такт, реально перед jnz .l несколько тактов
теряются впустую. чем длиннее цикл тем меньше должны быть потери

Бывает оптимизация по скорости, а бывает оптимизация по размеру. Причём во многих случаях имеет смысл именно оптимизация по размеру - ну не всё ли равно, будет некоторый код исполняться 2 мс или 3 мс? Если быстрый вариант занимает 200 байт, а медленный 50?
Во многих программах главный цикл обработки сообщений выглядит примерно так:

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. Вот как стоит писать этот цикл:

still:
push 10
pop eax
int 40h
dec eax
jz redraw
dec eax
jz key
button:

Первый вариант - 24 байта (если все переходы короткие), второй - 11 байт.
Далее, присутствующий код (пишу по памяти, так что в порядке сравнений могу ошибиться)

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:

эквивалентен

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" переводит заглавные латинские буквы в маленькие, а цифры оставляет на месте.

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

А нужна ли оптимизация по размеру? Понятно, что в 1976 году каждый байт был на вес золота, но через тридцать лет
что нам даст экономия 150 байт?

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

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

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

diamond
А как долго Колибри должна помещаться на дискету? Размер сектора на дискете 512 байт. Сколько файлов из дистрибутива
точно укладываются в 512, 1024, 1536, 2048 и т.д. байт ?

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

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

Дело не в дискете.
Чем меньшим числом команд будет записан алгоритм(естественно до разумного предела),тем меньше вероятность глюка.
Я делаю также как и diamond.Там где нужна оптимизация по скорости - делаю оптимизацию по скорости.А где она не важна - оптимизирую код по размеру(насколько умею).

Оптимизация не обязательно сводится к уменьшению числа команд. Интересно когда команда
mov eax, 3 заменяется на
push 3
pop eax ; команд больше а байт меньше - это оптимизация?

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

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

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

На время выполнения могут влиять аппаратные прерывания, если они не замаскированы и переключения задач.

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

Можно попробовать замаскировать аппаратные прерывания записав маски в порты 0х21 и 0хА1, если к этим портам можно получить доступ.

Дописал статью, произвел оптимизацию в коде. Доступна по старому адресу http://test-kolibri.narod.ru/d/less1.7z

Молодец!
Полезная статья.
Надо будет её потом на kolibrios.org закачать,если там будет раздел для закачки программ и статей(чтобы потом любой человек мог скачать).

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