Интернет магазин китайских планшетных компьютеров



Компьютеры - Оптимизация (информатика) - Приоритеты оптимизации

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


<<< Обратная совместимость
Ориентированное на пользователя проектирование >>>