В качестве предварительного этапа перед переходом FreeBSD на использование GCC 4.1, в FreeBSD-CURRENT будет обновлена (http://groups.google.com/group/muc.lists.freebsd.current/msg...) версия GCC до 3.4.6, затем, через некоторое время, GCC обновится и в RELENG6.
URL: http://groups.google.com/group/muc.lists.freebsd.current/msg...
Новость: http://www.opennet.ru/opennews/art.shtml?num=8227
Зачем оно надо?
Зачем оно не надо?
А самому почитать http://gcc.gnu.org/gcc-3.4/changes.html
никак?
Надо бы уже наверное переходить к четвёрке всё таки, надеюсь не сильно застрянем на 3.4.6 (ну при условии что 4.1 не окажется хуже, но вроде как линуксы уже перешли к этому компилятору)
В двух словах-то можете обьяснить, чем он лучше?
Пример:
Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30 сек.
>Пример:
>Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
>
>скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30
>сек.
Что такое FFT знаю, спасибо =)
Интересный результат.
То есть четвёртая ветка на большинстве задач быстрее третьей?
Дык, а причем тут компилятор? Это явно оптимизация библиотеки мат.функций.
Или вы думаете GCC4.x какие-то неведомые для GCC3.4 машинные операции использует?
А вы конечно думаете что к какой бибке линковаться выбирает компилятор?
Сильно изменили gcc'я от 3 к 4. Аффтары старались - changes писали. Так что дуйте на сайт да и станет вам ясно what & why ....
Бред какой-то. Какая еще оптимизация ручная что ли ?
Компиллер делает всю работу.
Оптимизация именно ручная, господа. Была и будет всегда... А компилятор всего лишь выполняет рутинную часть работы.
Хрестоматийный пример: Статическую функцию или статический параметр функции или константу в С++ можно таковыми не объявлять, на результат исполнения кода в большинстве случаев это не повлияет. Но в следствие этого, целый класс возможностей по оптимизации кода будет не доступен.
Так что, это по-вашему не оптимизация?! Впрочем вы хоть горшком обзовите, только в печь не ставьте... :)))Люди, знающие тонкости реализации gcc, легко могут представить такую реализацию FFT, что gcc4.1 будет проигрывать даже gcc2.95...
Все же gcc4.1 это лишь инструмент, который в руках грамотного специалиста при прочих равных даст лучший результат. Но сам по себе никаких сверхвозможностей не несет.PS. Я потрясен, что сам L.Torvalds удостоил своим вниманием мою скромную реплику. :)))
Позвольте вам выразить свое почтение. :))))
Согласен можно написать такой исходник что любой компилятор голову сломает
Но обычно FFT не стандартная и иснодники пишутся или качаются из сети
А товарищ говорил именно о каких то стандартных мат функсиях
О том собственно и речь. Тут скорость зависит от реализации конкретных алгоритмов.
В бытность свою студентом (были же времена) мы изучали Теорию компиляторов и на лабораторных проводили исследования по оптимизации кода. Увеличение скорости работы алгоритма на 5-6 процентов в результате общей оптимизации (т.е. без использования фич зависящих от конкретной аппаратной платформы)считалось просто невероятным прорывом, при условии, что алгоритм реализован оптимально на уровне языка программирования.
Поэтому для меня такие цифры 45 сек. и 30 сек. в отношении одной и той же реализации FFT выглядят умопомрачительными. Либо в GCC 3.4.4 просто отвратительный оптимизатор (а мой опыт говорит, что это не так) либо какая-то совсем экзотическая реализация FFT.
Опять же тут еще зависит от массива входных данных. Если на этом массиве FFT работает двое суток, то 15 сек разницы вполне адекватный результат. :))))Поэтому я и интересуюсь, откуда дровишки...
Разница в 15 сек за 2 суток не показатель и может быть связана с загруженностью систему
(системные вызовы ну и еже с ними) Но тут то 30% ето обалдеть
Хотя нрен его знает я пробовал компилить программу MD (molec. dynamics)Intel компиллером
в режиме -fast и без него и разница была 6 и 18 минут. Хотя это не совсем тот пример но
всеже компиллер тоже кое что могет.
Хех... Интеловские компилеры - это вообще песня.
Как-то давно мой однокашник после долгих ковыряний интелового компилера С с профилером поделился открытием, что скорость работы бинарника там может зависеть от того, на системе с каким процем его собирали.
И что бинарник собранный на iP-III отличается от бинарника собранном на iCel. Бинарник собранный под iP-III на Celeron'е сильно тормозит, а наоборот - нет.
>Пример:
>Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
>
>скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30
>сек.Кстати, а откуда эта информация? Ткните носом. Интересно было бы глянуть исходный текст. Что-то уж слишком существенная разница.
ну у меня не такой большой прирост, но тоже наблюдался при использовании ФФТ из библиотеки FFTW после пересборки оной с gcc4.1
косяк вынь...результат сравнивается на одинаковом коде. а то что можно написать хитрый код который будет давать противоречивые значения я и сам знаю.
это был ответ northbear
>косяк вынь...
>А что это значит? Переведи на русский.
>>косяк вынь...
>>
>
>А что это значит? Переведи на русский.
это значит нестоит курить смешную траву :)
>>>косяк вынь...
>>>
>>
>>А что это значит? Переведи на русский.
>
>
>это значит нестоит курить смешную траву :)Ясно. Меня смутило слово "вынь". :))
На счет содержательной части сообещния, я тоже имел ввиду компиляцию одного и того же кода разными компиляторами. Подробней в 20-м сообщении здесь.
На самом деле производительность будет различаться на разных задачах и разном коде.
Вот для примера - кодирование звука на примере lame и flac (и скорость их сборки).
Протестированы:
gcc version 3.4.4 [FreeBSD] 20050518
gcc version 4.0.4 20060824 (prerelease) [FreeBSD]
gcc version 4.1.2 20060825 (prerelease)
gcc version 4.2.0 20060819 (experimental)Каждый тест проводился 4 раза, взято среднее значение real time. Результаты соответственно 3.4, 4.0, 4.1, 4.2.
Сборка lame:
34,51 38,79 43,05 76,05Сжатие lame:
39,17 41,65 40,17 40,88Сборка flac:
85,54 81,50 93,19 160,84Сжатие flac:
65,55 53,99 56,53 56,58Я бы особо не спешил с переходом на gcc 4.x.