bobr пишет:
По-моему (опять-таки, жаль не могу прямо сейчас проверить, нет этого компьютера под рукой), native будет включать просто -march=core2
это зависит от gcc и от самого камня, но ничего страшного.
В моем случае так и будет. (Intel Atom n270 и GCC 4.4)
]]>по этому в результате экспериментов и было доказано, что дальше -О2 -pipe -fomit-frame-pointer и указания -march при компиляции всего юзерленда уходить не стоит.
аесли взять моно приложение.. я боюсь представить.
на вашем железе, с вашими приложениями - да, конечно.
как я понял, беда -O3 в том, что разных глюков полно, и кеш - тоже...
В конце концов, любая оптимизация - это компромисс. Часто ускорения можно достичь например вынося данные в память, а не вычисляя их каждый раз, но если так делать для ВСЕГО, то это ни к чему хорошему не приведёт. Что вовсе не мешает кодеру вынести критичные участки в отдельные модули, и компилировать их с опцией -O3, а остальные 95% кода на быстродействие не влияют, их можно вообще никак не оптимизировать. Тогда никаких лишних расходов памяти не будет. Вот только, что-бы так писать, лучше использовать разные языки вперемешку, или один низкоуровневый, вроде чистого С, а это долго, дорого и муторно.
можно использовать конечно другие флаги, но только к определённому софту, прочитав сначала про него.
иначе получим тормоза на атоме при проигрывании обычного mp3. и не ясно кто виноват, плеер или вообще libc6.
угу. но я предлагаю даже не софт целиком компиллить с -O3, а лишь некоторые модули. Но вот вынес-ли кодер эти модули в отдельные исходные файлы? Учёл-ли он это в Makefile? Скорее всего - нет. Потому по факту - вы совершенно правы.
ещё недавно, скомпилировав браузер с этой опцией вы получили бы быстрый как ракета софт.
щаз! получится тормозное глюкалово, которое жрёт немеренно памяти.
]]>и ваши рассуждения о ядрах для него бесполезны
мои рассуждения о ядрах были исключительно в контексте -О3.
но забываете, что ещё недавно этих 2х ядер ни у кого попросту не было.
ещё недавно, скомпилировав браузер с этой опцией вы получили бы быстрый как ракета софт. а сейчас получите тот же ФФ который просто не уместится в оперативной памяти ноутбука с одной вкладкой открытой. аесли взять моно приложение.. я боюсь представить.
по этому в результате экспериментов и было доказано, что дальше -О2 -pipe -fomit-frame-pointer и указания -march при компиляции всего юзерленда уходить не стоит.
можно использовать конечно другие флаги, но только к определённому софту, прочитав сначала про него.
иначе получим тормоза на атоме при проигрывании обычного mp3. и не ясно кто виноват, плеер или вообще libc6.
наверное уговаривая себя что это быстро..
это было БЫСТРЕЕ. да, причём тут "быстро"?
я вам простите ман gcc процитировал, а вы меня к нему отсылаете.
а маны они отличаются в разных системах и для разных версий gcc. о чём я и говорю - спорить бесполезно, от -O3 результат непредсказуемый, если не договорится о версии. А о версии мы не договорились. Вы так уверенно излагаете "только для 2х ядер", но забываете, что ещё недавно этих 2х ядер ни у кого попросту не было.
В разрезе сабжа это важно - у человека явно плохо с ресурсами, раз ему плеер нужен "экономичный", и ваши рассуждения о ядрах для него бесполезны - ведь уже со второго пня можно легко смотреть кино, а уж mp3 ЕМНИП и на i80486 не тормозил.
]]>А как я на iPI, iPI-MMX, iPII, iPIII использовал?
наверное уговаривая себя что это быстро.. я вам простите ман gcc процитировал, а вы меня к нему отсылаете.
]]>cat ./wave-file.au > /dev/dsp? :-)
]]>так что -O3 лучше использовать тем, у кого 2+ ядра.
угу. с "маленьким", "если-бы"... А как я на iPI, iPI-MMX, iPII, iPIII использовал? тут очень от многого зависит, это совсем не тривиальный процесс.
На самом деле, все эти О1, Оn - просто пресеты, созданные разработчиками компилятора, что-бы кодеры голову не забивали. В разных компиляторах опции работают по разному (за исключением -O0 которая вырубает всё, и -O3 которая всё врубает), можно мануал почитать, а не спорить. Или попробовать. Да, кстати, лучше не компиллить всё с одними флагами, а покрутить Makefile, и скомпиллить лишь критичные модули с -O3, а остальное с -O0, или возможно с -Os, тогда результат будет наилучшим. Примерно так подошли к делу создатели mplayer'а, и получили неплохой результат.
а иногда - помогает.
на процессорах с маленьким кешем, раздувшиеся от этого ключа программы могут вызвать падение производительности на рандомное количество процентов. а если они ещё своих друзей с жесткого диска теранят, то нагрузка в 2 раза больше на хард, и для них нужно в два раза больше оперативной памяти.
так что -O3 лучше использовать тем, у кого 2+ ядра.
По-моему (опять-таки, жаль не могу прямо сейчас проверить, нет этого компьютера под рукой), native будет включать просто -march=core2
это зависит от gcc и от самого камня, но ничего страшного.
]]>
. Некоторые программы не могут быть скомпилированы с этим флагом.2. Ну если вам все же не жалко памяти, то советовал бы вам пересобрать кодек и плеер с параметром
-Оэто увеличит размер но повысит производительность.
]]>и упаси боже не -O3
а иногда - помогает. иногда даже -Os помогает (но реже ИМХО).
]]>Т.ч. прошу прощения 