OpenWay|POSIX-saga|FreeBSD etc.|All Linux|Apps|POSIX-live|SiteMap

Комплексный тест методов оптимизации численных расчетов в среде GNU/Linux

Юрий Юревич

1. Введение
2. Условия эксперимента
1. Платформа
2. Методика измерения
3. Результаты
1. Производительность базовой конфигурации
2. Фактор №1: дистрибутив
3. Фактор №2: ядро
4. Фактор №3: копмилятор
5. Производительность оптимальной конфигурации
4. Выводы

Введение

1. Использование проприеритарных инструментов (icc, compaq fortran), дающих очень высокую степень оптимизации под конкретную модель процессора.
2. Взамен "академического" bcc:
1. Использование свободных инструментов (gcc, g77) с установками по умолчанию;
2. Использование проприеритарных инструментов (vc++) с установками по умолчанию.

Наиболее верный (на мой взгляд) вариант — 2.2; однако по производительности он сильно уступает варианту 1.

Данный эксперимент посвящен проблеме оптимизации численных расчетов используя исключительно свободные инструменты и свободное окружение.

Условия эксперимента

Платформа

Железная часть:

• Процессор: AMD Athlon XP 1700+ (1466 МГц, частота шины 266МГц)
• Платформа: EPOX 8RDA (nVidia nForce2)
• Оперативная память: 512 Мб (2x256)

Программная часть:

• Debian GNU/Linux 3.0r1 Woody (2002-12-18)
• glibc-2.2.5
• gcc-2.95.4 (включая g++ и g77)
• Debian GNU/Linux testing Sarge (2004-07-09)
• glibc-2.3.2
• gcc-2.95.4 (включая g++ и g77)
• gcc-3.3.4 (включая g++ и g77)
• Ядро Linux: собрано самостоятельно из исходных текстов, используя компилятор по умолчанию для каждой из версий Debian GNU/Linux (gcc-2.95.4 для Woody и gcc-3.3.4 для Sarge )
• vanilla 2.4.26 (i386, k7)
• vanilla 2.6.7 (i386, k7)

В ходе теста планируется сравнить влияние на производительность численного расчета следующих факторов:

1. Окружение (Woody или Sarge при прочих равных);
2. Ядро (2.4 или 2.6; архитектура i386 или k7);
3. Компилятор (gcc-2.x или gcc-3.x; флаги оптимизации).

Методика измерения

Измерения производятся одним синтетическим тестом и четырьмя реальными приложениями:

• Синтетический:
• scimark2, C-версия (http://math.nist.gov/scimark)
• Реальные:
• 3ddyn (3D), fortran-версия (моделирование динамики деления ядра в стохастическом подходе с использованием уравнения Ланжевена), предоставлена Рябовым Е. Г.
• frict_inert (FI), C-версия (расчет инерционных и фрикционных тензоров для уравнения Ланжевена), предоставлена Рябовым Е. Г.
• gk_l (GL), C-версия (расчет сечения слияния), предоставлена Косенко Г. И.
• potent (PO), C-версия (расчет тензора потенциальной энергии для уравнения Ланжевена), предоставлена Рябовым Е. Г.

Scimark2 дает для анализа следующие параметры (единицы измерения — mflops):

• Composite score (CS) — общая производительность (на самом деле это есть среднее арифметическое показателей нижеприведенных тестов, поэтому этот параметр учитываться не будет);
• FFT — быстрое преобразование Фурье;
• LU — факторизация матрицы;
• MonteCarlo (MC) — интегрирование методом Монте-Карло;
• Sparse matmult (SM) — перемножение разреженных матриц;
• SOR — преобразование Якоби.

Для приближения к реальным условиям, scimark2 используется с параметром -large.

Производительность реальных приложений измеряется в обратных секундах: скомпилированная программа запускается через вызов time и в качестве показателя берется real time.

Относительная производительность каждой вариации измеряется в процентах. За сто процентов берется следующая (базовая) конфигурация:

• ОС: Debian GNU/Linux 3.0r1 Woody
• Ядро: 2.4.26-i386
• Компилятор: gcc-2.95.4
• Опции сборки: -O2 -march=i386 -mcpu=i386

Каждый из тестов для каждой вариации повторяется три раза, затем вычисляется среднее значение и погрешность измерения.

Для определения итоговой значимости вариации каждого фактора определяется среднее с учетом веса каждого теста. Используются следующие веса для тестов:

• для всех реальных тестов вес 1.1
• для всех синтетических показателей scimark2 вес 0.92

Результаты

Производительность базовой конфигурации

За точку отсчета в 100% для каждого теста взяты следующие показатели:

Фактор №1: дистрибутив

• Фактор: дистрибутив
• Вариации:
1. Debian GNU/Linux Woody
2. Debian GNU/Linux Sarge
• Ядро: 2.4.26-i386
• Компилятор: gcc-2.95.4
• Опции сборки: -O2 -march=i386 -mcpu=i386

На графике изображен относительный прирост производительности при смене дистрибутива с Woody на Sarge

Средний прирост (с учетом веса каждого теста): (9.79 ± 1.44)%

Т.е. в большинстве случаев при смене дистрибутива с Woody на Sarge ожидается прирост производительности численных расчетов порядка 10% при прочих равных.

Фактор №2: ядро

• Фактор: ядро
• Вариации:
1. 2.4.26-i386;
2. 2.4.26-k7;
3. 2.6.7-i386;
4. 2.6.7-k7.
• Дистрибутив: Debian GNU/Linux Sarge
• Компилятор: gcc-2.95.4
• Опции сборки: -O2 -march=i386 -mcpu=i386

На графике изображен относительный прирост производительности (в процентах от производительности базовой системы) при смене ядра 2.4.26-i386 на вариационное ядро.

Средний прирост (с учетом веса каждого теста):

Т.о. в большинстве случаев есть смысл менять ядро с 2.4.x на 2.6.x; при этом ожидаемый прирост будет в пределах 1-2%. А вот сборка ядра под k7-архитектуру практически ничего не дает: почти все тесты показали результаты в пределах погрешности измерений.

Фактор №3: копмилятор

• Фактор: компилятор и опции сборки
• Вариации (опции для p3 и старше взяты с http://www.freehackers.org/gentoo/gccflags/flag_gcc3opt.html):
1. i386/gcc-2.95:

   -O3 -march=i386 -mcpu=i386

2. i686/gcc-2.95:

   -O3 -march=i686 -mcpu=i386

3. i386/gcc-3.3:

   -O3 -march=i386 -mcpu=i386

4. i686/gcc-3.3:

   -O3 -march=i686 -mcpu=i386

5. i686sse/gcc-3.3:

   -O3 -march=i686 -mcpu=i686 -mmmx -msse

6. i686fp/gcc-3.3:

   -O3 -march=i686 -mcpu=i686 -mmmx -msse -mfpmath=sse

7. pentium3/gcc-3.3:

   -O3 -march=pentium3 -mcpu=pentium3 -fomit-frame-pointer \ 
   -fforce-addr -falign-functions=4 -fprefetch-loop-arrays

8. athlon/gcc-3.3:

   -O3 -march=athlon -mcpu=athlon -O3 -fomit-frame-pointer \ 
   -ffast-math -fforce-addr -falign-functions=4 \ 
   -funroll-loops -msse

9. a-tbird/gcc-3.3:

   -O3 -march=athlon-tbird -mcpu=athlon-tbird -fomit-frame-pointer \ 
   -fforce-addr -falign-functions=4 -funroll-loops \ 
   -maccumulate-outgoing-args -msse

10. athlonxp/gcc-3.3:

    -O3 -march=athlon-xp -mcpu=athlon-xp -fomit-frame-pointer \ 
    -ffast-math -fforce-addr -falign-functions=4 -funroll-loops \ 
    -maccumulate-outgoing-args -frerun-cse-after-loop \ 
    -frerun-loop-opt -fprefetch-loop-arrays -msse -mfpmath=sse

• Дистрибутив: Debian GNU/Linux Sarge
• Ядро: 2.4.26-i386

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

Средний прирост (с учетом веса каждого теста):

По данному фактору можно сказать следующее: для большинства программ оптимальным будет использование сборки под athlon; дальнейшая оптимизация дает либо такой же (athlon-xp), либо худший результат (athlon-tbird).

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

• Дистрибутив: Debian GNU/Linux Sarge
• Ядро: 2.6.7-i386
• Компилятор: gcc-3.3.4
• Опции сборки:

  -O3 -march=athlon -mcpu=athlon -O3 -fomit-frame-pointer \ 
  -ffast-math -fforce-addr -falign-functions=4 \ 
  -funroll-loops -msse

Ниже на графике представлен прирост производительности (в процентах от производительности базовой системы) при оптимальной конфигурации. Оптимальная не в смысле "самая быстрая для каждого из тестов", а в смысле "самая быстрая для всех тестов суммарно".

Средний прирост (с учетом веса каждого теста): (67.77 ± 1.27)%

Показатели тестов оптимальной конфигурации:

Отдавая дань уважения авторам программ, упомянем оптимальные конфигурации для каждого из реальных тестов. Для C-версий оптимальная конфигурация для всех совпадает с оптимальной для каждого. В случае с fortran-версией наибольшее быстродействие¹ достигается при оптимизации под i386, т.е. с флагами -O3 -march=i386 -mcpu=i386. Любые другие виды оптимизации приводят к падению производительности программы 3D.

Выводы

Все выводы, сделанные ниже касаются только проведенного эксперимента и нисколько не обобщают на другие платформы (p4), компиляторы (icc, compaq fortran) и т.д.
• Повышение производительности на 10% в Sarge я склонен приписывать новой glibc.
• Разница производительности на различных ядрах настолько мала, что я бы не стал рассматривать производительность как повод к смене ядра.
• Насчет флагов оптимизации:
• Включение каких-либо мультимедийных инструкций само по себе прироста не дает, это заметно по отсутствию достоверно различимой разницы между i686/i686sse/i686fp.
• По всей видимости, большинство программ для численного счет достаточно протестировать при двух отпимизациях: "классической" (gcc-2.95; ix86; минимум дополнительных флагов) и "модерновой" (gcc-3.3; максимально близкая к процессору платформа; дополнительные флаги). И этого будет достаточно, чтобы выбрать близкую к оптимальной конфигурацию.
• Причину предрасположенности C-программ к "модерновой" оптимизации и fortran-программы к "классической" я вижу в том, что у разработчиков GNU Compiler Collection руки не дошли до оптимизации кода, генерируемого g77. Поэтому классический g77-2.95 генерирует наиболее чистый и быстрый код.

Итог таков: различными методами можно достичь в среднем 65-70% прироста производительности программ численного счета. При этом наиболее значимым фактором (55-60%) остается выбор компилятора и флагов оптимизации. Смена дистрибутива же дает "бонусных" 5-10% к уже скомпилированным программам. Такая картина характерна для платформы AMD²


В заключение, выражаю благодарность Рябову Е. Г. и Косенко Г. И. за идею, моральную поддержку и предоставленные программы.
____
   1 В итоге, для 3D имеем следующие результаты: прирост в производительности 35.46 ± 0.35 %. Абсолютное значение времени выполнения: 558.67 ± 0.24 с.
   2 Судя по ранее проводимым сравнениям (но, к сожалению, не опубликованных) Рябова Е. Г., для платформы Intel характерна более низкая производительность при малых уровнях оптимизации и существенный рост быстродействия при высоких уровнях оптимизации под архитектуру p4.

---

Обсуждение проекта