Скорость SSE с разными оптимизациями: -O1 и -O3

[Лекс Айрин]

Ты зря называешь бенчмаркинг рабочего кода синтетикой.

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

и отставание в четверть секунды превратится в четыре минуты.

А разве 4 минуты не видны на глаз? Хотя... можно так заопримизировать, что придется вводить циклы задержки.

[kazalex]

Самым корректным сравнением было бы написание версий с разными алгоритмами работы/оптимизациями

Так с самого начала об этом речь. Я же не о жонглировании опциями оптимизатора говорил.

А разве 4 минуты не видны на глаз?

Это видно, когда случилась такая нагрузка. На момент проектирования если об оптимизации не думать то и не видно ничего. Более того, как я уже говорил, можно думать будто алгоритм быстр, а на деле окажется не так. И такие моменты ничем кроме бенчмаркинга не ловятся. Вообще, нагрузочное и эталонное тестирование желательно делать на объемах работы которые сильно превышают видящиеся на данный момент, и в этом есть определенный смысл

[Лекс Айрин]

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

Вообще-то правильнее создать работающее приложение, а потом уже думать об его оптимизации. Иначе получается дележ шкуры не убитого медведя. А опции компилятора (жонглирование) выставляются сразу и сразу же, по идее, влияют на производительность и/или размер программы.

[kazalex]

Вообще-то правильнее создать работающее приложение, а потом уже думать об его оптимизации

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

А опции компилятора (жонглирование) выставляются сразу и сразу же, по идее, влияют на производительность и/или размер программы.

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

[Лекс Айрин]

В этом случае имеется немалый шанс обеспечить себя работой по переписыванию всего/большей части приложения.

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

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

FPC не Си с плюсами, Я Lasarus скачиваю, переустанавливаю и перекомпилирую в процессе утреннего/вечернего просмотра новостей. Под любой из трех осей, в которых работаю. А настройки оптимизации я вбиваю сразу же при создании проекта и забываю о них.

[kazalex]

И что?

Да ничего. Только это мазохизм.

Лучше оптимизировать неработоспособную программу?

А откуда эта идея, что если оптимизированная то значит обязательно неработоспособная? Тут стоит заметить, что оптимизированная совсем не означает, что там клубок низкоуровневых трюков. Последним, как раз, страдают прематурщики не понимающие, что выигрыш от таких плясок минимален, а код стремительно превращается во write only.

FPC не Си с плюсами

Несомненно. Как и качество его оптимизаций. Тем не менее, компилирует он значительно дольше чем та же Delphi. Но речь скорее об общем подходе, не все же pascal-only разработчики.

[Лекс Айрин]

А откуда эта идея, что если оптимизированная то значит обязательно неработоспособная?

Конечно, не обязательно, но откуда тогда в прогах столько глюков?

Тем не менее, компилирует он значительно дольше чем та же Delphi.

Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.

Но речь скорее об общем подходе, не все же pascal-only разработчики.

Форум-то для паскалевских программистов.

[debi12345]

Тем не менее, компилирует он значительно дольше чем та же Delphi.

Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.

100% логично (даже не задумываешься сколь компилируется FPC-программа - отвернешься, а она уже готова), но хотелось бы чтобы более долгая компиляция объяснялась более тщательной оптимизацией. Пусть даже будет режим компиляции в 100раз медленнее чем обычно - но с оптимизацией уровня GCC/G++.

[Лекс Айрин]

debi12345, согласен. Более тщательная оптимизация вполне нормальная цена за более долгую оптимизацию.

[kazalex]

Конечно, не обязательно, но откуда тогда в прогах столько глюков?

От низкой культуры разработчиков, от чего же еще.

Знаешь, разница между 1 и 2-3 минутами для меня не принципиальна.

На этапе прототипирования скорость получения результата очень важна.

Форум-то для паскалевских программистов.

Вот только обсуждаемый вопрос значительно шире.

[Лекс Айрин]

От низкой культуры разработчиков, от чего же еще.

От желания писать код быстро, вообще-то. Вот и забивают на полноценное тестирование.

На этапе прототипирования скорость получения результата очень важна.

Так прототипирование это не более чем черновые наброски.
Если позволена будет аналогия с написанием художественным текстом, то это канва произведения. Но если в канве окажутся неточные куски (а то и она вся), то они переписываются уже после написания более-менее значительного объема, когда обнаруживается ее фальш.
И, кстати, я не пишу прототипов. Они мне не нужны. Я сам себе заказчик и мне вполне хватит умения развалить проект на составляющие и переписать его заново с более оптимальным алгоритмом. Или начать его писать снизу, а не сверху, примерно представляя результат.

[kazalex]

Вот и забивают на полноценное тестирование.

Это и есть культура разработки и разработчиков.

Так прототипирование это не более чем черновые наброски.

Только эи черновые наброски позволяют выкристализовать/выбрать направление разработки алгоритмы и структуры данных для решения задачи. И процесс этот может быть весьма длительным. Кстати, именно на этом этапе наиболее часто используется отладчик, который очень не дружит с компиляторными оптимизациями.

И, кстати, я не пишу прототипов. Они мне не нужны.

Все, разумеется, зависит от сложности решаемых задач.

[Лекс Айрин]

Все, разумеется, зависит от сложности решаемых задач.

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

[debi12345]

Что значит задействованная оптимизация :

и

то есть около 30-ти (!!!) раз относительно одно-операндного (нынешнего FPC) варианта.

Вся статья : http://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions

[alexey38]

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

На ранней стадии разработки нужно просто исследовать отдельные новые алгоритмы. А из предыдущего опыта уже знать правильные алгоритмы.

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