company_banner

Оптимизация для Intel Atom на пальцах


    Начну, пожалуй, с очевидного (слева от этого текста). Изображение, приведенное здесь, довольно известно. Оно показывает, что сотрудники Интел обычно носят на пальцах вместо колец процессоры Atom и рисовые зерна.
    Оно демонстрирует размер процессора Intel Atom в сравнении с рисовым зерном. А я продемонстрирую вам буквально «на пальцах» простые и, надеюсь, полезные для программистов на С\С++ советы по оптимизации софта для Intel Atom.
    Вообще, единственный открытый официальный источник оптимизационной мудрости для процессоров Intel — это Intel® 64 and IA-32 Architectures Optimization Reference Manual — содержит целую главу (#13), посвященную Atom. Там даются многочисленные советы по оптимизации… но только для тех, кто пишет на ассемблере. Вот типичный пример:
    "Assembly/Compiler Coding Rule 4. -For Intel Atom processors, place a MOV instruction between a flag producer instruction and a flag consumer instruction that would have incurred a two-cycle delay. This will prevent partial flag dependency."
    Вы все поняли? Отлично!
    Но число Атомов во вселенной постоянно растет, а число пишущих софт на ассемблере — убывает, то что многим остается только переживать комплекс неполноценности читать более высокоуровневые советы ниже.

    1. Многопоточность, точнее — двухпоточность, по числу логических ядер. На Atom — очень эффективный Hyper Threading (имеется в большинстве моделей Atom). Так что если вы распарараллелите ваш код на два потока, то можете расчитывать на прирост производительности 30-50% ( против ожидаемых 15-20% на десктопных архитектурах Intel).
    2. Выравнивание памяти. При выравнивании памяти на 16 байт реально получить 10% выигрыша в приложении, активно выделяющем и копирующем память.
    3. Серьезная угроза производительности — многократный вызов коротких (небольших) функций. По возможности, такие функции надо или объединять, или принудительно встраивать (inline). Выигрыш производительности от такой простейшей оптимизации на серьезных приложениях может достигать 20%! Короткие функции могут прятаться в используемых библиотеках (например, математических), а также в разделяемых объектах Linux (PIC code). Кстати, следующая ф-я тоже будет короткой в случае, если bar =0.
      void foo() {
      if (bar) {
      /* делаем что-то нужное, длинное и сложное */
      }
      }
    4. Кэш в Atom небольшой, так что здесь особенно актуальна локальность доступа к данным -т.е. по возможности не «прыгать» по массивам, а обходить их последовательно; объединять в структуру то, что часто используется и не грузить кэш доступом к мертвым душам данным.
    5. Atom очень медленно работает с данными типа double. Примерно в 5 раз медленнее, чем с float! Причем, как в скалярных, так и векторных инструкциях (SSE). Так что, по возможности, откажитесь от двойной точности.
    6. Также медленно Atom занимается делением. Лучше вообще не делить, но если приходится, то знайте, что беззнаковое деление быстрее знакового, 8-битное быстрее 16-битного, которое, конечно же, быстрее 32-битного. У компилятора Intel есть специальный флаг для понижения точности = ускорения деленя “-no-prec-div”. И еще — блок деления в процессоре один, он совместно используется всеми потоками, так что это может стать узким местом.
    7. Работать с float (даже в скалярном случае) быстрее через векторные инструкции (или интринсики).
      Флаг “–fpmath=sse” компилятора gcc генерирует код с x87 на sse. Компилятор Intel делает то же самое
      автоматически..
    8. И, наконец, компиляторы. Вот рекоммендуемые флаги для компиляции под Atom. Помимо вышеописанных ускорений, компилятор Intel оптимизирует код на уровне микроинструкций (инженеры Интел честно изучили приведенный в начале мануал :) )
      gcc < 4.5: -march=core2 -mtune=generic -fpmath=sse –O3 [–ffast-math]
      gcc >=4.5: -march=atom –fpmath=sse -03 [-flto] [–ffast-math]
      icc < 11.1: -xL –O3 –ipo [-fno-alias] [-no-prec-div]
      icc >=11.1: -xSSE3_ATOM –ipo [–ansi-alias] [-no-prec-div]


    Советы даны просто в форме рецептов, без пояснений, почему это так. Но стандартный ответ звучит как «Так создал Бог устроен Atom». Если требуются более глубокие объяснения — комментарии и личная переписка к вашим услугам.
    Intel
    Компания

    Комментарии 35

      +1
      А разве это не кристалл на фотке? Корпуса как бы нет.
        +4
        Это именно процессор без корпуса.
          0
          Извиняюсь, что не по теме, но это конкретно эта часть настолько сильно разогревается? И насколько больше чип, например i3, чем этот?
        +9
        Gentoo'шникам и любителям Netbook'ов на заметку:
        gcc >=4.5: -march=atom –fpmath=sse -03 [-flto] [–ffast-math]
        Спасибо за статью.
          0
          пожалуйста! все для вас :)
            +1
            Простите, вы на нем же собирать будете, месье?!
              0
              Разве это обязательно?
                0
                Это попытка уйти от ответа? Какой у вас сценарий установки новых пакетов/программ или их обновлений?
                  0
                  Как я только не делал )).
                  Делал tmp в RAM и собирал всё на нетбуке.
                  Делал песочницу на ББ и по rsync потом синкал.
                    0
                    Мне кажется, что Gentoo вообще не место на компьютерах с Intel Atom.
                      0
                      Возможно ))
                      Но я думаю нужно остановить эту дискуссию, это уже не по теме статьи.
            +1
            Небольшое сравнение атома и нового процессора от AMD
            www.3dnews.ru/news/amd-brazos-protiv-atom-v-voprose-teplovideleniya
            Есть предположение: под AMD вообще ничего оптимизировать нет необходимости!
              +4
              предложение не пройдет. В статье описано декодирование видео, его делает встроенная графика, а оптимизация нужна для кучи софта, который не имеет соответствующих «железных» решений
                –2
                оптимизация как техпроцесс всегда вторична, если изначально не известно, что работать будет туго! т.е., в большинстве случаев, сначала пишем софт — затем оптимизируем. иначе, попахивает детским садом… так вот, если железо «тянет», ничего оптимизировать не приходится. вот и все… ;)
                  +1
                  преждевременная пессимизация опаснее преждевременной оптимизации…
                  ну и нужно объяснение Кнутта его знаменитой фразы и что он разочарован в том, в каком контексте ее обычно используют…
                    0
                    преждевременная пессимизация, как правило, закладывает дополнительные ресурсы на этапе эстимейта, что впоследствии приводит к более реальным значениям оного. начинать проект с оптимизации — паранойя! этап, когда программист хорошо владеет dk-equipment-ом, но совершенно не имеет понятия об управлении своим рабочим ресурсом!
                +5
                >Есть предположение: под AMD вообще ничего оптимизировать нет необходимости!

                Она всегда есть, и под любой процессор.
                  +2
                  Тут, скорее, имелось ввиду то, что аналог атома от амд будет куда полноценней в плане возможностей, чем это маленькое чудо. А всё потому, что в атоме отрезали внеочередной запуск кода и всего 2 инструкции за такт выполняется.
                    0
                    У K1xx и Vчёта-там виртуализация заявлена. Всё жду когда появится «на прилавках» чтобы пощупать, это будет убийственно, нетбук за ~10k и виртуализация =)
                  +1
                  Так нет необходимости или все таки без толку? :-)
                  +1
                  Совет номер 9: пользуйтесь интеловским компилятором, а не гцц :)
                    0
                    Заметьте, не я это сказала :) Я хотела обойтись без рекламы :)
                      +1
                      У вас и так скрытая реклама в восьмом совете.
                        0
                        Имхо icc все же лучше gcc, хотя бы потому что он заточен именно под интеловские процы.
                          0
                          А я и не спорю, что gcc лучше или хуже.
                          0
                          она очень-очень скрытая :) и не реклама, а правда.
                      0
                      у меня на генте:
                      CFLAGS="-march=native -O2 -fomit-frame-pointer -mfpmath=sse -mssse3 -pipe"
                        +1
                        Если я не ошибаюсь, то целочисленное деление gcc обычно компилирует в умножение, так что оно не должно по идее создавать проблем.
                          +1
                          Целочисленное деление на константу.
                          0
                          звучит голословно. можно вывод тайма при различных настройках компилятора (сам бы поробовал, железки нет под рукой)
                            0
                            mat1bench через Acovea(http://coyotegulch.com/products/acovea/) на D510 gcc 4.5.2

                            optimistic options:
                            -ffast-math (1.021)

                            A relative graph of fitnesses:
                            -O1: ********************************************** (3.0374)
                            -O3: *********************************************** (3.1439)
                            atom sse -O3: *********************************************** (3.1525)
                              0
                              хм… интересно, спасибо
                            +2
                            Ногти-то стричь надо!
                              +1
                              Никак не успеваем! Постоянно выпускаем какой-нибудь новый процессор, на ногти времени не хватает. Думаем нанимать аутсорсеров. Не хотите подработать? :)
                            • НЛО прилетело и опубликовало эту надпись здесь

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

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