Доброго времени суток, дамы и господа!
Вопрос из ряда теоретических:
имеется достаточно объемный модуль с описаниями нескольких классов. Там же - ряд общих (для всех классов) процедур (не методов). На текущий момент эти общие процедуры используются только в данном модуле, причем - используются достаточно "плотно". Как будет дальше - пока не знаю, но возможно - потребуется вызов из других, не связанных напрямую с этим модулем (то есть, добавлять в гыуы нового модуля этот может быть нежелательно). Вот и не могу понять - стоит ли сразу эти процедуры вынести в отдельный юнит?

Собственно - вопрос в том, отличаются ли вызовы процедуры_в_своем_модуле от процедуры_в_другом_модуле? Скорость является достаточно критичным фактором.

З.Ы. В отладчик просьба не посылать - "близкий" от "далекого" вызова не отличу (последний раз с ассемблером работал еще на Спектруме, так что об особенностях работы различных вызовов можно считать ничего не знаю).

1)Короткие/дальние вызовы были только в 16 битных процессорах. В 32 битных все вызовы одинаковы и идут по 32 битному адресу, хоть вызов из этого же модуля, другого модуля или из DLL библиотеки или метод интерфейса (правда последний вызывается из таблицы VMT)

2)Очень сомневаюсь что на компах начиная с Pentium I модель вызова может иметь какое-то значение. Начиная с этих процессоров реализуется параллельное выполнение инструкций и очень важное значение имеет не время работы одной команды, а взаимное расположение команд, а также количество промахов в кэше

Это понятно, про оптимизацию и оптимальное расположение ассемблерных инструкций слышал  Вот как раз поэтому (одна из причин) и спрашивал - если процедура находится в другом модуле, то скорее всего (???) она окажется в адресном пространстве далеко от текущего кода (если не прав - то вопрос можно считать решенным). Или нынешние процессоры настолько помешаны на оптимизации, что могут загружать в свой кэш кусок одного участка программы и кусок другого, миксуя их там как угодно?

Вообще - может, я зря в эти дебри полез, и лучше сосредоточиться на читабельности кода? (хотя, при прохождении AQTime бывает всплывают участки кода, небольшое изменение которых уменьшало время выполнения процедуры в несколько раз (!) )

Я тоже думаю, что будет промах кеша при вызове разнесенных методов, но учитывая размер линии кэша и размеры процедур, я думаю при вызове функции промах случается в 90% процентов случаев, однако учитывая наличие предсказателя переходов упадок производительности из-за этого будет минимальный. Я думая для производительности решающее значение имеет промахи при обращении к данным, т.к их гораздо больше и они сильно разнесены по памяти.

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

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

ЗЫ: Интересно из какой области это приложение, что требуется такая оптимизация?

Не, я же не говорил, что действительно требуется  Вопрос-то был теоретический   , так сказать - с прицелом на будущее. А вообще, текущее приложение из области шифрования данных...

Спасибо за разъяснения.