Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
А можно я сразу к сути вопроса.
Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
Красиво жить не запретишь.
Здравствуйте, denisko, Вы писали:
D>А можно я сразу к сути вопроса. D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
О! Какая благодатная тема!
На своём проекте я ускорил работу приложения примерно в 100 раз. И уменьшил расход памяти примерно в 10 раз.
Основная причина тормозов — идиоты разработчики.
1) Делали много ненужных подсчетов медленными методами.
2) Часто выделяли и освобождали ненужные куски памяти.
3) Слишком много данных хранили и обрабатывали как строки, хотя мжено было использовать числа.
4) Много раз бегали по одному и тому же массиву в поисках одного и того же значения.
5) Всё происходило на многоядерных серверах, но одним потоком.
Что я сделал.
1) Подсчеты теперь производятся только тогда, когда появляется небоходимость. Алгоритмы сделал быстрыми. (Ускорение раза в 4.)
2) Память теперь еще раз не выделялась, а юзалась уже имеющаяся. Местами, где можно было, перешел от огромных буферов к потокам. (Ускорение раза в 2.)
3) Где использовали как ключ строку вида "1234567890", там перешли на int. (Ускорение раза в 2.)
4) Сделал кеширование результатов в некоторых местах. (Ускорение раза в 2-5.)
5) Заюзал многопоточность. (Ускорение максимум в 14 раз.
Основаня причина расхода памяти — тоже идиоты разработчики.
1) Чтобы подсчитать одно (из сотен) число они исполозовали половину из всей выделеной ими памяти. Т.е. один из 2-х ГБ служил для единственной цифры.
2) Использовались огромные буферы.
3) Использовали строки в тех местах, где можно было int.
4) Одна и та же информация хранилась как почти идентичная копия в другом месте для других целей.
Что я сделал.
1) Спросил можно ли отказаться от этой единственной цифры совсем. Начальники сказали что можно. И я удалил её к чертям. -50%
2) Перешел кое-где от буферов к потокам. — Исчезли так называемые пиковые нагрузки, когда к выделеной памяти выделялось еще 200%.
3) Заюзал int-ы где только можно. Еще -50%.
4) Создали одно хранилище информации для всех целей. Еще -50%.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Nuzhny, Вы писали:
N>>Как это делается? WH>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.
А можно конкретнее? Ключевые строки до оптимизации и после.
Здравствуйте, MxKazan, Вы писали:
WH>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше. MK>А можно конкретнее?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, MxKazan, Вы писали:
WH>>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше. MK>>А можно конкретнее?
DM>http://people.redhat.com/drepper/cpumemory.pdf
Отлично. Я теперь на все вопросы в форумах по .NET буду отвечать: "http://msdn.microsoft.com/ru-ru/default.aspx" Я же просил примеры кода, а не литературу, в которой нужно разбираться. Глубоко копаться я пока не хочу, а быстро глянуть — интересно. Но если нет примеров, то ладно, нет так нет.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Заменил алгоритм со сложностью O(n^2) на O(n* log n). Производительность, очевидно, возросла.
Здравствуйте, StevenIvanov, Вы писали:
SI>А потом его переписали с помощью идиомы COW. SI>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.
А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...
Здравствуйте, Hawk, Вы писали:
H>Здравствуйте, StevenIvanov, Вы писали:
SI>>А потом его переписали с помощью идиомы COW. SI>>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.
H>А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...
Здравствуйте, alexeiz, Вы писали:
A>У меня был случай, когда профайлер показал необычно много времени, проведенном в функциях lock/unlock. Оказалось, что это происходило в многопоточном property map. Но в превалирующем сценарии properties в него в записывались только со старта программы, а потом только читались. Хотя могли быть и другие properties, которые могли писаться когда угодно. Тогда было сделано так: property map был разбит на две части. Первоначальный набор properties помещался в read-only часть (которая не требовала синхронизации), а все остальные в read-write (где вызывались lock/unlock, как обычно). После этого lock/unlock навсегда исчезли из профайла.
А почему бы для writeable данных не использовать Read/Write блокировки, вместо эксклюзивных lock/unlock ?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Недавно провел серию оптимизаций, результатом которых было ускорение кода более чем в 1000 раз и существенное сокращение потребляемой памяти.
1. Переписал три алгоритма (осбенно заметным был эффект от переписывания алгоритма O(n2) на O(n))
2. Реализовал кэш, в результате чего последующие алгоритмы обхода графообразных структур могли пользоваться статистикой, накопленной во время работы предыдущих алгоритмов.
3. Произвел рефакторинг, в результате которого были устранены некоторые идиотские решения, сделанные мной на скорую руку по принципу "чтоб работало".
4. Исправил одну ошибку, производительность тут же возросла где-то на 20 процентов.
5. !!! Самое существенное ускорение прозошло от предобработки входного графа. Преобразовал его в соответствии с принципами предметной области в другой граф, по коротому уже отрабатывали остальные алгоритмы. Потом результаты работы этих алгоритмов поднимались до исходного графа по истории преобразований. Граф с 100000 вершин в зависимости от топологии может преобразовываться в граф с количеством вершин 100-1000. В результате чего достигается феноменальное ускорение! Надо сказать, что это стало возможным благодаря введению истории преобразований (которую поддерживает почти каждый алгоритм) и иммутабельным алгоритмам (не изменяющим состояние исходного графа).
6. Реализовал способ выборки подходящего итерационного процесса в зависимости от входных условий. Эта часть надо сказать еще толком не работает, поэтому эффект в ускорении незначительный (правильнее сказать — нестабильный).
7. Применил некоторые оптимизации, подсказанные предметной областью.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Cadet, Вы писали:
C>>Ну где же, где примеры наступления счастья от переписывания всего на С++???
DM>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.
Это прямо-таки удивительно (если без изменений алгоритма).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
DM>>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.
LP>Это прямо-таки удивительно (если без изменений алгоритма).
В декларативном есть обсуждение.
А так ничего удивительного, достаточно или кучи мелких выделений памяти (у OCaml очень шустрый GC а стандартные аллокаторы C++ особенно VC обычно очень плохие) или как у него все логика транслируется в составное замыкание, если прямо переписать на C++ заменив замыкания объектами, то тоже получим тормоза, во первых из-за той же памяти во вторых из-за того что замыкания оптимизируются и инлайнятся компилятором OCamla гораздо лучше чем объекты компиляторами C++.
Здравствуйте, FR, Вы писали:
LP>>Это прямо-таки удивительно (если без изменений алгоритма).
FR>В декларативном есть обсуждение.
Это ты про 2009 вспомнил, а тут речь про задание 2007-го — где ДНК в РНК транслировалась. Там просто действительно очень много выделений памяти было, оттого и разница в скорости.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.