|
|
Компьютеры - Оптимизация (информатика) - Приоритеты оптимизации24 февраля 2011
Оглавление: 1. Оптимизация (информатика) 2. Основы 3. Простейшие приёмы оптимизации программ по затратам процессорного времени 4. Приоритеты оптимизации
- интерфейсный, т.е.желательно заранее ВСЁ согласовать с другими участниками проекта, включая кому сколько МАКСИМУМ %CPUuse на конкретном ПК.
- PS: ПК не должен быть современным и многопроцессорным... Если такого нет - заведомо сильно ограничить суммарный CPU расход, можно утилитами типа slowcpu; на MP доп.CPU отключая в BIOS/фиксируя все потоки на один CPU - исходя из того что релиз будет значительно тормознее ожидаемого, и чем сложнее тема, жёстче сроки, и меньше опыта в теме - тем сильнее... К тому же запас ВСЕГДА нужен ещё и на сколько-то нормальную работу в режиме DEBUG,TRACE
- PS: согласовать и обсудить - не спеша, и каждую мелочь вплоть до того где использовать ООП, а где нет - для ускорения. PS: Подсказка - STL и прч.- не использовать НИГДЕ... С# - аналогично, Скрипты - ТОЛЬКО там где нельзя без них обойтись..., тем более они часто привносят много проблем с багами...
- PS: причём не забыв каждую итерацию теста - искусственно сбрасывать L12 кэши и BTB,... Чтобы соединив все модули затем не удивляться...
- алгоритмический, минус - принцип чем оптимизированней - тем менее понятно, тем больше багов; но это самый эффективный способ, тем более наиболее оптимизируемые алгоритмы уже давно оптимизированы и можно посмотреть на их реализацию.
Этот пункт можно можно разделить на:
- математически-алгоритмический
- логически-алгоритмический
- проче-функционально-алгоритмический, например использования асинхронного исполнения всего что можно
...
- кэш-оптимизации на уровне алгоритма, включая HW L1,L2,программные-для данных, программные для ресурсов
- использование спецкоманд, например MMX,SSE,... Правда суммарно минусов больше чем плюсов, так как это чисто пиаровские технологии, например трудозатраты на разных архитектурах 2) у разных производителей CPU 3) в разных их моделях...)
PS: но, должен всегда быть вариант кода - без их наличия, в т.ч.для возм.портирования в будущем и просто для Safe версии исполнимого файла, т.к.некоторые PC-совместимые ПК, тем более лаптопы и прч. - не совсем совместимые и тем более безглючные...
- замена кода на ассемблерный, весьма спорна, т.к.не считая непортированности, и неплохого уровня оптимизации современных компиляторов, чтобы в случае большого объёма кода или применения нестандартных для программирования трюков приводит к очень плачевным результата - ошибкам, источник которые чаще так и не обнаруживается... Но оптимизация тоже имеет право на жизнь, особенно в inline или небольших ф-иях, типа rol и т.п. И особенно если программист хоть сколько знаком с ассемблером и архитектурой ПК, так как ассемблер позволяет иногда ускорить блоки в десятки и сотни раз за счёт визуального представления о функционировании и как следствии оптимизации так чтобы эффективно использовать L1, L2, промах которых на современных ПК исчисляется сотнями тактов.
PS: так же для каждого итерации оптимизации в идеале должен сохраняться неоптимизированный пример просто для понимания алгоритма другими людьми в проекте из тех кто плохо разбирается в подобном, или самому через пару недель/месяцев, просто для тестов на скорость и главное эквивалентность работы с и без такой оптимизации...
Просмотров: 4092
|