URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 81607
[ Назад ]

Исходное сообщение
"Оценка производительности GCC на новых процессорах AMD"

Отправлено opennews , 04-Дек-11 21:07 
Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=gcc_42_47...) тестировние производительности кода, собранного различными версиями GCC (4.2.4, 4.3.6, 4.4.6, 4.5.3, 4.6.1 и 4.7-dev). Тестирование было выполнено на системе с процессором AMD FX-8150, основанным на новой архитектуре AMD Bulldozer. Сборка была произведена с опциями "-march=native -mtune=native -O3".


В тесте C-Ray отмечается заметное повышение производительности при использовании тестового снапшота GCC 4.7. В тестах LAME и  Flac заметен небольшой прирост производительности при использовании GCC 4.7. В тестах 7-Zip и FFmpeg все версии GCC показали примерно одинаковые результаты. В тесте GraphicsMagick отмечается существенное замедление работы при использовании GCC 4.7, в  то время как GCC 4.6.1 показал наилучшие результаты. При измерении времени сборки PHP и Apache, отмечается небольшое уменьшение скорости сборки в GCC 4.7.
<center><img src="http://www.opennet.me/opennews/pics_base/3...

URL: http://www.phoronix.com/scan.php?page=article&item=gcc_42_47...
Новость: http://www.opennet.me/opennews/art.shtml?num=32461


Содержание

Сообщения в этом обсуждении
"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 04-Дек-11 21:11 
зачем -O3 ??

"Оценка производительности GCC на новых процессорах AMD"
Отправлено XPEH , 04-Дек-11 21:34 
Патамушта эта крута. Фороникс же.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 15:14 
> Патамушта эта крута. Фороникс же.

Ну вы же не сделали бенчмарков лучше. Вот и приходится довольствоваться форониксом.

Ну, покажите всем вашу круть! Сделайте лучше! (А мы обосрем, как вы фороникс)


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 04-Дек-11 21:39 
> -march=native -mtune=native

Что за нелепый набор опций? AFAIK, -march оптимизирует под конкретную модель процессора с потерей совместимости со всеми остальными, -mtune оставляет совместимость ценой недостаточной оптимизации (т.е., например, инструкции нового процессора не используются)


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Анонимко , 04-Дек-11 22:17 
>-march оптимизирует под конкретную модель процессора

А что по-твоему делает -mcpu?


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 04-Дек-11 22:22 
Это устаревший аналог -mtune

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 00:56 
> с потерей совместимости со всеми остальными, -

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


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 01:10 
Для этого есть -march, и как раз его надо было использовать. Для сохранения совместимости есть -mtune, а Похороникс умудрился заюзать оба сразу. Это похоже на попытки ниасилившего ман ламера напихать побольше ключей, "шоп наверняка". Хорошо еще, что не указали сразу x86 и x64

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 08:40 
> Для этого есть -march, и как раз его надо было использовать. Для
> сохранения совместимости есть -mtune, а Похороникс умудрился заюзать оба сразу.

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

> Это похоже на попытки ниасилившего ман ламера напихать побольше ключей, "шоп наверняка".
> Хорошо еще, что не указали сразу x86 и x64

Да я не сомневаюсь что лэйбаки клеить проще чем бенчи проводить. Поэтому читаем мы все-таки похороникса, у которого хоть какие-то бенчи есть.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Клован , 05-Дек-11 09:10 
Да, все верно. Но компилируется же исходник на стороне пользователя, и ему такая оптимизация очень даже.
А... Забыл, на линуксе ведь все распространяется через собранные где то там под каким то там железом пакеты? Ну чтож, ССЗБ. Этой проблемы в FreeBSD нет например. Потому что опенсорс - это способность собирать из сорцов. И не надо кричать, что "долго ждать пока все соберется" - при сегодняшних мощностях железа это уже минуты.  

"Оценка производительности GCC на новых процессорах AMD"
Отправлено daks , 05-Дек-11 10:56 
Открой для себя Gentoo и производные (Sabayon, Calculate и тп.), о юный адепт бсд. Хотя чё й то я такого толстого кормлю..

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Клован , 05-Дек-11 12:05 
> Открой для себя Gentoo и производные (Sabayon, Calculate и тп.)

Спасибо, только закрыл.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:19 
> Спасибо, только закрыл.

Судя по тому, как вы распространялись выше о бинарных линуксах, слово gentoo вы явно увидели в первый раз.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:18 
> Забыл, на линуксе ведь все распространяется через собранные где то там под каким то там железом пакеты? Ну чтож, ССЗБ. Этой проблемы в FreeBSD нет например.

Вранье. Во фре тоже бинарные пакеты =)


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:24 
> Да, все верно. Но компилируется же исходник на стороне пользователя, и ему такая оптимизация очень даже.

Как показывали неоднократные бенчмарки, компиляция под конкретный проц дает в среднем 1-2% прироста производительности. С точки зрения обычного пользователя, игра не строит свеч.

> И не надо кричать, что "долго ждать пока все соберется" - при сегодняшних мощностях железа это уже минуты.

Ну, если кому-то мамочка постоянно дает деньги на топовый игровой комп...
А у людей, которые ценят свои деньги и адекватно расходуют их, компы обычно не самые топовые. И на установку крупных пакетов софта могут уходить часы. Учитывая необходимость периодических обновлений, этот пресловутый 1% прироста в любом случае не оправдан.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено фтыш , 05-Дек-11 14:19 
Ох уж эти сказочники.
У меня на одноядерном атлоне за 5 лет использования генту статистика дает следующее - на сборку тратится в среднем 5-10 минут 100% загрузки CPU в день.
Да у меня проигрывание видео с pp7,hqdn3d,gradfun на порядок-два больше забирает ресурсов.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено FractalizeR , 05-Дек-11 14:31 
GIMP сколько собирается?

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Он , 28-Дек-11 17:02 
Wed Oct 19 18:27:52 2011 >>> media-gfx/gimp-2.6.11-r5
       merge time: 4 minutes and 12 seconds.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено vayerx , 05-Дек-11 15:08 
specifying -march=cpu-type implies -mtune=cpu-type

-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.

-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 00:12 
Да фигня это все. Сегодня есть проблема, а завтра пофиксили. В Bulldozer есть издержки из-за архитектуры, но и это компенсируется с лихвой. Сейчас качество софта и прямота рук программиста куда важнее чем микрооптимизация.

P.S.: А с -O3 я бы не стал собирать, так как бывают проблемы. Кому интересно - попробуйте собрать zlib, firefox (вероятно в новых версиях уже пофиксили).


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 08:57 
> P.S.: А с -O3 я бы не стал собирать, так как бывают проблемы.
> Кому интересно - попробуйте собрать zlib, firefox (вероятно в новых версиях уже пофиксили).

Бывают, факт. Что-то сверх -O2 и -Os - для любителей поэкспериментировать.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено anonymous , 05-Дек-11 00:12 
И откуда такая регрессия в производительности? gcc начал скатываться?

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 01:06 
>И откуда такая регрессия в производительности? gcc начал скатываться?

Нет, скорее регрессия от того что архитектура новая и, как и полагается, под новую архитектуру надо соответствующие способы тюнинга кода. Ничего страшного в этом нет - код дополнят/доработают под новые требования.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено anonymous , 05-Дек-11 03:32 
4.7 != 4.6, и выйдет только в марте или апреле 2012г. http://gcc.gnu.org/ml/gcc/2011-11/msg00200.html

Ваш К. О.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено ананим , 05-Дек-11 06:43 
Угу.
В 3 тестах увеличение производительности, в 2 примерно таже и в 1 уменьшение.
Тролячий вывод на лицо — ажназначна начал скатываться.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 08:58 
> И откуда такая регрессия в производительности? gcc начал скатываться?

Наверное оттуда что это хрензнаеткакая экспериментальная версия :)). А вам gcc чем-то мешает жить что вы ему пытаетесь приписать что-нить нелестное?


"Оценка производительности GCC на новых процессорах AMD"
Отправлено kuku , 05-Дек-11 10:19 
Первое
Знаешь, я незнаю строение компилятора, но знаю одно:
что на стадии генерации инструкции процессора происходит
глубокий анализ и переработка инструкции в несколько
проходов. А это значит, что компилятор на N-ом проходе
по тем или иным признакам ищет цепочку инструкций которую
можно оптимизировать.

Второе
С архитектурой процессоров знаком ? Например, что такое
конвейер ? Сколько их в ядре ? Сколько ядер в процессоре ?
Сколько процессоров в системе ? Сколько диспетчеров, то есть
координирующих узлов в системе или процессоре ?
А может это не процессор, а нечто имеющее несколько
вычислительных узлов и мощный, многоуровневый менеджер памяти ?

Третье
Компилятор поддерживает ли "специфику" той системы на которой он
работает ? Хорошо ли согласуется выполнение программы с
операционной системой ?

Подумай...
Посмотри на PathScale...

А GCC эээ... это как бы компилятор рассчитанный на поддержку
многих платформ, или систем, кому как. То есть что-то близко
к универсальному... Да ?

Если есть ошибки поправьте.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 00:49 
Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на 2% быстрее.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено dalco , 05-Дек-11 07:52 
Зависит от...

Если софтина будет годами крутиться на кластере из тысяч нод, то, ясен пень, лишние сутки сборки роли не играют.

Если требуется замутить нечто одноразовое, выдающее результат через 10 секунд расчетов, то ждать сборки лишние сутки, мягко говоря, не оптимально.

Ваш К.О.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 09:06 
>кластере из тысяч нод
>AMD

Сомнительно.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 09:55 
http://www.nccs.gov/computing-resources/jaguar/

"Оценка производительности GCC на новых процессорах AMD"
Отправлено iZEN , 05-Дек-11 09:48 
> Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на 2% быстрее.

В системах с непрерывной интеграцией ВАЖНО сколько времени отводится на сборку ПО. Так как непрерывный цикл разработки предполагает быстрые изменения, а C++ ещё не научили модульности на уровне исходного кода (в отличие от Pascal и Java), когда единицей компиляции является один файл, а для его компиляции нужны только уже откомпилированные бинарные модули (.tpu в архаичном Borland Pascal, .dcu в устаревшем Delphi, .class в Java и т.д.). Для сборки больших C++ программ приходится изобретать различные ухищрения, так как компиляция фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает непозволительно много времени.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:12 
я конечно, не профессионал, но... *.o файлы не то же самое?

и Pascal и Java "компилируются" в байткод.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 15:26 
> В системах с непрерывной интеграцией ВАЖНО сколько времени отводится на сборку ПО.

Отсюда вытекает мораль: тебе и твоей бсде в продакшне делать нечего. Большинству людей в хрен не вперлась какая-то там непрерывная интеграция, им непрерывно работающие системы нужны. Стабильно. Чем системы с непрерывной интеграцией как-то не очень могут похвастать - такой принцип автоматически подразумевает риск отвала башки.

Для сравнения: в бинарном дистре линукса на компиляцию тратится 0 минут 0 секунд, а грабли с пакетами вообще майнтайнеры разгребают. Что как-то сильно рулит когда надо достигать результатов а не страдать фигней с постоянной пересборкой там и тут.

> Так как непрерывный цикл разработки предполагает быстрые изменения, а C++ ещё
> не научили модульности на уровне исходного кода (в отличие от Pascal и Java),

С нетерпением жду когда ты уже перепишешь свою систему на паскаль или яву :D

> фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает
> непозволительно много времени.

Так и скажи, не осилил пересборку только измененного :)


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Ytch , 05-Дек-11 22:46 
>> фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает непозволительно много времени.
> Так и скажи, не осилил пересборку только измененного :)

Еще про precompiled header расскажи...


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 22:45 
.tpu в архаичном Borland Pascal, .dcu в устаревшем Delphi, .class в ненужной Java

извините, не удержался :)


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 22:59 
В основном C++ долго компилируется, т.к. язык намного сложнее для разбора, в сравнении с Pascal/Java. Это плата за те выразительные возможности, гибкость и мощь, который получает разработчик.

Меры ускорения сборки в C++ (то что сходу вспомнил):
- предварительные объявления в .h-файлах вместо инклудов
- идиома PIMPL (по крайней мере для библиотечных классов и классов инструментария проекта)
- закешированные скомпилированные единицы трансляции (объектные файлы .o) не перекомпилируются при следующей сборке, пока сами исходники не изменятся
- грамотно разбивать части проекта на отдельные либы (пусть даже статические), подпроекты и приложения - чтобы каждый раз не собирать 100500 исходников
- делать прекомпилированные хедеры
- для сборки на многоядерных процах - использовать опцию -j
- есть также системы для сборки проекта на нескольких компах
- не использовать ущербный mingw (не сидеть под оффтопиком), писать на linux, а под оффтопик кросскомпилировать через линуксовый mingw только для финальных релизов и тестов (если позволяет проект)

В общем, если сильно захотеть - всё делается. К тому же эти вещи нужно бы делать вне зависимости от наличия/отсутствия модульности, т.е. это не "различные ухищрения". И да, как бы вам не нравился C/C++ - но других языков с такой же эффективной компиляцией в нативный код не придумали пока, да и не нужно. Про управляемый код даже говорить не буду - попросту не нужно.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:27 
> Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на
> 2% быстрее.

Если обновлять хотя бы раз в месяц, то 2% явно не оправдают потери 1/30 (3,3%) рабочего времени.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 13:28 
> Если обновлять хотя бы раз в месяц, то 2% явно не оправдают

А обычно оно гораздо меньше, повезет, если больше одного процента.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 15:27 
> А обычно оно гораздо меньше, повезет, если больше одного процента.

Correct. Но бывают случаи когда некое сочетание параметров может выстрелить и в пару раз. Типа как pathscale на амд в бенчах фороникса на паре тестов.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 09:38 
У меня ОпенФоам, который окончательные вычисления делает больше недели на i7....
О3 - дает 10-30% ускорения (зависит от модели)
мне не ставить О3?

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 10:42 
с флагом компиляции -O3 велика вероятность получить глючный исполняемй код.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено Аноним , 05-Дек-11 15:19 
С этим флагом велика вероятность не получить вообще никакого кода.

"Оценка производительности GCC на новых процессорах AMD"
Отправлено okruzhor , 05-Дек-11 18:00 
Извините , что мимо темы . Не нашёл , куда сообщать о технических проблемах . Не к модераторам же стучать ...

На многих беседах (и на этой тоже) одна беда : нельзя получить плоский вид с сортировкой постингов по времени . Нажатие на "сортировку по времени" переносит в "Релиз Linux-дистрибутива ZevenOS 4.0 ...."


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Maxim Chirkov , 05-Дек-11 22:34 
> На многих беседах (и на этой тоже) одна беда : нельзя получить
> плоский вид с сортировкой постингов по времени . Нажатие на "сортировку

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

> по времени" переносит в "Релиз Linux-дистрибутива ZevenOS 4.0 ...."

Такое ощущение, что у вас из локального кэша это выдаётся без обращения к сайту.


"Оценка производительности GCC на новых процессорах AMD"
Отправлено okruzhor , 07-Дек-11 16:34 
>> На многих беседах (и на этой тоже) одна беда : нельзя получить плоский вид с сортировкой постингов по времени . Нажатие на "сортировку по времени"
> На какой странице (в новостях или форуме) и на какую именно ссылку вы нажимайте ? Каким браузером пользуйтесь. Выход в сеть не через прокси ?

На этой самой (новость) , ссылка "сортировка по времени" :-)

Opera 11.52 . Через прокси

> Такое ощущение, что у вас из локального кэша это выдаётся без обращения к сайту.

Да . У меня была отключена проверка обновления файлов в кэше . Получается , что для различных страниц с "сортировкой времени" генерируется одно и тоже имя файла в кэше ?

Включил такую проверку "всегда" . Сработало , после того как обновил страницу с сортировкой по ответам

Спасибо !


"Оценка производительности GCC на новых процессорах AMD"
Отправлено okruzhor , 07-Дек-11 16:40 
Хм! Продолжаю оффтоп . Править моё сообщение движок не даёт , мол "не ваше" . Однако создавать сообщение под своим ником я могу ! Значит всяк может постить с любым ником ? Пробовать не хочу , но это странная авторизация ...


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Maxim Chirkov , 07-Дек-11 17:06 
> Хм! Продолжаю оффтоп . Править моё сообщение движок не даёт , мол
> "не ваше".

Править свои тексты можно войдя в форум как зарегистрированный пользователь.

> Однако создавать сообщение под своим ником я могу. Значит всяк может постить с любым ником ?

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


"Оценка производительности GCC на новых процессорах AMD"
Отправлено Maxim Chirkov , 07-Дек-11 17:03 
> Да . У меня была отключена проверка обновления файлов в кэше .
> Получается , что для различных страниц с "сортировкой времени" генерируется одно
> и тоже имя файла в кэше ?

Да, при нажатии на ссылку сортировки по времени вызывается один скрипт, который устанавливает Cookie и делает редирект на основе содержимого http_referer.