Есть функция на двеннадцать коммандочек. Много ли она потеряет, если вместо макроподстановки вызывать ее фастколлом?
Fastcall это не inline. Fastcall вызывает функцию через call, inline - напрямую встраивает в код. Так что от inline экономия будет как минимум на одной паре call-ret.
Уточню вопрос. Насколько потеряет в быстродействии функция длиной скажем в шестнадцать асмовых комманд, если ее вызывать call и возвращаться ret, передавая параметры через регистры, по отношению к быстродействию той же функции, чье тело прописывается в коде каждый раз макросом?
Вот еще, для макроподстановки функции тоже нужно готовить входные параметры =((( ну тоесть наскока call и ret так сказать травмируют вычислительный прцесс, может для 16-ти асмовых комманд уже можно будет принебреч ?
Дело не в процентном соотношении (исполняемый код процедуры)/(сall+ret+загрузка данных). Дело в том, как часто вызывается процедура. Если один раз за всё время - никакой разницы. А если в основном цикле, то разница вполне может быть заметна.
Так просто на это вопрос не ответить. С одной стороны, будут потери на call+ret. С другой - если функция заинлайнена 100000 раз, это раздует код, он перестанет помещаться в кеш, будут промахи которые еще дороже. Поэтому бери профайлер и меряй реальный код.
Да, с этим я тоже сталкивался, например когда развернул RSA 4096 и он у меня перестал а кэш влезать, и без того тормоз стал тормозить еще сильнее. Проблема в том, что специфика моего маньячества требует обязательную пропись мелких функций на асме (в языках отсутствуют специфические типы данных вроде конЕчных полей , элл. кривых и т.д.). А компилеры что я пробовал не позволяют вроде инлайн функций с дерективой asm. Ну буду делать макроподстановку.
persicum Присоединяюсь к J0E - померять разные варианты и выбрать лучший. А (имхо) лучше развлекаццо в DLL, на asm. Может получиться удачная библа. CALL+RET скорее лучше не делать. Алгоритм можно выложить и думаю тут найдутся люди кто скажет как можно улучшить, ну там может mmx.
VC позволяет но потом неожиданно падает с internal compiler error ) если есть jmp то может отключить оптимизацию для С. А что за функции? Вдруг их можно все таки написать на С?
Да там фигня всякая вроде add eax,ecx adc eax,0 sub eax,edx sbb edx,edx и так далее... На си себе дороже обойдется.
Да уж С с carry flag плохо дружит, cмотрим 2–12 Overflow Detection http://www.hackersdelight.org/basics.pdf Код (Text): uint32_t fignya(uint64_t eax, uint32_t ecx, uint32_t edx) { eax += ecx; eax += eax >> 32; return (uint32_t)eax < edx ? -1 : 0; } Получается одна лишняя команда против call+ret Код (Text): mov ecx, DWORD PTR _eax$[esp-4] add ecx, DWORD PTR _ecx$[esp-4] mov eax, DWORD PTR _eax$[esp] adc eax, 0 add eax, ecx cmp eax, DWORD PTR _edx$[esp-4] sbb eax, eax при инлайне может лучше будет.
