хм...
-Ox
где x:
g - оптимизация по размеру кода
G - по скорости кода
r - хранить переменные целиком в регистрах (эксперементальная вещь и бывает выкидывает глюки)
u - включить кусочную оптимизацию (принцип - если каждый кусок быстрый, то и алгоритм быстрый), читать ниже об этом...
1 - быстрая оптимизация кода (при компиляции)
2 - чуть медленнее
3 - оптимизация O2 + Ou (где то видел что даже 5-ти проходная?)
так же если оперируете FPU/MMX/SSE/SSE2 не плохо использовать
-Opx
где x:
1 - для 386/486 камней
2 - Pentium/PentiumMMX
3 - PentiumPro,Pentium II-III,Celeron 6 покаления,K6
4 - Pentium 4
5 - Pentium M
будет базовая арифметика (включая массивную) работать быстрее... а также переходы в программе... но связывается с каким-то одним камнем...
самое однако великолепное это Op3 и выше... так как тут даже в ассемблере сложно оптимизировать до такого кода - на уровне конвеерной обработки... т.е. паралельного исполнения кода разными частями процессора... там целые теории и иногда месяца уходят на такую оптимизацию вручную... здесь как никак но основные принципы заложенны... меня это также радует )
на практике даже -O2 вполне хватает... я иногда на асме не могу лучше кода придумать, чем FPC мне выдаёт... по умолчанию юзается -OG, -O1 - менее эфективная, -O2 и -O3 более эфеткивны
более подробно:
OG - достаточно быстрая и толковая оптимизация (по умолчанию используется) но делает большой код
Or - хранит часто используемые пременные сразу в регистрах (очень полезно на программах с циклами и рекурсией) но бывают глюки, так как регистров общего назначения мало, а переменных бывает много... поэтому вроде как FPC не всегда справляется правильно их перебрасывать, когда одна переменная вдруг становится чаще использоваться чем другая (при условии множества переменных, уже забитых в так называемый стек регистров при компиляции)
O1 - заменяет хорошо известные структуры на более быстрый эквивалент
O2 - крутит что-то на основе ассемберной оптимизации (уже хорошо развитой в as)
O3 - то же, но более привередливо относится к ускорению именно по времени
с Ou вообще дело тёмное ) её далеко не всегда можно юзать... а так как она входит в O3, то последнюю тоже не всегда...
почему? я сам в этом долго в своё время разбирался )))
суть приблизительно в том, что оптимизация происходит блоками (независимыми) и если есть допутим переменная глобальная и внутри функции... неее наверное лучше на примере )))
- Код: Выделить всё
G:integer
procedure A(var b:integer);
begin
if G=b then
begin
inc(b);
if G<>b then writeln('bug');
end;
end;
реально оказывается что G - это конкретная переменная (с адресом), а b - передаваемый параметр (т.е. только адрес) с точки зрения компилятора... и никакой памяти физически ей не выделяется в любом виде компиляций )
при оптимизации Ou однако идея такая:
определённо инкримировать регистр лучше, чем прибавлять в памяти хз где единицу, а так как оптимизируем блоками не знаем что G и b завязыны и даже есть одна и та же переменная! то выдается код вида
- Код: Выделить всё
mov ax, G
mov bx,word [b]
cmp bx,ax
je +4 (@1)
jmp @END
@1: inc bx
jne @ВЫВЕСТИ_СЛОВО_БАГ <- не знаем, что то , что в bx должно по идее быть в [b], т.е. в G )
@END:
mov word [b],ax <- только тут сообщаем, что переменная одна и таже ! потому как адреса совпадают [G]=b
ret
вместо положенного
- Код: Выделить всё
mov ax, G
mov bx, b
cmp word [bx],ax
je +4 (@1)
jmp @END
@1:
inc [bx] <- инкримируем именно содержимое в памяти
mov ax,G <- читаем что именно сравниваем с b
cmp [bx],ax <- оказывается в G уже всё изминилось ! )
jne @ВЫВЕСТИ_СЛОВО_БАГ <- и этого не выведется
@END:
ret
поэтому при такой оптимизации функция A(G) выдаст слово bug, несмотря на то, что G=b (потому как она вызывается так... и адреса у них одинаковые) но блок функции не успел сообщить глобальной переменной, что её значение изменено... это требует частичная компиляция... вроде вот так приблизительно разжёван пример...
после -Ou пример по коду становится меньше на 4 байта, а по скорости - почти на 20% меньше тиков на i486, однако выводит слово bug ) чего быть не должно...
поэтому -Ou и -O3 стоит пользоваться с осторожностью... если не понимаете, о чём тут речь - лучше вообще не пользоваться

экономит это ну не более 10% на практике, если полно минифункций... как в драйверах...
во фортране однако вроде оптимизация бывает и на уровне функций языка, путём выбора лучшего алгоритма... здесь такое редко проглядывается... потому как алгоритм пишет программист и сам же его оптимизирует... однако на уровне конструкций ассемблера - оптимизация изумительная... я сам не раз поражался находчивости авторов FPC... за нами только правильно алгоритм придумать... хотя бы +/- близкий к оптимальным

всякие муравьиные алгоритмы пример обратного )
p.s. думаю достаточно... если что неправильно - поправьте )
p.p.s. извините за Intel-синтаксис... я не уважаю те компиляторы, где только AT&T типа GNU... (продолжите сами)