В последнее время меня стал сильно беспокоить вопрос оптимизации.
Кто какие приемы оптимизации использует(если использует)?

В частности, вот вопрос:
Кто-нить вообще использовал на практике возможность программной предвыборки в кэш?

оптимизация - когда скорость, когда размер, но стараюсь найти золотую середину
по возможности использую все
по не использую, только документацию

Теория оптимизации - это весьма обширный разговор, у нас на курсах он продолжался на протяжении нескольких лекций, в аттаче - краткий конспект первой из них (все примеры - на Паскале/Дельфи). Оптимизация - это вообще довольно емкое понятие, оно включает как создание более эффективного кода (занимающего меньше места, или работающего быстрее), так и теорию алгоритмов для поиска оптимального решения. Последнее - вообще университетский курс, начиная от численных методов поиска экстремума, и до совсем глобальных вещей, о которых на форуме даже разговор поднимать не имеет смысла, наверное Так что ты уж определись - что именно тебя интересует.

Я про код

В первом вопросе явно нехватает пункта "Когда как". Вообще оптимизировать стараюсь при написании (ну так чтоб код не повторялся и т.п.), а если что-то серьезное, тогда опять же документация. Очень редко использую профилировщик, да и оптимизировать приходится нечасто и в основном по размеру.

З.Ы.: Книга Касперски "Техника оптимизации программ" заставила много о чем задуматся.

Оптимизирую только по скорости.
ASMer, походу только мы с тобой проголосовали за 3й вариант 2ого вопроса ?

echo, это был я

Хм... интересно тогда он проголосовал за "Другое..." , интересно...
ЗЫ кто ни будь объясните что подразумевается под "Классический" ассемблер O_o

Имеется ввиду обычное переписывание "тормозного" кода на ассемблере(под CPU и FPU), но
не используя расширения типа Multimedia Extensions или Streaming Single Instruction Multiple Data Extensions.


Ага

ЛОЛ, а кто это у нас оптимизирует по памяти? Я вообще, честно говоря, думал, что в первом опросе смысла ноль - что в наше время огромных объемов железа все оптимизируют только по скорости

Не скажи. Вот у меня один проект есть и там потребовалось сделать маленький exe'шник (не основной, а дополнительный). Порывшись в документации я использовал пару трюков в VC и упаковщик. В итоге получилось 4Кб вместо 54Кб

Чаще всего по скорости, но задачи разные бывают
Понимаешь, Грей, одно другому мешает. Если оптимизировать скорость - размер будет
резко увеличиваться. Взять хотя бы развертывание циклов(если, конечно, компилятор сам этого не делает).

Ты мне это рассказываешь Я, помнится, ещё 10 лет назад на эту тему детям лекции читал (вон выше выложил текстовый файлик с лекцией)...

Это все понятно - но именно поэтому мои проги и весят за метр Что такое метр памяти во времена, когда гиг мозгов - это норма, да и два гига уже у многих есть? Скорость - наше все!

1) Скорость рулит, НО ТОЛЬКО если задача это оправдывает.
Если же задача не требует от программиста скорости, не имеет смысла расходовать на скорость лишние байты кода.

2) Из копеек складываются рубли. Помнится я видел полноценное 3д графическое приложение,
написанное на чистом ассемблере, с БООЛЬШОЙ кучей ресурсов, встроенных прямо в экзешник(музыка, мэши, текстуры, скрипты). Весило это щастье 64 кбайта. Я к тому, что интернет пока не совершенен,
поэтому потребность в малом размере передаваемых файлов очень велика. А вышеописанный пример,
показывает, что есть к чему стремиться.

Ну, понятно, что если особо не требуется - можно и ВОВСЕ оптимизацией не заниматься но кто ей не занимается - в этот топ не заходит... Что же касается второго абзаца, то к нему можно применить твой собственный первый Лично у меня ни разу ещё не возникало необходимости писать прогу маленького размера - на работе у нас анлим, да и все равно размер базы на два-три порядка превышает размер проги Так что кому надо скачать - скачают, и на размер проги даже внимания не обратят...

Про размер - да.
Ну так же будет не всегда
Во всяком случае, этим занимаются различные Research - центры. Мы-то, в основном, на готовенькое идем
Надо для приличия хотя б знать, как грамотно использовать тот или иной компилятор для сокращения размера.

Ну, скорость полюбому, важнее.

ЗЫ
Кстати, кто-то все же проголосовал за "память".

Не согласен !

Скажем так - не всегда!

Но вот допустим есть цикл:

Фактически, итоговый код будет состоять из тела
и команд условного перехода.
При отключенной оптимизации, тело состоит здесь из одного оператора( инкремент не учитываем).

Развернем в 4 раза(или позволим, грубо говоря, компилятору сделать это за нас):

Тело состоит здесь из 4-х операторов.
Скорость увеличилась, но увеличился и размер.

Это только один цикл, теперь давайте представим, сколько всего циклов чтения/записи может быть
в нашей программе. Прилично.

видели, знаем, называется .kkrieger и весит он вроде не 64, а 96 кило. там не большое кол-во ресурсов, там мега алгоритмы генерации текстур заложены, т.е там все текстуры процедурные.
кстати эта "крошка" не запускалалсь не имея под собой минимум 512 метров на раме. это я так к слову.

Я большей частью пишу клиентские прораммы. Поэтому оптимизация - как можно большая разгрузка компа клиента. Обработкой данных должен заниматься сервер. Отсюда и оптимизация памяти, и скорости и проч...

Хм. А звук?

Я если к серверу подключается куча клиентов и сервер обрабатывает большой поток данных? Отпитимировать нужно конкретную программу под конкретные нужды.

Никто не говорит что программу ненадо оптимизировать вовсе. А если к серверу подключается куча клиентов - нужен крутой сервер. Я знаю один такой стоимостью более 100 тыс. $.

Ты ещё спроси: а если клиент находится на расстоянии 1000 км...
Я в общем говорил. Принцип такой.

Конечно лучше , скорость..., и малый объём, я плюю на читабельность
Для этого существуют коментарии!
А для более удобного сопровождения либо создание ПО, либо ООП...

Фига себе
Т.е. ты сразу пытаешься писать быстрый и компактный код?
Бесполезно. Оптимизация без измерения результатов - пустая трата времени.

ЗЫ
Комментарии существуют для другого

ООП жутко тормозная штука


Я сразу пытаюсь...
Не всегда выходит, но всё равно

Нечитабельный код трудно сопровождать,
тем более к концу проекта "доживет" не весь код.

Одно дело - выбор грамотного алгоритма и некоторый здравый смысл
(вынос инвариантного кода запределы цикла).

Другое - более глубокая оптимизация, которая не несет в себе логики и "здравого смысла".
Не измеряя результаты можно получить совершенно обратный эффект. Поэтому,
как правило имеет смысл вначале писать код, удобный для сопровождения. Но это
мое ИМХО.

Абсолютно согласен Структурники ХО! ООП маздай

А читаемость программы никоем образом не связана с эффективностью ну, почти. Одну и ту же прогу можно написать читабельно и нечитабельно, и у них зачастую даже машинный код отличаться не будет.

Вот именно. Поэтому почему бы не писать читабельно?

Занимаюсь только базами данных - в них оптимизация это наличие индексов, правильная расстановка тейблспейсов и правильно написанный код и конкретно запрос.

Для оптимизации использую Execution Plan который показывает что именно работает медленно в запросе. (для разных серверов он разный)

То о чем ты говоришь это оптимизация обработки больших объемов чисел (всякие ССЕ ММиКс и тд) и я себе слабо представляю что разработчики игр спускаются на уровень этих команд для улучшения рендеринга. А вообще с этой частью программирования не сталкивался - интересно послушать.

Я спускался до SSE - пока не жаловался

Все зависит от того, где именно проводить вычисления.
Можно проводить на GPU(графическом процессоре на видеокарте)
через шейдеры. Это по определению будет намного быстрее, чем на центральном.

Но если требуются какие-то промежуточные вычисления,
например для определения столкновений на CPU,
использовать инструкции - самое оно!!!
Причем лучше, конечно, не раскидывать их по всему коду,
а скрыть в паре функций/методов.

Streaming SIMD Extensions помогают в частности быстро выполнять операции с 3д/4д
векторами(складывать, умножать на константу, скалярное произведение и т.д),
матрицами и др. мат элементами.

Причем можно использовать как чистый ассемблер(используя регистры типа xmm),
а можно использовать интеловские макросы и библиотеки, которые во многом упрощают работу
(Борланд вышел покурить, Only for MS Visual Studio)

Предусмотрено восемь 128-битных регистров(xmm0,xmm1, xmm2 ... xmm7)
(ассоциациии возникают? Совершенно верно - 4 32-битных координаты (x,y,z,w) на регистр)
Короче, SIMD позволяет ОДНОВРЕМЕННО выполнять операции
с 4-мя 32-битовыми числами.

К стандартному набору инструкций в
3-ем Пне добавили около 70-80 новых, работающих с xmm-регистрами.
Причем, SSE спокойно может работать параллельно с FPU и MMX.

SSE РЕАЛЬНО ВСЕГДА УСКОРЯЮТ РАБОТУ!!!!
Можете даже не сомневаться - это 100%. Не верите - проверьте.

Теперь про SSE2:
4 пень.
ССЕ 2 работают с числами двойной точности(64 бита)
Т.е. 128 битный регистр теперь поделен только на 2 части а не на 4,
как это было в 1-ых. Я никогда не работал со 2-ми.
Скажу лишь, что там есть около 150 команд.

ЗЫ
Математические функции, встроенные в расширения DirectX,
используют SIMD.

Все что ты написал понятно. Один единственный вопрос о котором идет речь именно в этой теме. Ты спускался до команд процессора при оптимизации движка игры или просто для того чтобы попробовать? 2-ое похвально но не отражает реалии жизни. Как ты уже заметил все это объединено в библиотеки и доступно для использования в оттестированном виде - что гораздо "лучше" чем самопал если идет работа над "продаваемым" проектом.

И все таки. Интересен вопрос именно оптимизации на уровне команд. Т.е. написание библиотек для прокладки более высокого уровня например OpenGL/DirectX. Ты этим занимался? И вообще насколько это распространенная практика. А может я вообще все путаю и эти библиотеки сами написаны на ASM-е

Спускался в предыдущих графических проектах.
Текущий движок еще не оптимизировал.



OpenGL не содержит никаких SSE библиотек для оптимизации.
DX тоже не содержит(в чистом виде), но для него есть расширения
(те самые файлы "d3dx9_n.dll", которые требуют самые свежие игры, выдавая ошибку при
запуске, где n - номер библиотеки ).

=> Под OpenGL народу приходится писать, хотя наверняка есть какие-то готовые.

Я OpenGL не использую, ибо Г. , а в применять какие-то
нестандартные мат операции(которые еще не реализованы в DX и их приходится
оптимизировать вручную) приходится редко, тем более, что с каждым обновлением
число таких операций резко сокращается.

Вообще не имеет смысл писать библиотеки, код-то предельно прост -
на уровне кода вызова одной функции.

Сложение координат 4-мерных векторов:
c = a+b

Чистый ассемблер(имеет смысл выделить под это одну inline функцию)


Библиотека Intel:


"Ну вот, а ты боялась - только юбочка помялась"



Ты про OpenGL и DX?
Это не библиотеки а графические API. Это все-таки
разные вещи.
DX вообще полностью построен на COM.

Ну в общем то что оно COM понятно. Только любой COM это либо EXE либо DLL. В данном случае это Dll. А теперь вопрос. Если вся эта функциональность уже включена в DLL как предполагается ее оптимизировать?

Ответ - никак.

Я говорю про функции. которые еще не реализованы в стандартных ДЛЛ.

Кроме того, DX скорее всего не определяет - доступно ССЕ или нет(!!!)

Вы никогда не задумывались: Почему в совр. играх главное системное требование
проц должнен быть не ниже PIII. Правильно - потому что в PIII появился ССЕ.

Хорошо бы проверять конечно, тем более что есть такие процы как у Mind'а
( Необъяснимые ошибки при запуске игр! )

If -then-else конечно хорошо, но уж больно примитивно
Схема действий такова:
ИМХО: хорошо бы вызывать не саму DX-функцию,
а завести еще одну функцию с таким же прототипом,
но не использующую SIMD-инструкции.

Затем при запуске определять - доступно ли ССЕ
и устанавливать указатель на соотв. функцию

Затем в коде вызывать функцию, которая находится по
адресу в указателе. Ну я делал так
Кто сможет лучше - пусть сделает.

Аналогично можно делать и для самописных функций
(которые еще не реализованы в DX)

ЗЫ
В DirectX все мат функции все-таки находятся на более высоком уровне
абстракции, чем ССЕ. Есть, конечно, функции, которые полностью повторяют
смысл некоторых SIMD инструкций(например скалярное перемножение векторов),
но работа с матрицами напрямую не реализована в SIMD, поэтому функции MS
удобнее чем SIMD.

Когда новый математический элемент становится полезным
для графики(как это случилось с кватернионами), разработчикам приходится писать под него код и оптимизировать при помощи
SIMD. MS тоже рано или поздно это сделает, но вы же не будете ради этого месяцами ждать очередного обновления?

Короче с оптимизацией мат расчетов(соотв. с SSE) дело обстоит НАМНОГО проще,
чем с отбраковкой, инстансингом, оптимизацией шейдеров и другими наполовину
GPU-шными задачами(они являются более тормозными)

ИМХО Поэтому не следует приравнивать понятия SSE и ОПТИМИЗАЦИЯ.
Здорово, конечно, но упор надо ставить не на это. Точнее так - оптимизацией
мат расчетов на центральном процессоре следует заниматься в последнюю очередь.

Скажу немного не в тему.
Но, немного всё же в тему, так что скажу ;-)

Ныне основная реальная задача оптимизации- по скорости (разработки ;-) ) и по стоимости этой разработки...

На память все чихают, ибо проще купить лишний гигабайт, чем заплатить программисту лишний месяц зарплаты. Конечно, в некоторых случаях это надо делать... Но уже много лет я работаю с файлами, загружая их махом в память и там уже по ним шуруя (не отображая, а именно загружая) - и никто не жаловался на то, что программа жрёт 200 мегабайт оперативки. По скорости - тоже редко приходится опускаться до низкоуровневой оптимизации, ибо процессоры нынче стремительны, а писать дублирующие механизмы для АДО (а тем более к WinAPI), к примеру- очень тяжёлая задача...
На моей практике - лаги бывают в основном в базах данных из-за медленных драйверов баз данных. Или их неоптимального использования. А базы данных- 95% разрабатываемых программ...

Вопрос в другом - вы как оптимизируете программы- по качеству или по стоимости? ;-) По скорости разработки или цене?...

Стрелять таких надо

;-)
Варианты
1) Вы платите 100 долларов и программа занимает 200 метров
2) Вы платите 1000 долларов, программа работает вдвое дольше, но занимает 1 метр.

Ваш выбор?

3) Написать самому

Это зависит от программиста. Можно сделать так,
что вся "стремительность" уйдет в минус.

Можно не спускаться на низкий уровень, но нужно разумно
пользоваться своими средствами .


Это уже выбор типа интеграции,
методологии разработки и т.д.
Вопрос к менеджерам а не к программистам.


Эта пять

Не каждый может сам написать... Так что вариант получается "не пользоваться программой".

Вы не одиноки! Так думает половина фирм, которым действительно нужен софт. Две мысли:
1) "Да это можно на рынке за 100 рублей купить- а с меня 2000 долларов просят!"
2) Вася из соседнего подъезда обещал сделать за 100 рублей.
В первом случае просто махнут рукой и продолжат терять деньги, во втором - наймут этого Васю, который им напишет "программу" на Access, все данные в одной табличке... Они с этой программой неделю потрахаются, потом разочаруются в ИТ-технологиях вообще и пойдут тем же путём...

А в итоге программисты сидят без работы, а потенциальные клиенты нанимают штат секретарш вести систему excel-таблиц (ох, сколько я таких штук видел...)

Если же Вы готовы терять время (много времени) на то, что бы написать программу, которая будет просто более оптимальна, то я Вам завидую ;-)
У меня его просто нет. И у клиентов обычно нет лишних денег, что бы оплачивать работу, результат которой носит дефакто чисто эстетическое значение.

Про оптимизацию по цене вопрос был риторический.
Я имел в виду, что обычно на оптимизацию денег просто не хватает. И фактически задача сводится не к балансу "память/производительность", а к балансу "качество/производительность" или "качество/скорость изготовления программы" (хотя второе всё же реже).

Мы живём в реальном мире :-)

Вы можете привести пример коммерческой программы except игровые движки, для которых актуальна и коммерчески выгодна задача оптимизации кода на уровне ассемблера, внедрение технологии mxx-потомков? Даже если Вы что-то и придумаете, это будет капля в море, не так ли?


Практический опыт (скорее интуитивный) - время разработки вдвое более оптимального кода требует втрое больше времени. Для случаев, когда он уже более- менее оптимален.

Что до оптимизации готового приложения - могу заверить, много там без серьёзной переделки скорее всего не получится выиграть... Так это эта оптимизация готового продукта - "сферический конь в вакууме". В теории возможно, на практике никто не станет это делать (даже при наличии документированных исходников)

Т.е. получается "производительность" плохо влияет на "качество" ?

ЗЫ
Оптимизация - стоит денег, не спорю.
Все зависит от требований.
Там все про все должно быть четко написано(в большинстве случаев)
и про оптимизацию в том числе.



Капля в море - ну и?
Главное, что такие случаи есть, и если программист знает как
оптимизировать код - это пойдет ему только в плюс.



Стремиться к этому можно и нужно.
В большинстве случаев это вполне реально, если изначально программу
писали не кривые руки.

В конце концов, можно хотя бы поставить себе компилятор от Intel.
Не таких уж больших денег стоит

Производительность влияет на качество!
В этом вся фишка. Обычно под разработку программы отводится определённый бюджет времени и денег. Потому код написанный быстро (то есть неоптимально, с использованием стандартных средств) будет проще, и, следовательно, лучше отлажен. А если начать делать очень оптимально- либо не впишитесь в сроки, либо получится сырой продукт.

Варианты с бесконечным финансированием или бесплатными работниками предлагаю не рассматривать.

Смена компилятора почти ничего не меняет - она позволяет выиграть крохи в неоптимальном приложении.

И вообще.
Я виноват - увёл тему.
Прошу прощения за оффтоп. Я просто хотел отметить, что задача оптимальности кода- не самая главная при написании софта, и что при выборе "будем ли мы оптимизировать наш софт под sse" надо учитывать и коммерческий аспект.

Обычно, оптимизацию проводят в самом конце, когда код доведен до идеала, поэтому
легко решить - проводить ли ее или нет, трезво оценив оставшееся время.

Поскольку код уже отлажен и тестирован(с большой областью покрытия), оптимизированный
код будет предельно простым для отладки, т.к. вероятность возникновения ошибок
в других модулях минимальна.


Скорость стабильно увеличивается на 10-15%
(измерял лично)


Ну это понятно
Но не особо больших усилий это стоит(SSE, в частности).
=> По идее, не на много дороже. Но, это мое ИМХО, т.к. я не знаю ситуацию на рынке ПО.

Да ви що, молодой человек, поиздеваться пришли? Оптимизировать по стоимости? По СКОРОСТИ РАЗРАБОТКИ? Я что, с ума сошел? Чем быстрее я данную прогу напишу - тем, пардон, быстрее наступит одно из следующих двух событий:
а) на меня нагрузят другую задачу;
б) мне придется искать другую работу.
Оно мне нафик надо - одно или другое?

Он просто не понял, что этот топик для ПРОГРАММИСТОВ
а не для начальников/менеджеров