company_banner

«Зачем обновлять GCC компилятор?» или «Производительность GCC компилятора на Intel Atom от версии к версии»


    Давайте попытаемся понять, что нового сделано в GCC компиляторе для процессоров архитектуры Intel Atom и как это влияет на производительность и размер кода известного бенчмарка EEMBC CoreMark.
    Выше приведен график, отображающий производительность CoreMark, откомпилированного с пиковым и базовым набором опций разными версиями GCC относительно производительности базового набора опций для GCC версии 4.4.6 (выше – лучше).

    При тестировании использовались следующие опции компилятора:
    базовый набор опций (base): “-O2 -ffast-math -mfpmath=sse -m32 -march=atom”
    базовый набор опций (base) + if convertion: “-O2 -ffast-math -mfpmath=sse -ftree-loop-if-convert -m32 -march=atom”
    пиковый набор опций (peak): “-Ofast -funroll-loops -mfpmath=sse -m32 -march=atom”, для версий 4.4 и 4.5 “-Ofast” было заменено на “-O3 -ffast-math”
    Подробнее про оптимальные опции для GCC на x86 было написано здесь. Стоить отметить, что опция “-flto” пока не прибавляет производительности CoreMark.

    Из графика видно, что базовый набор опций с “-ftree-loop-if-convert” достиг производительности пикового набора на CoreMark.

    Ниже приведен график показывающий увеличение размера исполняемого кода CoreMark откомпилированного с пиковым набором опций относительного базового для разных версий GCC:



    Ниже приведен график, показывающий увеличение размера исполняемого кода CoreMark, откомпилированного разными версиями GCC с базовым набором опций относительного базового набора опций на GCC 4.4.6:



    “-ffunction-sections -Wl,--gc-sections -fno-asynchronous-unwind-tables -Wl,--strip-all” были добавлены к базовому и пиковому набору опций для измерения в размера кода. Данные опции не влияют на производительность CoreMark.
    Более подробно про опции для оптимального размера исполняемого кода было написано здесь.

    Из графиков видно, что размер кода на пиковом наборе опций в 2 раза больше, чем на базовом и продолжает расти. Базовый набор опций, напротив, обеспечивает незначительное снижение размера кода.

    Все измерения производились для 1 потока на 2-х ядерном Intel Atom CPU D525, 1.80GHz с 4Gb памяти, операционная система Fedora 17.

    GCC продемонстрировал очень хороший прогресс от версии 4.4 к версии 4.8 (в основном от версии 4.6 к версии 4.7 и от «-ftree-loop-if-convert» на базовом наборе опций версии 4.8). Размер кода на базовом наборе опций остается без изменений, на пиковом наборе растет.

    Ниже приведено краткое описание опций и изменений в GCC от версии к версии:
    • В версии GCC 4.5 впервые представлена опция "-march=atom" (подробнее). GCC 4.4 упоминается в статье как последняя версия без поддержки Atom. CoreMark для этой версии было собрано с “-march=i686 -mtune=generic -mssse3”. До сих пор большое количество Unix систем используют gcc-4.4+. Однако стоит отметить, что некоторые специальные gcc-4.4 могут поддерживать “-march=atom”. Например, Android NDK gcc-4.4.
    • Версия GCC 4.6 отличается лучшими эвристиками для подстановки функций (inline) и возможностью улучшить производительность CoreMark за счет появившейся опции: "-ftree-loop-if-convert". По умолчанию эта опция включена, начиная с “-O3 (-Ofast)”. Добавленная к базовому набору опций, она ускоряет CoreMark на ~8%. Официальный список изменений в GCC 4.6.
    • В версии GCC 4.7 при включенной “-march=atom” появились новые специфичные для Atom оптимизации, в частности, оптимизации, улучшающие работу инструкций LEA и IMUL. Первоначально на архитектуре Atom IMUL требовал переключения в особый режим, и потому было выгодно группировать IMUL (исправлено в новейшем Atom процессоре Silvermont). LEA, результат которого шел на ALU, терял производительность. Поэтому некоторые LEA было выгодно заменять на последовательность из ADD и MOV (исправлено в новейшем Atom процессоре Silvermont). Официальный список изменений.
    • В версии 4.8 улучшены оптимизации над командами логики. В результате уменьшилось давление на регистры в некоторых функциях CoreMark (это касается только базового набора опций с "-ftree-loop-if-convert”). Также в версии 4.8 появилась возможность уменьшить давление на регистры: “-fschedule-insns -fsched-pressure” (ранее опции были крайне нестабильны). На CoreMark это добавит около 1% к пиковому набору опций. Чаще всего “-fschedule-insns -fsched-pressure” улучшают производительность, когда включена опция: "-funroll-loops". Официальный список изменений.


    Что, если в GCC версии 4.8 "-march=atom" включало бы лишь “-march=i686 -mtune=generic -mssse3”? Производительность на CoreMark упала бы на 5%. "-ftree-loop-if-convert” добавляет к производительности базового набора опций еще 13%.
    Если для Вашего Atom приложения важен и размер кода, и производительность — переключайтесь на GCC версии 4.8 и пробуйте компилировать с опциями:
    “-O2 -ffast-math -mfpmath=sse -ftree-loop-if-convet -fschedule-insns -fsched-pressure -m32 -march=atom”
    Если же важна только производительность, то GCC 4.8 оптимален с опциями:
    “-Ofast -flto -funroll-loops -mfpmath=sse -fschedule-insns -fsched-pressure -m32 -march=atom”

    Intel

    147,00

    Компания

    Поделиться публикацией
    Комментарии 18
      +1
      Обновление компилятора само по себе важно дело. Производительность, исправление багов и т.д. Но 4.8.1 действительно сделало скачек. Требует внимания. Спасибо за статью!
        0
        GCC 4.8.1 собирает BulletPhysics с internal compiler error: Segmentation fault. Поэтому более старую версию лучше не удалять.
          +7
          Вероятно, вы уже локализовали и отрепортили баг? ;-)
            +2
            Подскажите как воспроизвести (точная версия, опции, что пускать).
            +5
            удалено, почему никак не добавят возможность изменения ветки сообщения после написания?
              +6
              Есть мнение, что лучшая версия gcc — это clang :)
              Вообщем, реквестирую бенчмарк с clang 3.3
                +7
                CoreMark, gcc и clang в свободном доступе — проверяйте. Мои данные говорят, что clang пока отстает.
                  0
                  CoreMark в условно свободном доступе: нужно зарегестрироваться, и согласиться с длинным текстом лицензии. Вчера я этот текст так и не осилил.

                  Да и процессор Intel Atom D525 в свободном доступе найти не просто!
                    0
                    Если Вам нужно сравнить gcc и clang, то подойдет и что-нибудь другое. Прирост gcc от архитектурных оптимизаций будет другой, но в целом картина будет схожа.
                    +3
                    Clang отстает, ощутимо (пока), но на мой взгляд, он все же перспективней, чем GCC. Архитектура GCC представляет собой месиво из функций, причем, например, это нормально, когда бэкенд лезет чуть-ли не во фронтэнд за какой-либо нужной ему информацией. Изменение в любом компоненте может повлиять на большое количество мест и простой фикс выливается в огромый патч во всех модулях. Почитайте, например, недавнюю историю с переходом на компиляцию при помощи g++. С другой стороны, архитектура LLVM — стройный код, написанный в прадигме ООП. Разбираться и работать с ним одно удовольствие.
                      +1
                      У gcc есть поддержка множества архитектур. Другим компиляторам такой поддержки добиться слабо реально. Этот факт застолбит часть будущего за gcc.
                        0
                        А множество архитектур — это сколько? Четыре десятка, учитывая те, что уже не производятся лет 10? Более того, архитектуру в компилятор добавить относительно не сложно.

                        Но, не отрицаю, что пока от GCC не уйти — очень много на него завязано всего.
                          0
                          Добавить поддержку в софте — одно. Добавить инфраструктуру и людей это много сложнее. GNU продукты это не только gcc. Не зря все бьются за совместимость с gcc.
                  +3
                  будущее все равно за LLVM/clang
                    0
                    Мм… вопрос, а что мне надо к примеру под AMD A10? Какие параметры будут оптимальны под самое высокое быстродействие.
                      +1
                      Самое простое универсальное решение — -march=native -O3.
                      Будет использовать все доступные на хост машине инструкции и пытаться оптимизировать по максимуму, учитывая некоторые особенности доступного процессора (размер кэша, например).
                        0
                        -O3 обычно не советуют использовать, т.к. программы становятся не стабильны.
                        Насколько вообще опасно его юзать, и что может произойти?
                          +3
                          На приложениях, где стабильность критически важна, советуют использовать -O1. В остальных случаях, -O2 и -O3 вполне допустимы. Разница у них в наборе используемых оптимизаций. Никаких экспериментальных и ненадежных вещей O3 не включает.

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

                    Самое читаемое