|
| 1.4, Bocha (??), 09:03, 28/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Надо бы уже наверное переходить к четвёрке всё таки, надеюсь не сильно застрянем на 3.4.6 (ну при условии что 4.1 не окажется хуже, но вроде как линуксы уже перешли к этому компилятору) | | |
| |
| 2.5, Dyr (??), 12:28, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 В двух словах-то можете обьяснить, чем он лучше? | | |
| |
| 3.6, pavlinux (??), 13:17, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
 Пример:
Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30 сек.
| | |
| |
| 4.7, Dyr (??), 13:24, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Пример:
>Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
>
>скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30
>сек.
Что такое FFT знаю, спасибо =)
Интересный результат.
То есть четвёртая ветка на большинстве задач быстрее третьей? | | |
| 4.8, northbear (??), 14:44, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
Дык, а причем тут компилятор? Это явно оптимизация библиотеки мат.функций.
Или вы думаете GCC4.x какие-то неведомые для GCC3.4 машинные операции использует? | | |
| |
| 5.9, L.Torvalds (?), 17:09, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
А вы конечно думаете что к какой бибке линковаться выбирает компилятор?
Сильно изменили gcc'я от 3 к 4. Аффтары старались - changes писали. Так что дуйте на сайт да и станет вам ясно what & why .... | | |
| 5.10, vvv (??), 19:41, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
Бред какой-то. Какая еще оптимизация ручная что ли ?
Компиллер делает всю работу. | | |
| |
| 6.11, northbear (??), 21:32, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
Оптимизация именно ручная, господа. Была и будет всегда... А компилятор всего лишь выполняет рутинную часть работы.
Хрестоматийный пример: Статическую функцию или статический параметр функции или константу в С++ можно таковыми не объявлять, на результат исполнения кода в большинстве случаев это не повлияет. Но в следствие этого, целый класс возможностей по оптимизации кода будет не доступен.
Так что, это по-вашему не оптимизация?! Впрочем вы хоть горшком обзовите, только в печь не ставьте... :)))
Люди, знающие тонкости реализации gcc, легко могут представить такую реализацию FFT, что gcc4.1 будет проигрывать даже gcc2.95...
Все же gcc4.1 это лишь инструмент, который в руках грамотного специалиста при прочих равных даст лучший результат. Но сам по себе никаких сверхвозможностей не несет.
PS. Я потрясен, что сам L.Torvalds удостоил своим вниманием мою скромную реплику. :)))
Позвольте вам выразить свое почтение. :)))) | | |
| |
| 7.18, чч (?), 17:44, 29/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
Согласен можно написать такой исходник что любой компилятор голову сломает
Но обычно FFT не стандартная и иснодники пишутся или качаются из сети
А товарищ говорил именно о каких то стандартных мат функсиях | | |
| |
| |
| 9.22, vvv (??), 09:46, 30/08/2006 [^] [^^] [^^^] [ответить] | +/– | Разница в 15 сек за 2 суток не показатель и может быть связана с загруженностью ... текст свёрнут, показать | | |
|
|
|
|
|
| 4.14, northbear (??), 23:07, 28/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>Пример:
>Маленькая хрень (программка) с FFT (Fast Fourier Trans. aka Шустрое Преобразование Фурьёвича),
>
>скомпиленая на 3.4.4 работат ~ около 45 сек., на 4.1.1 около 30
>сек.
Кстати, а откуда эта информация? Ткните носом. Интересно было бы глянуть исходный текст. Что-то уж слишком существенная разница. | | |
| |
| 5.17, antonmx (?), 11:29, 29/08/2006 [^] [^^] [^^^] [ответить]
| +/– | |
ну у меня не такой большой прирост, но тоже наблюдался при использовании ФФТ из библиотеки FFTW после пересборки оной с gcc4.1 | | |
|
|
|
|
| 1.12, emp (??), 22:38, 28/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
косяк вынь...
результат сравнивается на одинаковом коде. а то что можно написать хитрый код который будет давать противоречивые значения я и сам знаю. | | |
| |
| |
| 3.19, emp (??), 18:45, 29/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>косяк вынь...
>>
>
>А что это значит? Переведи на русский.
это значит нестоит курить смешную траву :)
| | |
| |
| 4.21, northbear (??), 08:02, 30/08/2006 [^] [^^] [^^^] [ответить]
| +/– |
>>>косяк вынь...
>>>
>>
>>А что это значит? Переведи на русский.
>
>
>это значит нестоит курить смешную траву :)
Ясно. Меня смутило слово "вынь". :))
На счет содержательной части сообещния, я тоже имел ввиду компиляцию одного и того же кода разными компиляторами. Подробней в 20-м сообщении здесь.
| | |
|
|
|
| 1.23, Аноним (-), 22:33, 30/08/2006 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На самом деле производительность будет различаться на разных задачах и разном коде.
Вот для примера - кодирование звука на примере 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. | | |
|
