вторник, 24 августа 2010 г.

Тяжела и неказиста

Месяц бьюсь с железкой, выжимаю такты. Любимое дело - переписать кусок на ассемблере, понаставить rdtsc, собрать тайминги, строить gnuplot'ом графики и любоваться.

Накопил забавного экспириенса...

Например, жила-была структура размером 32 байта. Ради ускорения добавил 8 байт, в которые при инициализации структуры пишу предварительно посчитанные коэффициенты, чтобы в основной логике не считать их каждый раз. Ну, стандартный, в общем, подход. Профит? Нифига! Количество попаданий в первый наносекундный интервал упало в... Нет! Просто рухнуло, в 2.5 раза. Попадание во второй, правда, подросло, но в 2.5 хуже в первом - это катастрофа. Выравнивание до 64 байт и префетч в нужном месте дела значительно улучшили, но до исходного варианта всё равно сильно не дотягивает.

Получается, что выгодней считать компактно расположенные данные, чем не считать некомпактные.

Другой случай: одна боевая итерация обработки данных безбожно жрёт такты. Все выделяемые куски логики обмеренны отдельно, сложены, сумма в 10 раз меньше, чем имеем на деле для всего. Тестовая итерация жрёт нормально, мало. В тестовом варианте данные сосутся из файла, в боевом - те же данные, но из raw-сокета, всего одно отличие. Только на каждое чтение из сокета каждый пакет протаскивается через все кишки ядра, которые нагло и беспардонно выбрасывают из кэша заботливо префетченные руками данные. А при чтении из файла libc делает буферизацию, уменьшая общее число сисколлов. Ну и сам код файловой системы, судя по всему, попроще, чем сетевой.

Самое паршивое, что такая фигня чисто аналитически понимается. Полдня и целый вечер мучался, думал.

Третий случай: у меня ноут со стареньким Core2Duo T5600, одна удалённая машина какой-то Феном, другая i7 (Nehalem). На всех трёх результаты микрооптимизаций часто дают противоположный эффект :)


Вывод явный: гентушники были бы правы, что если систему пересобирать под каждую коробку, то она могла бы быстрее работать, но только gcc пока оптимизировать код под такие тонкости не научился :) Да и для систем, работающих по событиям, т.е. 99.(9)% даже круто пересобранных гентушных установок, оно нафиг в принципе не нужно.

Ну и напоследок: если за оптимизациями не гоняться, то на чистых, канонических сях по сравнению с лиспом писать медленней не меньше, чем в 10 раз. Не меньше. То есть либо условия задачи стоят такие, что скорость по всей цепочке обработки до тактов надо выжимать, чтобы получить минимально возможную задержку на реакцию, либо работодатель просто в 10 раз больше денег потратит (если у лиспера и сишника з/п одинаковые). Т.к. я и то, и другое в одном лице, то сишный продукт получается на десятичный порядок дороже.

1 комментарий:

  1. Вроде бы ты в марте рассказывал, что вместо gnuplot на R поглядываешь. Не срослось?

    ОтветитьУдалить

Архив блога