Здравствуйте.
Просмотрел тут программы для KOS и ужаснулся.
Абсолютно неоптимизированный код.
Почти всегда MOV EAX, 00000001 вместо PUSH 1 / POP EAX
и так далее.
Вы ведь можете уменьшить Колибри раза в полтора, если
захотите. Я понимаю, у вас есть паковщик, но все равно
программы станут меньше.
Если нужно, я готов составить файл со списком программ,
где напишу возможные улучшения для каждого вплоть
до номеров строк.
Оптимизация кода
если бы ты внимательнее читал, то мог бы заметить в macros.inc
В общем если интересна оптимизация можешь начать присматриваться с этого файла
Насчёт полтора раза ты помоему перегнул
Code: Select all
macro mov arg1,arg2
{
if (arg1 in __regs) & ((arg2 eqtype 0) | (arg2 eqtype '0'))
if (arg2) = 0
xor arg1,arg1
else if (arg2) = 1
xor arg1,arg1
inc arg1
else if (arg2) = -1
or arg1,-1
else if (arg2) > -128 & (arg2) < 128
push arg2
pop arg1
else
mov arg1,arg2
end if
else
mov arg1,arg2
end if
}
В общем если интересна оптимизация можешь начать присматриваться с этого файла
Насчёт полтора раза ты помоему перегнул
blueboar
Оптимизация бывает разная. Есть по размеру а есть по скорости. Кому как нравится.
Оптимизация бывает разная. Есть по размеру а есть по скорости. Кому как нравится.
blueboar
Ага, есть неоптимальный код. Но есть и код, близкий к оптимальному. В качестве примера посмотри, например, на приложение end.
Насчёт уменьшения раза в полтора - это вряд ли.
Кстати, следует учитывать, что фактически любой файл занимает целое число секторов...
Ага, есть неоптимальный код. Но есть и код, близкий к оптимальному. В качестве примера посмотри, например, на приложение end.
Насчёт уменьшения раза в полтора - это вряд ли.
Кстати, следует учитывать, что фактически любой файл занимает целое число секторов...
Мы будем только рады Единственное, что не стоит оптимизировать по размеру код, критичный по скорости, но такого довольно мало. Если умеешь работать с svn, попроси mike.dld выделить аккаунт в Колибри-репозитории и работай прямо там; если нет, можешь в качестве альтернативы к выкладыванию файла различий просто послать оптимизированный вариант тому же mike.dld или мне, контакты можно узнать, например, на kolibrios.org.Если нужно, я готов составить файл со списком программ,
где напишу возможные улучшения для каждого вплоть
до номеров строк.
А ещё надо учитывать что в памяти программа занимает целое число страниц и накладные расходы памяти на выполнение программы end раз в сорок больше самой программы
Ну хорошо, насчет MOV EAX, 1 я действительно не заметил. Но вот код, который есть почти в каждой программе
still: ; MAIN PROGRAM CYCLE
mov eax,10 ; wait for event
mcall
cmp eax,1 ; redraw? -
je red ; goto red
cmp eax,2 ; key pressed? -
je key ; goto key
cmp eax,3 ; button pressed? -
je button ; goto button
jmp still ; no more events to process
Почему нельзя было заменить все эти CMP на DEC EAX / JZ?
PS: Посмотрел повнимательнее - действительно, такой код есть примерно в половине программ. В половине (в той же END) он действительно заменен на DEC/JZ. Но что мешало заменить его и во второй половине?
still: ; MAIN PROGRAM CYCLE
mov eax,10 ; wait for event
mcall
cmp eax,1 ; redraw? -
je red ; goto red
cmp eax,2 ; key pressed? -
je key ; goto key
cmp eax,3 ; button pressed? -
je button ; goto button
jmp still ; no more events to process
Почему нельзя было заменить все эти CMP на DEC EAX / JZ?
PS: Посмотрел повнимательнее - действительно, такой код есть примерно в половине программ. В половине (в той же END) он действительно заменен на DEC/JZ. Но что мешало заменить его и во второй половине?
Вот для примера код игры "15". Кое-какие оптимизации могут оказаться неправильными, но хотя бы
появятся вопросы для обсуждения. Про STILL я уже говорил. Кроме того.
Строка 66
mov cl,16
ror eax,cl
--> ror eax, 16
Строка 118
cmp eax,176
jl still
sub eax,176
cmp eax,3
ja still
movzx eax,byte [eax+correct] ; 'delta' value from correct[]
jmp m_check
-->
sub eax,176
jc still
cmp eax,3
ja still
movzx eax,byte [eax+correct] ; 'delta' value from correct[]
jmp m_check
Строка 416
cmp ecx,0
jne no_win
--> or ecx, ecx
появятся вопросы для обсуждения. Про STILL я уже говорил. Кроме того.
Строка 66
mov cl,16
ror eax,cl
--> ror eax, 16
Строка 118
cmp eax,176
jl still
sub eax,176
cmp eax,3
ja still
movzx eax,byte [eax+correct] ; 'delta' value from correct[]
jmp m_check
-->
sub eax,176
jc still
cmp eax,3
ja still
movzx eax,byte [eax+correct] ; 'delta' value from correct[]
jmp m_check
Строка 416
cmp ecx,0
jne no_win
--> or ecx, ecx
blueboar
Это очень важный момент! В погоне за уменьшением размера/увеличением скорости запросто можно внести кучу новых багов. Оптимизировать нужно крайне осторожно, всегда помечая в контроле версий что, где и зачем было переписано.Кое-какие оптимизации могут оказаться неправильными
А может просто разработчикам программ самим оптимизировать код? + также пересмотреть содержание программ на самой ОС (точнее на дискетке с ОС)?
По историческим соображениям. Изначально много программ были написаны Ville, а многие другие программы - по этому образцу. В результате получился код с cmp. Позже были оптимизации, в частности, временами лично я выбирал программу, занимающую 512*n+epsilon байт и оптимизировал до состояния 512*n-epsilon В некоторых программах замену на dec/jz сделал Heavyiron заодно с перерисыванием на использование новых заголовков/системных вызовов.Почему нельзя было заменить все эти CMP на DEC EAX / JZ?
PS: Посмотрел повнимательнее - действительно, такой код есть примерно в половине программ. В половине (в той же END) он действительно заменен на DEC/JZ. Но что мешало заменить его и во второй половине?
Интересно. Как вы отнесетесь к тому коду который начнет выходить из под пера компиляторов высокоуровневых языков .
..bw
..bw
bw
Будем дизассемблировать, и править, править, править...
Будем дизассемблировать, и править, править, править...
Преждевременная оптимизация - сами знаете что такое. А у меня ни одну программу язык не поворачивается назвать хотя бы более-менее законченной. Оптимизация хороша и заметна в критичных алгоритмах, таких как, например, сортировка. А в основном народ пишет код, чтобы его потом понимать и иметь возможность сопровождать, а не чтобы на него смотрели и не понимали, как оно работает и как что-то исправить.
To Mario79
Знать бы, что править
Высокоуровневые компиляторы очень хорошо выполняют кучу рутины - типа, выравнивания команд/операндов/переходов по словам и распихивания по регистрам. Да и одних оптимизаций циклов можно штук 5 придумать - кому охота с этим заморачиваться вручную?
Для всяких высокоуровневых конструкций давно известны оптимальные аналоги на ASM.
To Ленин
Грамотно. Согласен.
Знать бы, что править
Высокоуровневые компиляторы очень хорошо выполняют кучу рутины - типа, выравнивания команд/операндов/переходов по словам и распихивания по регистрам. Да и одних оптимизаций циклов можно штук 5 придумать - кому охота с этим заморачиваться вручную?
Для всяких высокоуровневых конструкций давно известны оптимальные аналоги на ASM.
To Ленин
Грамотно. Согласен.
Насчёт оптимизации...
Занимался я как-то портированием TinyC в Колибри. Там вывод сообщений об ошибках производится посредством функции printf(). Я долго не мог понять, почему же не выводятся сообщения от компилятора. Потратил кучу времени и нервов. А оказалось, что компилятор GCC САМОВОЛЬНО подменял функции printf() на puts(). Но так как puts() ещё небыла реализована в menuetlibc, то никаких сообщений от компилятора не поступало. С точки зрения оптимизации эта подмена правильная, с точки зрения нервов программиста и надёжности скомпилированного кода - нет.
Так что доверяйте компиляторам языков высокого уровня, но проверяйте сгенерированный код !
Занимался я как-то портированием TinyC в Колибри. Там вывод сообщений об ошибках производится посредством функции printf(). Я долго не мог понять, почему же не выводятся сообщения от компилятора. Потратил кучу времени и нервов. А оказалось, что компилятор GCC САМОВОЛЬНО подменял функции printf() на puts(). Но так как puts() ещё небыла реализована в menuetlibc, то никаких сообщений от компилятора не поступало. С точки зрения оптимизации эта подмена правильная, с точки зрения нервов программиста и надёжности скомпилированного кода - нет.
Так что доверяйте компиляторам языков высокого уровня, но проверяйте сгенерированный код !
Who is online
Users browsing this forum: No registered users and 1 guest