Re: О производительности
От: denisko http://sdeniskos.blogspot.com/
Дата: 19.08.09 18:16
Оценка: :)))
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

А можно я сразу к сути вопроса.
Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
<Подпись удалена модератором>
Re[2]: О производительности
От: Vamp Россия  
Дата: 19.08.09 18:19
Оценка:
D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
Красиво жить не запретишь.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: О производительности
От: igna Россия  
Дата: 20.08.09 01:59
Оценка:
Здравствуйте, denisko, Вы писали:

D>А можно я сразу к сути вопроса.

D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.

А длину обратно скорректировать забыл?
Re: О производительности
От: Kore Sar  
Дата: 20.08.09 13:32
Оценка: 7 (1)
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

О! Какая благодатная тема!
На своём проекте я ускорил работу приложения примерно в 100 раз. И уменьшил расход памяти примерно в 10 раз.

Основная причина тормозов — идиоты разработчики.
1) Делали много ненужных подсчетов медленными методами.
2) Часто выделяли и освобождали ненужные куски памяти.
3) Слишком много данных хранили и обрабатывали как строки, хотя мжено было использовать числа.
4) Много раз бегали по одному и тому же массиву в поисках одного и того же значения.
5) Всё происходило на многоядерных серверах, но одним потоком.

Что я сделал.
1) Подсчеты теперь производятся только тогда, когда появляется небоходимость. Алгоритмы сделал быстрыми. (Ускорение раза в 4.)
2) Память теперь еще раз не выделялась, а юзалась уже имеющаяся. Местами, где можно было, перешел от огромных буферов к потокам. (Ускорение раза в 2.)
3) Где использовали как ключ строку вида "1234567890", там перешли на int. (Ускорение раза в 2.)
4) Сделал кеширование результатов в некоторых местах. (Ускорение раза в 2-5.)
5) Заюзал многопоточность. (Ускорение максимум в 14 раз.
Автор: Kore Sar
Дата: 09.12.08
)



Основаня причина расхода памяти — тоже идиоты разработчики.
1) Чтобы подсчитать одно (из сотен) число они исполозовали половину из всей выделеной ими памяти. Т.е. один из 2-х ГБ служил для единственной цифры.
2) Использовались огромные буферы.
3) Использовали строки в тех местах, где можно было int.
4) Одна и та же информация хранилась как почти идентичная копия в другом месте для других целей.

Что я сделал.
1) Спросил можно ли отказаться от этой единственной цифры совсем. Начальники сказали что можно. И я удалил её к чертям. -50%
2) Перешел кое-где от буферов к потокам. — Исчезли так называемые пиковые нагрузки, когда к выделеной памяти выделялось еще 200%.
3) Заюзал int-ы где только можно. Еще -50%.
4) Создали одно хранилище информации для всех целей. Еще -50%.
Re[4]: О производительности
От: MxKazan Россия  
Дата: 20.08.09 16:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Nuzhny, Вы писали:


N>>Как это делается?

WH>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.
А можно конкретнее? Ключевые строки до оптимизации и после.
Re[5]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 21.08.09 04:29
Оценка: 1 (1)
Здравствуйте, MxKazan, Вы писали:

WH>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.

MK>А можно конкретнее?

http://people.redhat.com/drepper/cpumemory.pdf
Re[6]: О производительности
От: MxKazan Россия  
Дата: 21.08.09 14:55
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, MxKazan, Вы писали:


WH>>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.

MK>>А можно конкретнее?

DM>http://people.redhat.com/drepper/cpumemory.pdf

Отлично. Я теперь на все вопросы в форумах по .NET буду отвечать: "http://msdn.microsoft.com/ru-ru/default.aspx" Я же просил примеры кода, а не литературу, в которой нужно разбираться. Глубоко копаться я пока не хочу, а быстро глянуть — интересно. Но если нет примеров, то ладно, нет так нет.
Re[7]: О производительности
От: cl-user  
Дата: 21.08.09 18:03
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Глубоко копаться я пока не хочу...


Нет ничего более постоянного, чем временное...
Re[7]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 21.08.09 18:16
Оценка: 10 (1)
Здравствуйте, MxKazan, Вы писали:

MK> Я же просил примеры кода, а не литературу,


В том файле смотри главу 6, там конкретные приемы и примеры кода.
Re: О производительности
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.08.09 11:01
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Заменил алгоритм со сложностью O(n^2) на O(n* log n). Производительность, очевидно, возросла.


http://www.rsdn.org:80/File/18435/5278.png
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: О производительности
От: Hawk Россия  
Дата: 27.08.09 13:24
Оценка:
Здравствуйте, StevenIvanov, Вы писали:

SI>А потом его переписали с помощью идиомы COW.

SI>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.

А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...
Re[3]: О производительности
От: MT-Wizard Украина  
Дата: 27.08.09 15:25
Оценка:
Здравствуйте, Hawk, Вы писали:

H>Здравствуйте, StevenIvanov, Вы писали:


SI>>А потом его переписали с помощью идиомы COW.

SI>>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.

H>А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...


http://en.wikipedia.org/wiki/Copy-on-write
А ти, москалику, вже приїхав (с)
Re[3]: О производительности
От: IID Россия  
Дата: 01.09.09 21:20
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>У меня был случай, когда профайлер показал необычно много времени, проведенном в функциях lock/unlock. Оказалось, что это происходило в многопоточном property map. Но в превалирующем сценарии properties в него в записывались только со старта программы, а потом только читались. Хотя могли быть и другие properties, которые могли писаться когда угодно. Тогда было сделано так: property map был разбит на две части. Первоначальный набор properties помещался в read-only часть (которая не требовала синхронизации), а все остальные в read-write (где вызывались lock/unlock, как обычно). После этого lock/unlock навсегда исчезли из профайла.


А почему бы для writeable данных не использовать Read/Write блокировки, вместо эксклюзивных lock/unlock ?
kalsarikännit
Re: О производительности
От: LaPerouse  
Дата: 04.09.09 08:07
Оценка: 6 (1)
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

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

1. Переписал три алгоритма (осбенно заметным был эффект от переписывания алгоритма O(n2) на O(n))
2. Реализовал кэш, в результате чего последующие алгоритмы обхода графообразных структур могли пользоваться статистикой, накопленной во время работы предыдущих алгоритмов.
3. Произвел рефакторинг, в результате которого были устранены некоторые идиотские решения, сделанные мной на скорую руку по принципу "чтоб работало".
4. Исправил одну ошибку, производительность тут же возросла где-то на 20 процентов.
5. !!! Самое существенное ускорение прозошло от предобработки входного графа. Преобразовал его в соответствии с принципами предметной области в другой граф, по коротому уже отрабатывали остальные алгоритмы. Потом результаты работы этих алгоритмов поднимались до исходного графа по истории преобразований. Граф с 100000 вершин в зависимости от топологии может преобразовываться в граф с количеством вершин 100-1000. В результате чего достигается феноменальное ускорение! Надо сказать, что это стало возможным благодаря введению истории преобразований (которую поддерживает почти каждый алгоритм) и иммутабельным алгоритмам (не изменяющим состояние исходного графа).
6. Реализовал способ выборки подходящего итерационного процесса в зависимости от входных условий. Эта часть надо сказать еще толком не работает, поэтому эффект в ускорении незначительный (правильнее сказать — нестабильный).
7. Применил некоторые оптимизации, подсказанные предметной областью.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[3]: О производительности
От: LaPerouse  
Дата: 04.09.09 08:51
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, Cadet, Вы писали:


C>>Ну где же, где примеры наступления счастья от переписывания всего на С++???


DM>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.


Это прямо-таки удивительно (если без изменений алгоритма).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[4]: О производительности
От: FR  
Дата: 05.09.09 05:30
Оценка: 2 (1)
Здравствуйте, LaPerouse, Вы писали:

DM>>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.


LP>Это прямо-таки удивительно (если без изменений алгоритма).


В декларативном есть обсуждение.
А так ничего удивительного, достаточно или кучи мелких выделений памяти (у OCaml очень шустрый GC а стандартные аллокаторы C++ особенно VC обычно очень плохие) или как у него все логика транслируется в составное замыкание, если прямо переписать на C++ заменив замыкания объектами, то тоже получим тормоза, во первых из-за той же памяти во вторых из-за того что замыкания оптимизируются и инлайнятся компилятором OCamla гораздо лучше чем объекты компиляторами C++.
Re[5]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.09.09 17:48
Оценка: :)
Здравствуйте, FR, Вы писали:

LP>>Это прямо-таки удивительно (если без изменений алгоритма).


FR>В декларативном есть обсуждение.


Это ты про 2009 вспомнил, а тут речь про задание 2007-го — где ДНК в РНК транслировалась. Там просто действительно очень много выделений памяти было, оттого и разница в скорости.
Re: О производительности
От: hexamino http://hexamino.blogspot.com/
Дата: 07.09.09 09:44
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Переход к функциональным иммутабельным структурам данных
Автор: thesz
Дата: 21.02.09
— ускорение 10%
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.