The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

15.04.2010 09:52  Релиз набора компиляторов GCC 4.5.0

После года разработки вышел релиз набора компиляторов GCC 4.5.0 в котором представлен новый оптимизатор на этапе компоновки, реализована экспериментальная поддержка некоторых возможностей стандарта C++0x, продолжена интеграция наработок проекта Graphite с реализацией поддержки автоматического распараллеливания операций.

Основные изменения:

  • Общие нюансы:
    • Для сборки GCC теперь требуется математическая библиотека MPC (multiprecision library) для более точных вычислений на этапе компиляции;
    • Часть старых архитектур была объявлена устаревшей и будет полностью исключена в версии 4.6.0: IRIX до версии 6.5, Solaris 7, Tru64 Unix до версии 5.1, более подробно читайте об этом с списке рассылки;
    • Убрана поддержка систем, объявленных устаревшими в версии GCC 4.4.0;
    • Из релиза исключены утилиты protoize и unprotoize;
    • Улучшились возможности по генерации отладочного кода, в связи с чем требуется GDB версии не ниже 7.0;
    • Для x86 архитектур код с плавающей точкой, генерируемый согласно ужесточенным требованиям стандарта C99, будет работать гораздо медленней, чем в старых версиях GCC. Для решения этой проблемы используйте ключ компиляции -fexcess-precision=fast;
    • Атрибут функции noinline более не гарантирует то, что GCC не создаст клон функции - для предотвращения создания клона появился новый атрибут noclone. Клонирование функции обозначает, что создаётся дубликат функции при некоторых обстоятельствах, например, когда известно значение одного из атрибутов функции;
  • Новые возможности оптимизации:
    • Флаг компиляции -save-temps теперь может использовать дополнительный аргумент. Так, при использовании опций -save-temps и -save-temps=cwd GCC будет писать временные в текущую рабочую директорию, основываясь на расположении исходников. При -save-temps=obj временные файлы будут сохраняться в туже директорию, куда были сохранены объектные файлы (-o). Это позволит компилировать одно и тоже дерево исходников в разные директории.
    • Файлы с отладочной информацией теперь будут сохраняться туда же, куда были сохранены объектные файлы;
    • Для компиляции сложных арифметических выражений теперь используется библиотека MPC, что позволило более точно высчитывать их результат;
    • Появилась новая опция межфайловой оптимизации при линковке файлов -flto. Эта опция заставляет компилятор добавлять в каждый объектный файл некоторую секцию .ELF, и когда затем происходит линковка файла GCC, заметив эту секцию выполняет оптимизацию всех объектных файлов как-будто если бы это был един файл исходников;
    • Подсистема Graphite теперь позволяет включать автоматическую параллезацию с помощью опции -floop-parallelize-all;
    • Переписана инфраструктура оптимизации на основе restrict qualified pointers, что привело к генерации более производительного кода. Также была включена оптимизация кода для этой возможности при использовании флага компиляции -fno-strict-aliasing;
    • Улучшен код функций, генерируемый для уровней -O2 и -Os: если встречаются прототипы функции, параметры которых затем нигде не используются то тогда эти параметры не передаются, а аргументы передаваемые по указателю передаются по значению.
    • GCC теперь оптимизирует код исключений.

Среди прочих изменений нужно отметить улучшенную поддержку стандарта C++0x, улучшенные возможности выдачи сообщений об ошибках на этапе компиляции, улучшение компиляции кода C++, использующего темплейты и многое другое.

  1. Главная ссылка к новости (http://gcc.gnu.org/gcc-4.5/...)
  2. OpenNews: GCC-плагин DragonEgg достиг возможности собственной пересборки
  3. OpenNews: В состав GCC одобрено включение фронтэнда для языка Go
  4. OpenNews: Релиз набора компиляторов GCC 4.4.3 и планы подготовки GCC 4.5
  5. OpenNews: Линус Торвальдс о борьбе с оптимизатором GCC
  6. OpenNews: Релиз набора компиляторов GCC 4.4.0
Автор новости: Artem S. Tashkinov
Тип: Программы
Ключевые слова: gcc, compiler
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, szh (ok), 11:27, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    > #  Для x86 архитектур код с плавающей точной, генерируемый согласно ужесточенным требованиям стандарта C99, будет работать гораздо медленней, чем в старых версиях GCC. Для решения этой проблемы используйте ключ компиляции -fexcess-precision=fast;
    > # GCC now supports handling floating-point excess precision arising from use of the x87 floating-point unit in a way that conforms to ISO C99. This is enabled with -fexcess-precision=standard and with standards conformance options such as -std=c99, and may be disabled using -fexcess-precision=fast.

    по ссылке не написано, где про это можно почитать ?

     
  • 1.2, Аноним (-), 11:32, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]
  • +1 +/
    Эх, если бы ещё такие вот "новинки" можно было без клизмы вставить в существующую систему!...
     
     
  • 2.3, Serega (??), 11:55, 15/04/2010 [^] [ответить]    [к модератору]
  • +1 +/
    Используйте source-based дистрибутив и пересобирайте мир :)
     
     
  • 3.8, noname (??), 15:20, 15/04/2010 [^] [ответить]    [к модератору]
  • +1 +/
    >Используйте source-based дистрибутив и пересобирайте мир :)

    И обломитесь о тучу ошибок сборки и новых багов в "успешно" собранных программах.

     
     
  • 4.15, rfc.1118 (?), 18:19, 15/04/2010 [^] [ответить]    [к модератору]
  • +/
    вы ошибаетесь. нет, правда.
     
     
  • 5.17, User294 (ok), 21:06, 15/04/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    Ага, наверное именно поэтому у кучи знакомых юзеров source based вечно какие-то глюки которые больше нигде не увидишь :). В общем каждому свое.
     
     
  • 6.21, rfc.1118 (?), 12:24, 16/04/2010 [^] [ответить]    [к модератору]  
  • –1 +/
    >Ага, наверное именно поэтому у кучи знакомых юзеров source based вечно какие-то
    >глюки которые больше нигде не увидишь :). В общем каждому свое.

    у меня наоборот кстати.
    каждому свое, да.


     
  • 6.22, stranger (??), 14:54, 16/04/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    Я думаю, что тут проблема не в source-based дистрибутивах, а в том, что ими пользуются те, кто любит поэкспериментировать с системой. Вот поэтому и "глючит".
     
  • 4.24, Adminus (?), 05:21, 17/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Пять лет использую Source based дистрибутивы. Два раза в жизни реально была проблема
    со сборкой.

    1. Когда в конфиге не отлючил зависимый модуль от уже отключенного.

    2. Сборка новой версии неполностью обновленной из репы.

    Вообщем оба раза моя ошибка. Что я делаю не так?

     
     
  • 5.25, fetisheer (ok), 08:56, 17/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Пользуешься стандартным софтом или очень редко обновляешься.
    Как пример: tigervnc Available versions:  1.0.0-r2 1.0.0-r4 (~)1.0.1_pre20100306-r1
    x11-base/xorg-server Available versions:  [M]1.5.3-r6 1.6.5-r1 1.7.6 ~1.8.0
    Притом tigervnc 1.0.0-r4 не работает с xorg 1.7.6. При обновлении же возникла блокировка между mesa и xorg )
    Точно тоже самое с xorg и ati-driver.

    В общем, у генту чрезвычайно несогласованное сообщество: tigervnc и ati-driver должны были стабилизированы перед стабилизацией xorg-server. Это далеко не первый такой пример, за последний год уже пару раз похожие ситуации встречались.

     
  • 2.10, sluge (ok), 17:01, 15/04/2010 [^] [ответить]    [к модератору]  
  • –6 +/
    ну для gcc это традиия. под новый компайлер надо править свои исходники...
    а вот MS, хоть ее и ругают, выпускает компайлеры так что в старых редко что править надо
     
     
  • 3.19, Michael Shigorin (ok), 00:32, 16/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Там предпочитают выдёргивать из-под ног сразу платформу, как вот с VB произошло.
    Ну и компайлеры MS -- немного офтопик как бы. :)
     
  • 1.5, hatewindows (ok), 13:08, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ./configure --happy=on
    make
    sudo make install
     
  • 1.6, Злой (?), 14:10, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    > Для x86 архитектур код с плавающей точкой, генерируемый согласно ужесточенным требованиям стандарта C99, будет работать гораздо медленней, чем в старых версиях GCC. Для решения этой проблемы используйте ключ компиляции -fexcess-precision=fast;

    прошу прощения за свою безграмотность - сюда и x86_64 попадает?

     
     
  • 2.7, anonymous (??), 14:59, 15/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Да.
    Теперь поддерживается более строгая обработка исключений при выполнении команд процессора, работающих с плавающей точкой, а FPU-инструкции (FADD,FMUL,FDIV,FXCH,FCOM,FSQRT etc) в x86-64 такие же, они вроде вообще со времен 387 не менялись - только SIMD-FPU инструкции изменились в x86-64.
     
     
  • 3.9, svn (??), 16:25, 15/04/2010 [^] [ответить]    [к модератору]  
  • –1 +/
    >в x86-64 такие же

    Бред сивой кобылы. В amd64 все операции с плавающей точкой делаются sse инструкциями.

     
     
  • 4.26, anonymous (??), 16:19, 17/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Извини, но бредишь тут ты :)
    Мы про SIMD или классические FPU-команды?? SSE понятно что можно использовать. Да и gcc не против, укажи -mfpu=sse и получи sse-код. А вот классические 387 команды в x86-64 РОВНО такие же, как и в x86.

    И вообще, вот тебе пример когда на x86-64 классический 387 код уделывает sse-вариант. Да здравствует -mfpu=387 на x86-64 :p :p
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780#c5
    Не, я конечно понимаю - ну лажанулись разработчики. Но два раза есть два раза, не?

    ЗЫ капча 54387, что как бы намекает. http://img22.imageshack.us/img22/6713/opennet.png

     
  • 3.11, sluge (ok), 17:04, 15/04/2010 [^] [ответить]    [к модератору]  
  • +/
    вообщето x86 и x86_64 разные архитектуры.
    первую обычно обозначают i386 и так далее
     
  • 1.14, funky_dennis (?), 18:13, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    <cite>Улучшен код функций, генерируемый для уровней -O2 и -Os: если встречаются прототипы функции, параметры которых затем нигде не используются то тогда эти параметры не передаются, а аргументы передаваемые по указателю передаются по значению.</cite>

    Жесть, я думал такое есть с самого начала...

     
  • 1.16, gegMOPO4 (ok), 18:56, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А почему не упомянули о бинарных плагинах?
     
  • 1.18, alex789 (?), 23:32, 15/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    >> а аргументы передаваемые по указателю передаются по значению.

    [с сарказмом]
    O_o  да вот ЭТО действительно классно

    [серьезно]
    или я что-то пропустил и теперь это такой стандарт?

     
     
  • 2.20, funky_dennis (?), 07:11, 16/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Это оптимизация, невидимая программисту, и это правильно. Если в теле функции указатель является указателем на базовый тип, и не меняет своего содержимого, то зачем засовывать в стек адрес ячейки? Чтобы потом вытащить со стека адрес, сходить по этому адресу и опять засунуть в стек содержимое? Это быдло-подход, я не понимаю, почему раньше такого не сделали. Можно же сразу засунуть в стек содержимое.
     
  • 2.23, Вова (?), 17:13, 16/04/2010 [^] [ответить]    [к модератору]  
  • +/
    turn arguments passed by reference to arguments passed by value when possible.

    видимо, под "when possible" имеются в виду константные объекты малого размера.

     
  • 1.27, solardiz (?), 07:56, 29/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Написал тут пошаговую инструкцию по сборке и использованию gcc 4.5.0 под пользователем (без root-доступа), включая сборку и "установку" требуемых им библиотек. В том числе - вариант сборки с Graphite (авто-параллелизация). Далее поигрался с авто-параллелизацией и с поддержкой OpenMP. Все это см. на wiki (ссылка ниже), включая команды шелла, примеры программ, сравнение производительности (для разных сборок примеров программ), встреченные проблемы и некоторые из сделанных выводов:

    http://openwall.info/wiki/internal/gcc-local-build

     
     
  • 2.28, Вова (?), 10:27, 03/05/2010 [^] [ответить]    [к модератору]  
  • +/
    >Написал тут пошаговую инструкцию по сборке и использованию gcc 4.5.0 под пользователем
    >(без root-доступа), включая сборку и "установку" требуемых им библиотек. В том
    >числе - вариант сборки с Graphite (авто-параллелизация). Далее поигрался с авто-параллелизацией
    >и с поддержкой OpenMP. Все это см. на wiki (ссылка ниже),
    >включая команды шелла, примеры программ, сравнение производительности (для разных сборок примеров
    >программ), встреченные проблемы и некоторые из сделанных выводов:
    >
    >http://openwall.info/wiki/internal/gcc-local-build

    по поводу сравнения производительности, нельзя ли сделать примеры с большим числом итераций (хотя бы на минуту выполнения) и глянуть top, сколько процентов цпу - 200? 400?

     
     
  • 3.29, solardiz (?), 11:11, 03/05/2010 [^] [ответить]    [к модератору]  
  • +/
    >>http://openwall.info/wiki/internal/gcc-local-build
    >
    >по поводу сравнения производительности, нельзя ли сделать примеры с большим числом итераций
    >(хотя бы на минуту выполнения) и глянуть top, сколько процентов цпу
    >- 200? 400?

    Более длительные тесты я делал и top смотрел. Там ничего нового - то же соотношение, что мы видим в выдаче time - да и неоткуда взяться другому. Разумеется, все 8 thread'ов работают, т.е. top показывает 100% user, 0% idle в "шапке" (при одном работающем он показывает там 12.5% и 87.5%, соответственно). OMP_WAIT_POLICY=PASSIVE эту картину меняет - появляется idle время, но общее время работы (реальное) увеличивается. time и top показывают примерно одно и то же соотношение и в этом случае.

     
     
  • 4.31, Вова (?), 07:13, 04/05/2010 [^] [ответить]    [к модератору]  
  • +/
    один трид  = 12.5 %% в топе? Какая версия top, либо - что за окружение?
     
     
  • 5.32, solardiz (?), 10:25, 04/05/2010 [^] [ответить]    [к модератору]  
  • +/
    >один трид  = 12.5 %% в топе?

    Да, в "шапке", в режиме показа общих данных по всем процессорам сразу (в этой системе их 8 логических). В строке с конкретным процессом - 99.9% CPU, причем эта величина не увеличивается если работает более одного thread'а (NPTL).

    > Какая версия top,

    procps-3.2.5-owl8

    > либо - что за окружение?

    Процессор Core i7 920 2.67 GHz (с Turbo Boost до трех с чем-то GHz при работе одного thread'а), Hyperthreading включен (ядро видит 8 siblings), дистрибутив Openwall GNU/*/Linux (Owl) свежий -current, сборка под x86_64 (и ядро и userland). Используется OpenVZ, эксперименты проводятся в контейнере с такой же системой (pre-created OpenVZ template за 23-е марта - раздается с наших FTP mirrors).

    Некоторые тестовые примеры я собирал статически и переносил бинарники на другие системы, в том числе Dual Xeon X5460 ("настоящие" 8 ядер) и старенький Dual P4 Xeon Nocona (уже 64-бит). Результаты там схожие - такое же замедление "на всю страницу" (а не только на cache line) при записях и т.п.

     
  • 3.30, solardiz (?), 11:16, 03/05/2010 [^] [ответить]    [к модератору]  
  • +/
    > сколько процентов цпу - 200? 400?

    В таком виде выдачу можно получить от внешней команды time (не bash builtin). Вот для первого примера с авто-параллелизацией:

    $ OMP_WAIT_POLICY=ACTIVE time ./loop
    cf5419a0
    19.70user 0.00system 0:02.46elapsed 799%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+1162minor)pagefaults 0swaps

    $ OMP_WAIT_POLICY=PASSIVE time ./loop
    cf5419a0
    8.83user 0.20system 0:04.06elapsed 222%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+1157minor)pagefaults 0swaps

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2019 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor