kazalex писал(а):В этом случае имеется немалый шанс обеспечить себя работой по переписыванию всего/большей части приложения. При этом я не ратую за преждевременную оптимизацию. Но разработка без оптимизаций основанных на методе предварительных оценок ни к чему хорошему не приведет точно.
На ранней стадии разработки нужно просто исследовать отдельные новые алгоритмы. А из предыдущего опыта уже знать правильные алгоритмы.
В результате собственно проект пишеться без оптимизации, но исходно на правильных алгоритмах и правильными методами программирования. Тестирование быстродействия без реальных примеров обычно не требуется, т.к. не угадаешь что нужно было тестить. На этапе финального тестирования (в рабочем окружении) вычищаются очевидные тормоза.
Статистика: Добавлено alexey38 — 16.12.2013 18:56:20
]]>
и
то есть около 30-ти (!!!) раз относительно одно-операндного (нынешнего FPC) варианта.
Вся статья : http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
Статистика: Добавлено debi12345 — 16.12.2013 12:52:46
]]>
kazalex писал(а):Все, разумеется, зависит от сложности решаемых задач.
Понятное дело. Но тот проект, который хочется сделать, мне если и удастся, то очень нескоро. Не хватает справочного материала на русском (с английским увы не очень дружу)
Статистика: Добавлено Лекс Айрин — 03.12.2013 00:45:59
]]>
Лекс Айрин писал(а):Вот и забивают на полноценное тестирование.
Это и есть культура разработки и разработчиков.
Лекс Айрин писал(а):Так прототипирование это не более чем черновые наброски.
Только эи черновые наброски позволяют выкристализовать/выбрать направление разработки алгоритмы и структуры данных для решения задачи. И процесс этот может быть весьма длительным. Кстати, именно на этом этапе наиболее часто используется отладчик, который очень не дружит с компиляторными оптимизациями.
Лекс Айрин писал(а):И, кстати, я не пишу прототипов. Они мне не нужны.
Все, разумеется, зависит от сложности решаемых задач.
Статистика: Добавлено kazalex — 02.12.2013 23:43:19
]]>
kazalex писал(а):От низкой культуры разработчиков, от чего же еще.
От желания писать код быстро, вообще-то. Вот и забивают на полноценное тестирование.
kazalex писал(а):На этапе прототипирования скорость получения результата очень важна.
Так прототипирование это не более чем черновые наброски.
Если позволена будет аналогия с написанием художественным текстом, то это канва произведения. Но если в канве окажутся неточные куски (а то и она вся), то они переписываются уже после написания более-менее значительного объема, когда обнаруживается ее фальш.
И, кстати, я не пишу прототипов. Они мне не нужны. Я сам себе заказчик и мне вполне хватит умения развалить проект на составляющие и переписать его заново с более оптимальным алгоритмом. Или начать его писать снизу, а не сверху, примерно представляя результат.
Статистика: Добавлено Лекс Айрин — 02.12.2013 20:56:36
]]>
Лекс Айрин писал(а):Конечно, не обязательно, но откуда тогда в прогах столько глюков?
От низкой культуры разработчиков, от чего же еще.
Лекс Айрин писал(а):Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.
На этапе прототипирования скорость получения результата очень важна.
Лекс Айрин писал(а):Форум-то для паскалевских программистов.
Вот только обсуждаемый вопрос значительно шире.
Статистика: Добавлено kazalex — 02.12.2013 20:27:17
]]>
Статистика: Добавлено Лекс Айрин — 02.12.2013 19:43:06
]]>
Тем не менее, компилирует он значительно дольше чем та же Delphi.
Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.
100% логично (даже не задумываешься сколь компилируется FPC-программа - отвернешься, а она уже готова), но хотелось бы чтобы более долгая компиляция объяснялась более тщательной оптимизацией. Пусть даже будет режим компиляции в 100раз медленнее чем обычно - но с оптимизацией уровня GCC/G++.
Статистика: Добавлено debi12345 — 02.12.2013 18:31:30
]]>
kazalex писал(а):А откуда эта идея, что если оптимизированная то значит обязательно неработоспособная?
Конечно, не обязательно, но откуда тогда в прогах столько глюков?
kazalex писал(а):Тем не менее, компилирует он значительно дольше чем та же Delphi.
Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.
kazalex писал(а):Но речь скорее об общем подходе, не все же pascal-only разработчики.
Форум-то для паскалевских программистов.
Статистика: Добавлено Лекс Айрин — 02.12.2013 17:51:11
]]>
Лекс Айрин писал(а):И что?
Да ничего. Только это мазохизм.
Лекс Айрин писал(а):Лучше оптимизировать неработоспособную программу?
А откуда эта идея, что если оптимизированная то значит обязательно неработоспособная? Тут стоит заметить, что оптимизированная совсем не означает, что там клубок низкоуровневых трюков. Последним, как раз, страдают прематурщики не понимающие, что выигрыш от таких плясок минимален, а код стремительно превращается во write only.
Лекс Айрин писал(а):FPC не Си с плюсами
Несомненно. Как и качество его оптимизаций. Тем не менее, компилирует он значительно дольше чем та же Delphi. Но речь скорее об общем подходе, не все же pascal-only разработчики.
Статистика: Добавлено kazalex — 02.12.2013 16:53:27
]]>
kazalex писал(а):В этом случае имеется немалый шанс обеспечить себя работой по переписыванию всего/большей части приложения.
И что? Лучше оптимизировать неработоспособную программу? Сколько раз находили ошибки в оптимизированном коде, которые там были с момента его создания. Конечно, по возможности, лучше стараться писать оптимальный код, но если в программе ошибки (и они не исправляются), но смысл пользования ею пропадает.
kazalex писал(а):то на этапе прототипирования они, вероятнее всего, будут лишь увеличивать время компиляции.
FPC не Си с плюсами, Я Lasarus скачиваю, переустанавливаю и перекомпилирую в процессе утреннего/вечернего просмотра новостей. Под любой из трех осей, в которых работаю. А настройки оптимизации я вбиваю сразу же при создании проекта и забываю о них.
Статистика: Добавлено Лекс Айрин — 02.12.2013 16:08:37
]]>
Лекс Айрин писал(а):Вообще-то правильнее создать работающее приложение, а потом уже думать об его оптимизации
В этом случае имеется немалый шанс обеспечить себя работой по переписыванию всего/большей части приложения. При этом я не ратую за преждевременную оптимизацию. Но разработка без оптимизаций основанных на методе предварительных оценок ни к чему хорошему не приведет точно.
Лекс Айрин писал(а):А опции компилятора (жонглирование) выставляются сразу и сразу же, по идее, влияют на производительность и/или размер программы.
Если оптимизации медленные (т.е компилятор тратит много времени на оптимизацию) то на этапе прототипирования они, вероятнее всего, будут лишь увеличивать время компиляции. Оптимизации хороши для уже отшлифованного алгоритма.
Статистика: Добавлено kazalex — 02.12.2013 15:02:54
]]>
kazalex писал(а):На момент проектирования если об оптимизации не думать то и не видно ничего. Более того, как я уже говорил, можно думать будто алгоритм быстр, а на деле окажется не так.
Вообще-то правильнее создать работающее приложение, а потом уже думать об его оптимизации. Иначе получается дележ шкуры не убитого медведя. А опции компилятора (жонглирование) выставляются сразу и сразу же, по идее, влияют на производительность и/или размер программы.
Статистика: Добавлено Лекс Айрин — 02.12.2013 08:43:38
]]>
Лекс Айрин писал(а):Самым корректным сравнением было бы написание версий с разными алгоритмами работы/оптимизациями
Так с самого начала об этом речь. Я же не о жонглировании опциями оптимизатора говорил.
Лекс Айрин писал(а):А разве 4 минуты не видны на глаз?
Это видно, когда случилась такая нагрузка. На момент проектирования если об оптимизации не думать то и не видно ничего. Более того, как я уже говорил, можно думать будто алгоритм быстр, а на деле окажется не так. И такие моменты ничем кроме бенчмаркинга не ловятся. Вообще, нагрузочное и эталонное тестирование желательно делать на объемах работы которые сильно превышают видящиеся на данный момент, и в этом есть определенный смысл
Статистика: Добавлено kazalex — 02.12.2013 01:47:53
]]>
kazalex писал(а):Ты зря называешь бенчмаркинг рабочего кода синтетикой.
Возможно, мы по разному понимает эти вещи. Самым корректным сравнением было бы написание версий с разными алгоритмами работы/оптимизациями. Все остальное пусть и менее трудоемко, но вносит искажения в окончательный вариант.
kazalex писал(а):и отставание в четверть секунды превратится в четыре минуты.
А разве 4 минуты не видны на глаз? Хотя... можно так заопримизировать, что придется вводить циклы задержки.
Статистика: Добавлено Лекс Айрин — 01.12.2013 23:23:00
]]>
Лекс Айрин писал(а):Там где она дает ощутимые плоды, результат виден на глаз...
Вовсе нет. Разницу между 0.75 сек. и 1сек. на глаз не увидишь, но она достаточно велика если говорить о часто используемой функции. Вызовешь такую тысячу раз и отставание в четверть секунды превратится в четыре минуты.
Лекс Айрин писал(а):Следовательно, никакая синтетика не нужна
Синтетика действительно не нужна. Но бенчмаркинг нужен т.к. не всегда предполагаемое совпадает с реальностью. Может оказаться так, что более громоздкий алгоритм работает быстрее.
Лекс Айрин писал(а):Да и оптимизация должна быть очень качественной
Вообще, самый большой выигрышь дают алгоритмические оптимизации и оптимизации основанные на понимании механизмов работы компилятора.
Лекс Айрин писал(а):Просто непонятна позиция некоторый к синтетике
Ты зря называешь бенчмаркинг рабочего кода синтетикой. Синтетика это когда выводы делаются по косвенным характеристикам. Тестирование рабочего кода дает возможность адекватно выбрать правильный путь развития.
Статистика: Добавлено kazalex — 01.12.2013 22:37:26
]]>
Статистика: Добавлено Лекс Айрин — 01.12.2013 20:42:05
]]>
и стоит ли вообще ее производить. Может случиться так, что весь выигрыш будет съеден накладными расходами.
В случае FPC однозначно стоит (ессно как только она по части SSE когда-нибудь будет допилена в компиляторе) - ведь на кону выигрыш в разы и даже десятки раз.
Статистика: Добавлено debi12345 — 01.12.2013 19:53:18
]]>
kazalex писал(а):Только это не повод отказываться от оптимизации там, где она приносит ощутимые плоды.
Там где она дает ощутимые плоды, результат виден на глаз... а это примерно 5-10% повышения производительности (а встречал мнение, что и все 30!) Следовательно, никакая синтетика не нужна. Да и оптимизация должна быть очень качественной.
kazalex писал(а):становится ясно какие части являются критичными для общей производительности.
и стоит ли вообще ее производить. Может случиться так, что весь выигрыш будет съеден накладными расходами.
Статистика: Добавлено Лекс Айрин — 01.12.2013 18:27:52
]]>
Лекс Айрин писал(а):Зачастую, производительность упирается в физические ограничения железа.
Более того, любая программа, по определению, ограничена возможностями железа. Только это не повод отказываться от оптимизации там, где она приносит ощутимые плоды.
Лекс Айрин писал(а):ТРот же код может быть так размазан по программе, что его и не выцепишь сразу.
Обычно, на этапе декомпозиции задачи становится ясно какие части являются критичными для общей производительности.
Статистика: Добавлено kazalex — 01.12.2013 18:08:40
]]>
А своими силами сделать вменяемую оптимизацию нынче не получится. Это только мануалы к процессорам годы курить надо.
Статистика: Добавлено Mirage — 01.12.2013 17:43:11
]]>
kazalex писал(а): Если за основу бенчмарка берется ресурсоемкий код реального приложения, то такой тест будет реально отражать положение дел.
Как говорил один профессор, "я всегда найду для вашего калькулятора задачу, которая ему не по зубам". Зачастую, производительность упирается в физические ограничения железа. И в таких случаях хоть оптимизируй, хоть забивай на это дело разница небольшая. ТРот же код может быть так размазан по программе, что его и не выцепишь сразу.
Статистика: Добавлено Лекс Айрин — 01.12.2013 15:52:20
]]>
Программирование*, Алгоритмы*, C++*
По мотивам одного вчерашнего поста про оптимизацию условных переходов при расчете x=sign(a,b)*min(abs(a), abs(b)) якобы в 10 раз. Краткая сводка:
оптимизация налицо, но размер мнимый: не в 10 раз, а 2.5 раза;
бенчмарки надо делать правильно: не надо мерить CPU stalls, RAM bandwidth итп вместо исследуемой функции;
бенчмарки надо делать правильно: иначе могут дико дрожать;
выставлять только приоритет прикольно, но на коротких бенчмарках зря: +0.5% скорости, -15% дрожания;
нужно мерить исследуемую функцию и только ее, только так получаешь корректные данные;
нужно греть проц, нужно считать минимум из N прогонов/секунд, только так побеждаешь дрожание;
нужно пользовать SSE, с ним получилось 8.6 раз, причем код… читается.
В общем, опять пачка классических методологических ошибок при бенчмарке. Кому интересно, как такие ошибки НЕ делать, подробности, детальный разбор полетов, оптимизация в еще несколько раз и, главное, исходники под катом.
Прочитал вчера исходный пост, очень удивился ускорению в 10 раз за счет ликвидации переходов, даром, что на синтетике. Это слишком много, переходы дорогие, но не настолько. Попробовал повторить результаты, посмотрел внимательнее, и натурально: опять детсадовские ошибки в методике бенчмарка! Что же, пора их опять разобрать, пример хороший.
Добавлено спустя 4 минуты 17 секунд:
Также важно чтобы компиятор умел строить SSE4+ инструкции :
На помощь приходит SSE. У меня на десктопе неновый Core2Duo E8500, но даже он умеет SSE4. Разворачиваем цикл в 4 раза, считаем по 4 пары зараз. Прямо в лоб пользуемся специнструкциями для вычисления sign, abs.
1.073 sec, llr() baseline
0.438 sec, llr2() optimized, 2.5x
0.125 sec, llr4() sse + 4x unroll, 8.6x
АФАЙК, FPC пока умеет SSE3-.
Статистика: Добавлено debi12345 — 01.12.2013 15:07:49
]]>
debi12345 писал(а):Да не в "холоде" там дело, а в оптимизаторе.
Речь не об этом частном случае, а об общем подходе.
Лекс Айрин писал(а):бейчмарки, как ни пиши, все равно не будут соответствовать реальным приложениям.
Это смотря как писать. Если за основу бенчмарка берется ресурсоемкий код реального приложения, то такой тест будет реально отражать положение дел.
Лекс Айрин писал(а):А как быть в тех случаях, когда нет принципиальной разницы между лучшим и худшим кодом? Ловить микросекунды из принципа?
Если нет разницы то и вопросы оптимизации кода/алгоритма обычно не возникают.
Статистика: Добавлено kazalex — 01.12.2013 11:15:48
]]>
Статистика: Добавлено Лекс Айрин — 01.12.2013 10:53:54
]]>
Код:
A := (((P1 + P2) * P1) / P2) - P1;FPC ускорился в 2 раза (теперь полсекунды).
G++ разобрался в ситуации лучше и заменил цикл на однократное умножение на лимит цикла - получили мгновенное (0 микросекунд) выполнение.
Меняем цикл на трудный для логической оптимизации (чтобы не избежать цикла и чтобы не было кэширования предыдущего значения)
Код:
for (i=0; i <= 99999999; i++ ) {
B = B + A + i;
}
Имеем :
G++ : 0.12 секунды
Код:
**** for (i=0; i <= 99999999; i++ ) {
**** // A = FasmAdd(P1, P2);
**** B = B + A + i;
cvtsi2sd xmm0, rax # tmp100, i
**** for (i=0; i <= 99999999; i++ ) {
add rax, 1 # i,
cmp rax, 100000000 # i,
addsd xmm6, xmm0 # B, tmp100
.LVL8:
**** for (i=0; i <= 99999999; i++ ) {
jne .L4 #,
**** }
4 команды, из которых 2 - SSE-набор. Все операторы - в регистрах проца.
FPC: 1.14 cекунды
Код:
.Lj21:
incl -32(%ebp)
fldt U_P$SSETEST_A
fldt U_P$SSETEST_B
faddp %st,%st(1)
movl -32(%ebp),%eax
movl %eax,-4(%ebp)
movl %eax,-16(%ebp)
movl $0,-12(%ebp)
fildq -16(%ebp)
faddp %st,%st(1)
fstpt U_P$SSETEST_B
cmpl $99999999,-32(%ebp)
jb .Lj21
13 команд, несколько SSE. Часть операндов - не в регистрах а в ОЗУ и возможно кэше проца (что намного тормознее)
Как результат, проигрыш в 10 раз.
Тут либо у FPC оптимизатор должен быть основным направлением совершенования. Либо G++ невероятно умен по этой части
попасть на холодное ядро"
Да не в "холоде" там дело, а в оптимизаторе. "-O3" оставляет операнды в регистрах, а "-O1" - в оперативке. Видимо обращение к оперативке быстрее пробуждает проц к 100% активности. Можно кстати удлиннить цикл - это уменьшит эффект от задержки на пробуждние
Статистика: Добавлено debi12345 — 01.12.2013 10:50:05
]]>
Лекс Айрин писал(а):Скорее всего, и в реальных приложениях код будет попадать на холодное ядро и тормозить. Что же это за прога, которую надо "разогревать"?
В реальных приложениях вероятность "попасть на холодное ядро" есть как у хорошего алгоритма так и у плохого. Вопрос в том, как определить - какой из них хороший, а какой плохой. Так вот, без предварительных мероприятий направленных на уменьшение влияния внешних факторов (как то: активные технологии энергосбережения или повышения производительности, высокая активность фоновых процессов, дисковый кэш ОС) невозможно корректно выявить какой из алгоритмов лучше или хуже. Поэтому бенчмарки писать не так просто, как кажется.
Статистика: Добавлено kazalex — 01.12.2013 10:36:58
]]>
debi12345 писал(а):Также видно, что умный (на максимальной оптимизации) G++-компилятор "раскусил" что "FasmAdd(P1, P2)" - чистая (зависящая только от входных аргументов) функция и поэтому ее достаточно выполнить один раз, закэшировать результат и потом его использовать в цикле как константу в регистре. FPC таким интеллектом пока еще не обладает.
Собственно Вами показан пример искусственного и сугубо синтетического теста, какими обычно пользуются маркетологи, призывая покупать нечто именно у них, а не у конкурента.
Алгоритмически ни один из приведенных примеров компиляторов не смог соптимизировать задачу, т.к. требовалось всего навсего результат функции вычислить один раз и умножить его на 99999999. Но все же один из компиляторов не стал вычислять некое выражение много раз, а другой тупо выполнил, что ему написали.
К реальности эти примеры не имеют ни какого отношения. Собственно я не вижу большой цены в оптимизаторе заведомо плохого кода. Тут оптимизировать должен программист, а не компилятор.
Составляя тесты, нужно думать головой. Написать хороший (качественный) тест для сравнения оптимизаторов не так уж и легко.
Статистика: Добавлено alexey38 — 01.12.2013 10:19:48
]]>
pda писал(а):У вас тест может показать, что более оптимальный код "работает" медленнее, потому что попал на холодное ядро.
Скорее всего, и в реальных приложениях код будет попадать на холодное ядро и тормозить. Что же это за прога, которую надо "разогревать"?
В любом случае, речь о конкретном наборе оптимизаций.. Я просто учел факт бесполезности выставления ключа О3 и все.
Статистика: Добавлено Лекс Айрин — 01.12.2013 10:00:05
]]>
pda писал(а):Чтобы адекватно мерять надо сначала привязывать главный поток к конкректному ядру (если измеряемый код однопоточный), а потом несколько секунд "греть" его, т.е. гонять в цикле какие-нибудь бессмысленные сложения, чтобы частотя ядра на максимум вышла. Иначе не результат, а цена на дрова будет.
Поддерживаю. Только привязывать и греть не обязательно. Достаточно выставить профиль энергосбережения на High performance (Control Panel\Power Options\High performance). У кого AMD Phenom, можно использовать PhenomMsrTweaker - он позволяет переключать профили из трея. Кстати, на ноутбуках тоже можно прифили в трее переключать.
pda писал(а): GetTickCount, вроде тоже может странные показания выдавать, если поток к одному ядру не привязан.
Только не GetTickCount, а QueryPerformanceCounter и только в случае некорректной реализации BIOS (я под VirtualBox'ом периодически ловлю некорректные показания). GetTickCount не рекомендуется для замеров по причине невысокой точности.
Статистика: Добавлено kazalex — 01.12.2013 00:29:05
]]>