7 + 14 == 14
Современные компьютеры, конечно, весьма загадочные звери.
Профилировал тут давеча callgrind-ом один бинарь: смотрю -- наверх всплывают две тяжёлые функции, допустим, A и B. На первую процессор тратит 14 млрд тиков, на вторую 7. Вклад всего остального, допустим, несущественен.
Казалось бы, должна ли программа стать быстрее на треть, если избавится в коде от функции B? Логика подсказывает, что да, и мало того -- под профайлером оно почти так и происходит. Но запускаешь релизную сборку -- по таймингам ускорение 2.5% вместо 33% :)
И причина древняя, и хорошо всем знакомая: функция B считает математику в тёплом и уютном кэше процессора, а A рыщет по памяти, инициализируя структуры и всячески перелинковывая их.
Короче, не очень понятно, как в таком недружелюбном мире профилировать что-то. Походу, надо сначала добиваться удовлетворительной работы программы в условиях 100%-го свопа на хард (причём, какой-нибудь старый 5400rpm), чтобы минимизировать все возможные random seek в алгоритме :)
Профилировал тут давеча callgrind-ом один бинарь: смотрю -- наверх всплывают две тяжёлые функции, допустим, A и B. На первую процессор тратит 14 млрд тиков, на вторую 7. Вклад всего остального, допустим, несущественен.
Казалось бы, должна ли программа стать быстрее на треть, если избавится в коде от функции B? Логика подсказывает, что да, и мало того -- под профайлером оно почти так и происходит. Но запускаешь релизную сборку -- по таймингам ускорение 2.5% вместо 33% :)
И причина древняя, и хорошо всем знакомая: функция B считает математику в тёплом и уютном кэше процессора, а A рыщет по памяти, инициализируя структуры и всячески перелинковывая их.
Короче, не очень понятно, как в таком недружелюбном мире профилировать что-то. Походу, надо сначала добиваться удовлетворительной работы программы в условиях 100%-го свопа на хард (причём, какой-нибудь старый 5400rpm), чтобы минимизировать все возможные random seek в алгоритме :)