Про оптимизацию кода

google://rtc resolution

Да, кстати, учитывая суперскалярность, многоуровневую кэш-память и прочие подобные штуки, измерять производительность такий способом - гиблое дело.

То есть время выполнения функции будет зависеть от того в какой я ее прогк вызываю?

Время исполнения кода напрямую зависит от того, есть ли нужные данные в кэше. Например, банальное a+b выполнится за пару циклов, если оба операнда есть в L1-кэше, в противном случае же эта операция застрянет циклов на 200 (кажется такая задержка у DDR3 сейчас).

http://www.akkadia.org/drepper/cpumemory.pdf

Тебе стоит почитать вот это.

Real time плохо считать так как он не учитывает прерывания, а время затраченное на конкретный поток покажет, на х86 асма с rdtsk, короче самое лучшее считать такты на конкретный процесс

Счётчик процессов так же не учитывает прерывания и переключение контекста, так что забудь о нём.

s/процессов/тактов/ разумеется

Да я это все знаю, первый а плюс б или перед ним загрузит данные в кеш выполнив как ты сказал кучу лишних циклов а если сделать стопицот циклов то данные к кеше будут всегда а сложение будет занимать время в наносекундах потому и получается то о чем я говорил. Блин лучшеб тему не создавал) думал мне скажут что я делаю не так а тут оказывается все зависит от в целом от случая и надо в «боевых» условиях проверять все

Ну хз, я проверял так, создавал два потока и один усыплял и в нем время считал, а во втором что либо делал, в итоге спящий поток всегда показывал единое число тактов, абсолютно одно итоге число, причем если было бы как ты то каждый раз было бы по разному в зависимости от состояние процессов во всей системе

Ну зачем же так категорично, всякие не дёргающие ядро алгоритмы можно и через rdtsc мерять, главное приоритет повыше процессу поставить (в идеале realtime, конечно), ну и много прогонов делать.

Ну зачем же так категорично, всякие не дёргающие syscall алгоритмы можно и через rdtsc мерять

У тебя ОС с вытесняющей многозадачностью :)

Ну сколько я функций не тестил всегда было примерно так: 3 разных сильно отличающихся числа с небольшим плюс минусом в итоге меньшее число это время работы функции в идеальном случае, среднее это то время на которое стоит ориентироваться и самое большое это то что будет в худшем случае

Ну поэтому и приоритет realtime должен быть, чтобы многозадачность не мешала, пока сами не позволим :) Тут главное самому в сисколл или page fault не свалиться.

одна итерация занимает 1 мкр а скажем 50к итераций 1к мкр

Короткие временные промежутки замерять нельзя - не хватит разрешающей способности таймеров, слишком велико влияние сторонних факторов типа шедулинга, и оверхеда самой clock_gettime.