LINUX.ORG.RU

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


0

1

Усем привет, опция для gcc -O0 отключает все оптимизации? Ну тоесть совсем? А то просто я решил проверить время выполнения функции, и одна итерация занимает 1 мкр а скажем 50к итераций 1к мкр, входны данные использую одни и теже каждый раз, время считаю clock_gettime( CLOCK_REALTIME, &start) или например если я хочу проверить сколько времени займёт вызов pthread_mutex_lock(&mutex); pthread_mutex_unlock(&mutex); то для 1 вызова будет 1мкр, а для техже 50к 1.6к мкр


Ответ на: комментарий от hateyoufeel

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от Onito

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

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hateyoufeel

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

Onito ()
Ответ на: комментарий от hateyoufeel

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

Onito ()
Ответ на: комментарий от hateyoufeel

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

Onito ()
Ответ на: комментарий от hateyoufeel

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

mix_mix ★★★★★ ()
Последнее исправление: mix_mix (всего исправлений: 1)
Ответ на: комментарий от mix_mix

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от mix_mix

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

Onito ()
Ответ на: комментарий от hateyoufeel

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

mix_mix ★★★★★ ()

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

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

slovazap ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.