Компілятори Intel. Спільне використання компіляторів Intel і GCC

Попередньому номері журналу ми обговорювали продукти сімейства Intel VTune Performance Analyzer - коштів аналізу продуктивності, що користуються заслуженою популярністю у розробників додатків і дозволяють виявляти в коді додатків команди, на які витрачається занадто багато ресурсів процесора, що дає розробникам можливість виявити і усунути потенційні вузькі місця, пов'язані з подібними ділянками коду, прискоривши тим самим процес розробки додатків. Відзначимо, однак, що продуктивність додатків багато в чому залежить від того, наскільки ефективні застосовуються при їх розробці компілятори, і які особливості апаратного забезпечення вони використовують при генерації машинного коду.

Останні версії компіляторів Intel Intel C ++ і Intel Fortran для ОС Windows і Linux дозволяють отримати виграш в продуктивності додатків для систем на базі процесорів Intel Itanium 2, Intel Xeon і Intel Pentium 4 до 40% в порівнянні з існуючими компиляторами від інших виробників за рахунок використання таких особливостей зазначених процесорів, як технологія Hyper-Threading.

До відмінностей, пов'язаних з оптимізацією коду даними сімейством компіляторів, слід віднести застосування стека для виконання операцій з плаваючою точкою, межпроцедурную оптимізацію (Interprocedural Optimization, IPO), оптимізацію відповідно до профілю додатки (Profile Guided Optimization, PGO), попередню завантаження даних в кеш (Data prefetching), яка дозволяє уникнути затримки, пов'язаної з доступом до пам'яті, підтримку характерних особливостей процесорів Intel (наприклад, розширень для потокової обробки даних Intel Streaming SIMD Extensions 2, характерних для Intel Pentium 4), автоматичне розпаралелювання виконання коду, створення додатків, виконуються на декількох різних типах процесорів при оптимізації для одного з них, засоби «передбачення» подальшого коду (branch prediction), розширену підтримку роботи з потоками виконання.

Відзначимо, що компілятори Intel застосовуються в таких відомих компаніях, як Alias \u200b\u200b/ Wavefront, Oracle, Fujitsu Siemens, ABAQUS, Silicon Graphics, IBM. За даними незалежного тестування, проведеного низкою компаній, продуктивність компіляторів Intel значно перевищує продуктивність компіляторів інших виробників (див., Наприклад, http://intel.com/software/products/compilers/techtopics/compiler_gnu_perf.pdf).

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

Компілятори для платформи Microsoft Windows

Intel C ++ Compiler 7.1 для Windows

Intel C ++ Compiler 7.1 це компілятор, випущений на початку цього року, який дозволяє досягти високого ступеня оптимізації коду для процесорів Intel Itanium, Intel Itanium 2, Intel Pentium 4 і Intel Xeon, а також для процесора Intel Pentium M, який використовує технологію Intel Centrino і призначеного для застосування в мобільних пристроях.

Зазначений компілятор повністю сумісний із засобами розробки Microsoft Visual C ++ 6.0 і Microsoft Visual Studio .NET: він може бути вбудований у відповідні середовища розробки.

Даний компілятор підтримує стандарти ANSI і ISO C / C ++.

Intel Fortran Compiler 7.1 для Windows

Компілятор Intel Fortran Compiler 7.1 для Windows, також випущений на початку поточного року, дозволяє створювати оптимізований код для процесорів Intel Itanium, Intel Itanium 2, Intel Pentium 4 і Intel Xeon, Intel Pentium M.

Цей компілятор повністю сумісний із засобами розробки Microsoft Visual C ++ 6.0 і Microsoft Visual Studio .NET, тобто може бути вбудований у відповідні середовища розробки. Крім того, даний компілятор дозволяє вести розробку 64-розрядних додатків для операційних систем, що виконуються на процесорах Itanium / Itanium 2, за допомогою Microsoft Visual Studio на 32-розрядному процесорі Pentium із застосуванням 64-розрядної компілятора Intel Fortran Compiler. При налагодженні коду даний компілятор дозволяє застосовувати відладчик для платформи Microsoft .NET.

При наявності встановленого продукту Compaq Visual Fortran 6.6 можна застосовувати замість вихідного компілятора Intel Fortran Compiler 7.1, так як зазначені компілятори сумісні на рівні вихідного коду.

Компілятор Intel Fortran Compiler 7.1 для Windows повністю сумісний зі стандартом ISO Fortran 95 і підтримує створення і налагодження додатків, що містять код на двох мовах С і Fortran.

Компілятори для платформи Linux

Intel C ++ Compiler 7.1 для Linux

Ще один компілятор, який побачив світ на початку року, Intel C ++ Compiler 7.1 для Linux, дозволяє досягти високого ступеня оптимізації коду для процесорів Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Даний компілятор повністю сумісний з компілятором GNU C на рівні вихідного коду і об'єктних модулів, що без додаткових витрат дозволяє здійснювати міграцію на нього додатків, створених за допомогою GNU C. Компілятор Intel C ++ Compiler підтримує C ++ ABI (додаток до ядра Linux, що дозволяє виконувати під управлінням Linux скомпільований код для інших платформ, таких як ранні операційні системи SCO, ранні версії Sun Solaris і ін.), а це означає повну сумісність з компілятором gcc 3.2 на рівні двійкового коду. Нарешті, за допомогою компілятора Intel C ++ Compiler 7.1 для Linux можна навіть перекомпіліровать ядро \u200b\u200bLinux, зробивши кілька незначних змін в його вихідному коді.

Intel Fortran Compiler 7.1 для Linux

Компілятор Intel Fortran Compiler 7.1 для Linux дозволяє створювати оптимізований код для процесорів Intel Itanium, Intel Itanium 2, Intel Pentium 4, Intel Pentium M. Даний компілятор повністю сумісний з компілятором Compaq Visual Fortran 6.6 на рівні вихідного коду, дозволяє здійснювати з його допомогою перекомпіляцію додатків , створених за допомогою Compaq Visual Fortran, підвищуючи таким чином їх продуктивність.

Крім того, зазначений компілятор сумісний з такими застосовуваними розробниками утилітами, як редактор emacs, відладчик gdb, утиліта для збірки програм make.

Як і Windows-версія даного компілятора, Intel Fortran Compiler 7.1 для Linux повністю сумісний зі стандартом ISO Fortran 95 і підтримує створення і налагодження додатків, що містять код на двох мовах С і Fortran.

Слід особливо підкреслити, що істотний внесок в створення перерахованих компіляторів Intel внесли фахівці Російського центру Intel по розробці програмного забезпечення в Нижньому Новгороді. Більш детальну інформацію про компіляторах Intel можна знайти на Web-сайті корпорації Intel за адресою: www.intel.com/software/products/.

Друга частина цієї статті буде присвячена компіляторам Intel, що створює додатки для мобільних пристроїв.

Приклади реальних зламів: Intel C ++ 7.0 Compiler - Архів WASM.RU

... компілятор Intel C ++ 7.0 докачаєте пізно вночі, годині десь о п'ятій ранку. Спати хотілося неймовірно, але і цікавість: чи була посилена захист чи ні, теж роздирали. Вирішивши, що до тих пір поки не розберуся з захистом я все одно не засну, я, відкривши нову консоль, і перевстановити системні змінні TEMP і TMP на каталог C: \\ TEMP, нашвидку набив непристойно довге ім'я інсталятора W_CC_P_7.0.073.exe в командному рядку (Необхідність в установці змінних TEMP і TMP пояснюється тим, що в Windows 2000 вони за умовчанням вказують на дуже глибоко вкладений каталог, а інсталятор Intel C ++ - та й не тільки він - не підтримує шляхів такого величезного розміру).
Відразу ж з'ясувалося, що політика захисту була кардинально переглянута і тепер наявність ліцензії перевірялося вже на стадії установки програми (у версії 5.x установка здійснювалося без проблем). ОК, даємо команду dir і дивимося на вміст того, з чим нам зараз доведеться воювати:
Вміст папки C: \\ TMP \\ IntelC ++ Compiler70

17.03.2003 05:10
html

17.03.2003 05:11
x86

17.03.2003 05:11
Itanium

17.03.2003 05:11
notes

05.06.2002 10:35 45 056 AutoRun.exe

10.07.2001 12:56 27 autorun.inf

29.10.2002 11:25 2 831 ccompindex.htm

24.10.2002 8:12 126 976 ChkLic.dll

18.10.2002 22:37 552 960 chklic.exe

17.10.2002 16:29 28 663 CLicense.rtf

17.10.2002 16:35 386 credist.txt

16.10.2002 17:02 34 136 Crelnotes.htm

19.03.2002 14:28 4 635 PLSuite.htm

21.02.2002 12:39 2 478 register.htm

02.10.2002 14:51 40 960 Setup.exe

02.10.2002 10:40 151 Setup.ini

10.07.2001 12:56 184 setup.mwg

19 файлів 2 519 238 байт

6 папок 886 571 008 байт вільно

Ага! Програма установки setup.exe займає всього сорок з хвостиком кілобайт. Дуже добре! У такий обсяг серйозний захист навряд чи сховаєш, а якщо навіть так - цей крихітний файл нічого не варто проаналізувати цілком - до останнього байта дізассемблерного лістингу. Втім, не факт, що захисний код розташований саме в setup.exe, він може знаходиться і в інший місці, ось наприклад ... ChkLic.dll / ChkLic.exe, які займають в сукупності трохи менше семисот кілобайт. Стривай, який такий ChkLic? Це скорочення від Check License чи що ?! Гм, у хлопців з Intel очевидно серйозні проблеми з почуттям гумору. Вже краще б вони назвали цей файл "Hack Me" чесне слово! Гаразд, судячи з обсягу, ChkLic це той самий FLEX lm і є, а з ним ми вже стикалися (див. "Intel C ++ 5.0 Compiler") і приблизно уявляємо як його ламати.
Даємо команду "dumpbin / EXPORTS ChkLic.dll" для дослідження експортованих функцій і ... міцно тримаємося за Клаву, щоб не впасти зі стільця:
Dump of file ChkLic.dll

Section contains the following exports for ChkLic.dll

0 characteristics

3DB438B4 time date stamp Mon Oct 21 21:26:12 2002

1 number of functions

1 number of names

ordinal hint RVA name

1 0 000010A0 _CheckValidLicense

Чорт забирай! Захист експортує всього одну-єдину функцію з чудовим ім'ям CheckValidLicense. "Чудовим" - тому, що призначення функції стає зрозумілим її назви і з'являється можливість уникнути кропіткого аналізу дізассемблерного коду. Ну ось, відбили весь інтерес ... вже краще б вони її по ордіналов експортували чи що, або, по крайней мере, охрестили її яким не будь відлякує ім'ям типу DES Decrypt.
... розмріялись! Гаразд, повернемося до наших баранів. Давайте міркувати логічно: якщо весь захисний код зосереджений безпосередньо в ChkLic.dll (а, судячи з "навісного" характером захисту, це дійсно так), то вся "захист" зводиться до виклику CheckValidLicense з Setup.exe і перевірці повернутого нею результату. Тому для "злому" достатньо лише пропадчіть ChkLic.dll, змушуючи функцію ChekValidLicense завжди повертати ... так, до речі, що вона повинна повертати? Точніше: яке саме значення, що повертається відповідає успішної перевірки ліцензії? Ні, не поспішайте розбирати setup.exe для визначення, адже можливих варіантів не так уже й багато: або FALSE, або TRUE. Ви робите ставку на TRUE? Що ж, в якомусь сенсі це логічно, але з іншого боку: а чому ми, власне, вирішили, що функція CheckValidLicense повертає саме прапор успішності операції, а не код помилки? Адже повинна ж вона якось мотивувати причини відмови встановлювати компілятор: файл з ліцензією не знайдений, файл пошкоджений, ліцензія прострочена і так далі? Добре, спробуємо повернути нуль, а якщо це не прокотить, повернемо одиницю.
ОК, пристібатися, поїхали! Запускаємо HIEW, відкриваємо файл ChkLic.dll (якщо ж він не відкривається - тричі пом'янувши ховрахів, тимчасово скопіюємо його в кореневу або будь-яку іншу директорію, що не містить в своєму імені спецсимволов, які так не подобаються hiew "у). Потім, звернувшись ще раз до таблиці експорту, отриманої за допомогою dumpbin, визначаємо адресу функції CheckValidLicense (в даному випадку 010A0h) і через, "10A0" переходимо в її початок. Тепер, - ріжемо по "живому", переписуючи поверх старого коду "XOR EAX, EAX / RETN 4 ". Чому саме" REN 4 ", а не просто" RET "? Та тому, що функція підтримує угоду stdcall, про що можна дізнатися поглянувши в HIEW" e на її епілог (просто проведіть по екрані екран дизассемблера вниз до тих пір, поки не зустрінете RET).
Перевіряємо ... Це працює !!! Незважаючи на відсутність ліцензії, інсталятор, не ставлячи зайвих питань, починає установку! Стало бути, захист впала. Ой, не віриться нам, що все так просто і, щоб не сидіти, втупившись в монітор в очікуванні завершення процесу інсталяції програми, ми нацьковують на setup.exe свій улюблений дизассемблер IDA. Перше, що кидається в очі, відсутність CheckValidLicense в списку імпортованих функцій. Може бути, вона файл ChkLic.exe якось запускає? Пробуємо знайти відповідне посилання серед автоматично розпізнаних рядків: "~ View аNames", "ChkLic" ... ага, рядки "Chklic.exe" тут взагалі немає, але зате виявляється "Chklic.dll". Ага, зрозуміло, значить, бібліотека ChkLic завантажується явною компонуванням через LoadLibrary. І перехід по перехресної посиланням підтверджує це:
Text: 0040175D push offset aChklic_dll; lpLibFileName

Text: 00401762 call ds: LoadLibraryA

Text: 00401762; завантажуємо ChkLic.dll ^^^^^^^^^^^^^^^^^

Text: 00401762;

Text: 00401768 mov esi, eax

Text: 0040176A push offset a_checkvalidlic; lpProcName

Text: 0040176F push esi; hModule

Text: 00401770 call ds: GetProcAddress

Text: 00401770; отримуємо адресу функції CheckValidLicense

Text: 00401770;

Text: 00401776 cmp esi, ebx

Text: 00401778 jz loc_40192E

Text: 00401778; якщо такої бібліотеки немає, то виходимо з програми установки

Text: 00401778;

Text: 0040177E cmp eax, ebx

Text: 00401780 jz loc_40192E

Text: 00401780; якщо такої функції в бібліотеці немає, то виходимо з установки

Text: 00401780;

Text: 00401786 push ebx

Text: 00401787 call eax

Text: 00401787; викликаємо функцію ChekValidLicense

Text: 00401787;

Text: 00401789 test eax, eax

Text: 0040178B jnz loc_4019A3

Text: 0040178; якщо функція поверненню не нуль, то виходимо з програми установки
Неймовірно, але ця жахливо примітивна захист побудована саме так! Причому, півметровий файл ChkLic.exe взагалі не потрібен! І навіщо коштувало тягти його з Інтернету? До речі, якщо ви надумаєте зберігати дістрібьютів компілятора (увага: я не говорив "поширювати"!), То для економії дискового простору ChkLic. * Можна стерти: або пропадчів setup.exe, назавжди відучивши його до них звертатися, або ж просто створивши свою власну ChkLic.dll, що експортує stdcall функцію CheckValidLicence виду: int CheckValidLicence (int some_flag) (return 0;)
Так-с, поки ми все це обговорювали, інсталятор закінчив установку компілятора і благополучно завершив свою роботу. Чи цікаво запуститься компілятор або все найцікавіше тільки починається? Гарячково спускаємося вниз по розгалуженої ієрархії вкладених папок, знаходимо icl.exe, який як і слід було очікувати, знаходиться в каталозі bin, натискаємо і ... Компілятор природно не запускається, посилаючись на те, що "icl: error: could not checkout FLEX lm license" , без якої він не може продовжити свою роботу.
Виходить, що Intel застосувала багаторівневий захист і перший рівень виявився грубою захистом від дурнів. Що ж! Ми приймаємо цей виклик і, спираючись на свій попередній досвід, машинально шукаємо файл LMGR * .DLL в каталозі компілятора. Марно! На цей раз такого файлу тут не виявляється, зате з'ясовується, що icl.exe сильно додав у вазі, переваливши за позначку шестиста кілобайт ... Стоп! А чи не прілінкованние розробники компілятора цей самий FLEX lm статичної компонуванням? Дивимося: в Intel C ++ 5.0 сума розмірів lmgr327.dll і icl.exe становила 598 Кб, а зараз одні лише icl.exe займає 684 Кб. З урахуванням поправки на природне старече "ожиріння", цифри дуже добре сходяться. Значить, все-таки FLEX lm! Ой ой! Але ж тепер, - без символічних імен функцій, ламати захист буде набагато важче ... Втім, не будемо завчасно панікувати! Давайте думати, тільки спокійно! Навряд чи команда розробників повністю переписала весь код, яка взаємодіє з цієї "конвертової" захистом. Швидше за все, її "удосконалення" однією лише зміною типу компонування і закінчилося. А раз так, то шанси зламати програму по раніше великі!
Пам'ятаючи про те, що в минулий раз захисний код знаходиться в функції main, ми, визначивши її адресу, просто встановлюємо точку зупину і, дочекавшись спливання відладчика, тупо трассіруем код, поперемінно поглядів то на відладчик, то на вікно виводу програми: чи не з'явилася там лайливе повідомлення? При цьому, всі зустрілися нам умовні переходи, ми відзначаємо на окремому листку паперу (або відкладаємо в своїй власній пам'яті, якщо ви так хочете), не забувши вказати виконувався чи кожен умовний перехід чи ні ... Стоп! Щось забалакались ми з вами, але ж лайливе повідомлення вже вискочило! ОК добре! Подивимося, який умовний перехід йому відповідав. Наші записи показують, що останнім зустрівся переходом, був умовний перехід JNZ, розташований за адресою 0401075h і "реагує" на результат, повернення процедурою sub_404C0E:

Text: 0040107F loc_40107F:; CODE XREF: _main + 75 ^ j

Text: 0040107F mov eax, offset aFfrps; "FFrps"

Text: 00401084 mov edx, 21h

Text: 00401089 call sub_404C0E

Text: 0040108E test eax, eax

Text: 00401090 jnz short loc_40109A

Очевидно, що sub_404C0E і є та сама захисна процедура, яка здійснює перевірку ліцензії на її наявність. Як її обхитрити? Ну, тут багато варіантів ... По-перше, можна, вдумливо й скрупульозно проаналізувати вміст sub_404C0E на предмет з'ясування: що саме і як саме вона перевіряє. По-друге, можна просто замінити JNZ short loc_40107F на JZ short loc_40107F або навіть NOP, NOP. По-третє, команду перевірки результату повернення TEST EAX, EAX можна перетворити в команду установки нуля: XOR EAX, EAX. По-четверте, можна пропадчіть саму sub_404C0E, щоб вона завжди повертала нуль. Не знаю, як ви, але мені більше всіх сподобався спосіб номер три. Міняємо два байта і запускаємо компілятор. Якщо ніяких інших перевірок його "ліцензійності" в захисті немає, то програма запрацює і, відповідно, навпаки. (Як ми пам'ятаємо, в п'ятій версії таких перевірок було дві). Вражаюче, але компілятор більше не лається і працює !!! Дійсно, як і слід було очікувати, його розробники нітрохи не посилили захист, а, навпаки, навіть послабили її! Кріс Касперски

Компілятори Intel C ++ і Fortran і бібліотека MKL

Поряд зі стандартними для Linux компиляторами GNU, на кластерах обчислювального комплексу НИВЦ встановлені компілятори Intel C ++ і Fortran. На даний час (початок 2006 року) на всіх кластерах встановлені компілятори версії 9.1. Справжня сторінка присвячена опису найбільш важливих опцій і налаштувань цих компіляторів, а також їх основних відмінностей від компіляторів GNU. Сторінка орієнтована, в основному, на користувачів кластерів НИВЦ МГУ, але може бути корисна і іншим російськомовним користувачам. Тут не порушуються питання, пов'язані з компіляцією для платформи IA-64.

Також на всіх кластерах встановлена \u200b\u200bбібліотека Intel Kernel Math Library (MKL) версії 8.0.2. Бібліотека розташовується в каталозі / usr / mkl. Звертаємо увагу на те, що в каталозі lib доступні підкаталоги 32, 64 і em64t. На кластері Ant необхідно використовувати бібліотеки з підкаталогу em64t, а на інших кластерах - з підкаталогу 32. Вся необхідна документація та приклади можуть бути отримані з каталогу / usr / mkl / doc.

Для чого потрібні були нові компілятори?

Необхідність в нових компіляторах виникла, головним чином, а) для підтримки програмування на мові Фортран 90, а також б) для більш потужної оптимізації програм на мові Фортран, ніж забезпечує компілятор g77, що використовує трансляцію в мову Сі і потім компіляцію з допомогою gcc.

Цим вимогам задовольняють також компілятори PGI (Portland Group), але компанія-розробник відмовилася постачати їх в Росію.

Як скористатися?

Компілятори Intel викликаються за допомогою команд icc (C або C ++), icpc (C ++) і ifort (Фортран 77/90). Команди mpicc, mpiCC і mpif77 для компіляції і збірки MPI-програм також налаштовані на використання компіляторів Intel.

Зберігається також можливість користуватися компіляторами GNU за допомогою команд mpigcc, mpig ++ і mpig77 (Фортран 90 не підтримується).

вхідні файли

За замовчуванням, файли з розширенням .cpp і .cxx вважаються вихідними текстами на мові С ++, файли з розширенням .c - вихідними текстами на мові Сі, а компілятор icpc також компілює файли.c як вихідні тексти на С ++.

Файли з розширеннями .f, .ftn і .for розпізнаються як вихідні тексти на мові Фотран, з фіксованою формою записи, а файли .fpp і .F додатково пропускаються через препроцесор мови Фортран. Файли з розширенням .f90 вважаються вихідними текстами Фортран 90/95 з вільною формою записи. Явно можна задати фіксовану або вільну форму записи Фортран-програм за допомогою опцій -FI і -FR відповідно.

Файли з розширенням .s розпізнаються як код на мові асемблера для IA-32.

Характеристики компіляторів Intel

Тут ми наводимо характеристики компіляторів Інтел, як вони заявлені розробником в керівництві користувача з деякими нашими коментарями.

значна оптимізація
мабуть, тут мається на увазі оптимізація коду ще на високому рівні, тобто перш за все, різні перетворення циклів, що з більшим чи меншим успіхом роблять майже всі компілятори
Оптимізація обчислень з плаваючою точкою
мабуть, мається на увазі перш за все максимальне використання команд, реалізованих на апаратному рівні
Межпроцедурние оптимізації
тобто глобальна оптимізація всієї програми, на відміну від звичайної оптимізації, яка зачіпає тільки код конкретних функцій
Оптимізація на базі профілів
тобто можливість прогнати програму в тестовому режимі, зібрати дані про час проходження тих чи інших фрагментів коду всередині часто використовуваних функцій, а потім використовувати ці дані для оптимізації
Підтримка системи команд SSE в процесорах Pentium III
примітка: для обчислювальних задач більший інтерес представляють команди SSE2, тобто векторні команди над 64-розрядними числами, але вони підтримуються тільки в процесорах Pentium 4, яких в нашому розпорядженні поки немає
автоматична векторизація
тобто знову ж таки, використання команд SSE і SSE2, що вставляються автоматично компілятором
Підтримка OpenMP для програмування на SMP-системах
примітка: на кластері рекомендується переважно користуватися інтерфейсом MPI; широке використання OpenMP на кластері НЕ передбачається і таких експериментів поки не проводилося; але, ймовірно, має сенс користуватися бібліотеками (BLAS і ін.), розпаралеленого для спільної пам'яті.
предвибірки даних
тобто мабуть, використання команд попереднього завантаження з пам'яті в кеш даних, які знадобляться через деякий час
"Диспетчеризація" коду для різних процесорів
тобто можливість генерації коду для різних процесорів в одному виконуваному файлі, що дозволяє використовувати переваги новітніх процесорів для досягнення на них максимальної продуктивності, при збереженні двійковій сумісності програм з більш ранніми процесорами; на нашому кластері це поки не актуально, тому що використовуються тільки процесори Pentium III, а також не передбачається передача і запуск на інших машинах програм, відкомпільованих на кластері

Основні опції компіляторів

Найбільш цікавими, звичайно ж, є опції оптимізації коду. Більшість опцій є загальними для компіляторів С ++ і Фортран. більш докладний описом опцій в англомовних інструкціях користувача.

рівні оптимізації
опція	опис
-O0	відключає оптимізацію
-O1 або -O2	Базова оптимізація на швидкість роботи. Відключається інлайн-вставка бібліотечних функцій. Для компілятора С ++ ці опції дають однакову оптимізацію, для компілятора Фортрана опція -O2 краще, тому що включає ще розкрутку циклів.
-O3	Більш потужна оптимізація, включаючи перетворення циклів, передвибірки даних, використання OpenMP. На деяких програмах може не гарантуватися підвищена продуктивність в порівнянні з -O2. Має сенс використовувати разом з опціями векторизації -xK і -xW.
-unroll [n]	Включає розкрутку циклів до n раз.
Оптимізації під конкретний процесор
опція	опис
-tpp6	Оптимізація для процесорів Penitum Pro, Pentium II і Pentium III
-tpp7	Оптимізація для процесорів Penitum 4 (ця опція включена за замовчуванням для компілятора на IA-32)
-xM	Генерація коду з використанням розширень MMX, специфічних для процесорів Pentium MMX, Pentium II і пізніших
-xK	Генерація коду з використанням розширень SSE, специфічних для процесорів Pentium III
-xW	Генерація коду з використанням розширень SSE2, специфічних для процесорів Pentium 4
Межпроцедурная оптимізація
-ip	Чи включається межпроцедурная оптимізація всередині одного файлу. Якщо при цьому вказати опцію -ip_no_inlining, То відключаються інлайн-вставки функцій.
-ipo	Чи включається межпроцедурная оптимізація між різними файлами
Оптимізації з використанням профілів
-prof_gen	Генерується "профілювання" код, який буде використаний для профілювання, тобто збору даних про частоту проходження тих чи інших місць в програмі
-prof_use	Проводиться оптимізація на основі даних, отриманих на етапі профілювання. Має сенс використовувати разом з опцією межпроцедурной оптимізації -ipo.
Розпаралелювання для SMP-систем
-openmp	Чи включається підтримка стандарту OpenMP 2.0
-parallel	Чи включається автоматичне розпаралелювання циклів

продуктивність

Згідно з результатами прогону тестів SPEC CPU2000, опублікованими на сервері ixbt.com, компілятори Intel версії 6.0 практично скрізь виявилися кращими в порівнянні з компіляторами gcc версій 2.95.3, 2.96 і 3.1, і PGI версії 4.0.2. Ці тести проводилися в 2002 році на комп'ютері з процесором Pentium 4 / 1.7 ГГц і ОС RedHat Linux 7.3.

Згідно з результатами тестів, проведених компанією Polyhedron, компілятор Intel Fortran версії 7.0 майже всюди виявився краще в порівнянні з іншими компіляторами Fortran 77 для Linux (Absoft, GNU, Lahey, NAG, NAS, PGI). Тільки в деяких тестах компілятор Intel незначно програє компіляторам Absoft, NAG і Lahey. Ці тести були проведені на комп'ютері з процесором Pentium 4 / 1.8 ГГц і ОС Mandrake Linux 8.1.

Компілятори Intel версії 9.1 також обганяють по продуктивності компіялтори gcc, і показують продуктивність порівнянну з Absoft, PathScale і PGI.

Ми будемо вдячні тим користувачам і читачам, які надішлють нам дані щодо впливу вибору компілятора (GCC або Intel) і опцій оптимізації на швидкість роботи на їх реальних задачах.

бібліотеки

Компілятор мови Сі використовує runtime-бібліотеку, розроблену в рамках проекту GNU ( libc.a).

Разом з компілятором Intel C ++ поставляються наступні бібліотеки:

libcprts.a - runtime-бібліотека мови С ++ розробки Dinkumware.
libcxa.a - додаткова runtime-бібліотека для З ++ розробки Intel.
libimf.a - бібліотека математичних функцій розробки Intel, в яку входять оптимізовані і високоточні реалізації тригонометричних, гіперболічних, експоненційних, спеціальних, комплексних та інших функцій (докладніше див. Список функцій).
libirc.a - runtime-підтримка профілювання (PGO) і "диспетчеризації" коду в залежності від процесора (див. Вище).
libguide.a - реалізація OpenMP.

У цьому списку перераховані статичних бібліотек, але для більшості з них існують також динамічні, тобто підключаються під час запуску, варіанти ( .so).

Разом з компілятором Фортрана поставляються наступні бібліотеки: libCEPCF90.a, libIEPCF90.a, libintrins.a, libF90.a, Також використовується бібліотека математичних функцій libimf.a.

Збірка виконуваного файлу

Підключення бібліотек можливо статичне (під час збирання) або динамічне (під час запуск програми). Динамічний підхід дозволяє зменшити розмір виконуваного файлу, дозволяє розділяти в пам'яті одну і ту ж копію бібліотеки, але для цього необхідно встановити на кожному вузлі, де будуть запускатися програми, повний набір використовуваних динамічних бібліотек.

Таким чином, якщо Ви встановили компілятор Intel на своїй машині з Linux і хочете запускати зібрані виконувані файли на інших машинах, то потрібно або використовувати статичну збірку (що простіше) або скопіювати на ці машини динамічні бібліотеки Intel (зазвичай з директорії виду / opt / intel / compiler70 / ia32 / lib) в одну з директорій, перерахованих у файлі /etc/ld.so.conf, а також подбати про те, щоб на цих машинах було встановлено однаковий набір динамічних бібліотек GNU / Linux.

За замовчуванням, всі бібліотеки розробки Intel (крім libcxa.so) підключаються статично, а всі системні бібліотеки Linux і бібліотеки GNU підключаються динамічно. За допомогою опції -static можна змусити складальник (редактор зв'язків) підключити всі бібліотеки статично (що збільшить обсяг виконуваного файлу), а за допомогою опції -i_dynamic можна підключати динамічно все бібліотеки розробки Intel.

При підключенні додаткових бібліотек за допомогою опції виду -lбібліотека може знадобитися використовувати опцію -Lдіректорія, Щоб задати шлях, де розміщуються бібліотеки.

За допомогою опцій -Bstatic і -Bdynamic можна явно задавати динамічне або статичне підключення кожної з бібліотек, заданих в командному рядку.

За допомогою опції -c збірка виконуваного файлу відключається і виробляється тільки компіляція (генерація об'єктного модуля).

Спільне використання модулів на Фортране і Сі

Щоб спільно використовувати модулі, написані на мовах Фортран і Сі, потрібно узгодити іменування процедур в об'єктних модулях, передачу параметрів, а також доступ до глобальних змінних, якщо такі є.

За замовчуванням, компілятор Intel Fortran переводить імена процедур в нижній регістр і додає в кінець імені знак підкреслення. Компілятор Сі ніколи не зраджує імена функцій. Таким чином, якщо ми хочемо з модуля на Фортране викликати функцію або процедуру FNNAME, реалізовану на Сі, то в модулі на Сі вона повинна іменуватися fnname_.

Компілятор Фортрана підтримує опцію -nus [ім'я файлу], Яка дозволяє відключати додавання знаків підкреслення до внутрішніх іменах процедур. Якщо задано ім'я файлу, то це робиться тільки для імен процедур, перерахованих в заданому файлі.

За замовчуванням, на Фортране параметри передаються по посиланню, а на Сі - завжди за значенням. Таким чином, при виклику Фортран-процедури з модуля на Сі ми повинні в якості параметрів передавати покажчики на відповідні змінні, що містять значення фактичних параметрів. При написанні на Сі функції, яку треба буде викликати з модуля на Фортране, ми повинні описувати формальні параметри як покажчики відповідних типів.

У модулях на Сі можливе використання COMMON-блоків, визначених всередині модулів на Фортране (докладніше про це див. Intel Fortran Compiler User "s Guide, глава Mixing C and Fortran).

Спільне використання компіляторів Intel і GCC

Об'єктні модулі на мові Сі, отримані компілятором Intel C ++, сумісні з модулями, отриманими компілятором GCC і бібліотекою GNU для мови Сі. Таким чином, ці модулі можуть спільно використовуватися в одній програмі, яка збирається за допомогою команд icc або gcc, але для коректного підключення бібліотек Intel рекомендується використовувати icc.

Компілятор Intel підтримує ряд нестандартних розширень мови Сі, що використовуються в рамках проекту GNU і підтримуваних компілятором GCC (але не всі з них, докладніше див. Тут).

Про сумісності об'єктних модулів на мовах С ++ і Фортран в керівництві користувача нічого не сказано, мабуть, вона не підтримується.

підтримка стандартів

Компілятор Intel C ++ Compiler 7.0 for Linux підтримує стандарт мови Сі ANSI / ISO (ISO / IEC 9899/1990). Можливо установка суворої сумісності cо Стадарт ANSI C ( -ansi) Або розширеного діалекту ANSI C ( -Xa). При використанні опції -c99

Керівництва по компіляторам в форматі HTML (доступні в "онлайн" на нашому сервері, але потрібна підтримка мови Java)
Intel C ++ Compiler User "s Guide.
Intel Fortran Compiler User "s Guide.

Керівництва по компіляторам англійською мовою у форматі PDF (потрібно програма Acrobat Reader, потрібно завантажити PDF-файли на свій комп'ютер)
Керівництво користувача по компілятору Intel С ++: Intel C ++ Compiler User "s Guide (1.3 Мбайт, 395 сторінок).
Керівництво користувача по компілятору Intel Fortran: Intel Fortran Compiler User "s Guide (1.1 Мбайт, 285 сторінок).
Довідник програміста на мові Фортран: Intel Fortran Programmer "s Reference (7 Мбайт, 566 сторінок).
Довідник по бібліотеках для мови Фортран: Intel Fortran Libraries Reference Manual (9.5 Мбайт, 881 сторінка).

Керівництво по отладчику Intel Application Debugger.

Порівняння компіляторів на тестах SPEC CPU2000 (стаття на сайті ixbt.com російською мовою).

На сайті компанії Polyhedron представлені результати порівняння різних компіляторів.

Введення кінці 2003 року корпорація Intel представила версію 8.0 своєї колекції компіляторів. Нові компілятори покликані підвищити продуктивність додатків, що працюють на серверах, настільних ПК і мобільних системах (Ноутбуки, мобільні телефони та кишенькові комп'ютери) на базі процесорів Intel. Приємно відзначити, що даний продукт створений за активної участі співробітників нижегородського Центру Intel по розробці ПО і фахівців Intel з Сарова.

Нова серія включає компілятори Intel для мов C ++ і Fortran для ОС Windows і Linux, а також компілятори Intel для мови C ++ для ОС Windows CE .NET. Компілятори орієнтовані на системи на базі наступних процесорів Intel: Intel Itanium 2, Intel Xeon, Intel Pentium 4, процесорів з архітектурою Intel Personal Internet Client Architecture для мобільних телефонів і кишенькових ПК і процесора Intel Pentium M для мобільних ПК (компонент технології Intel Centrino для мобільних ПК).

У компіляторі Intel Visual Fortran для ОС Windows реалізовані технології компіляції нового покоління для високопродуктивних обчислювальних рішень. Він поєднує в собі функціональність мови Compaq Visual Fortran (CVF) і підвищення продуктивності, що стало можливим завдяки технологіям оптимізації компіляції та генерації коду корпорації Intel, і спрощує завдання перенесення вихідного коду, розробленого за допомогою CVF, в середу Intel Visual Fortran. У цьому компіляторі функції CVF вперше реалізовані як для 32-розрядних систем Intel, так і для систем на базі процесорів сімейства Intel Itanium, які працюють в середовищі Windows. Крім того, цей компілятор дозволяє реалізувати мовні функції CVF в системах під управлінням ОС Linux на базі 32-розрядних процесорів Intel і процесорів сімейства Intel Itanium. У 2004 році планується випустити розширену версію цього компілятора - компілятор Intel Visual Fortran Compiler Professional Edition для ОС Windows, до складу якої буде включена бібліотека IMSL Fortran 5.0 Library, розроблена компанією Visual Numerics, Inc.

"Нові компілятори підтримують також майбутні процесори Intel, відомі під кодовою назвою Prescott, в яких передбачені нові команди для підвищення продуктивності графіки і відео, а також інші засоби збільшення продуктивності. Вони також підтримують нову технологію Mobile MMX (tm), аналогічним чином підвищує продуктивність графічних, звукових і відеопріложеній для мобільних телефонів і кишенькових ПК, - зазначив со-директор Центру Intel по розробці ПО в Нижньому Новгороді Олексій Одиноков. - Ці компілятори надають розробникам додатків єдиний комплекс інструментальних засобів для побудови нових додатків для бездротових мереж на основі архітектури Intel. Нові компілятори Intel також підтримують технологію Hyper-Threading корпорації Intel і галузеву специфікацію OpenMP 2.0, визначальну використання директив високого рівня для управління потоками інструкцій в додатках ".

Серед нових інструментів, включених в компілятори - кошти Intel Code Coverage і Intel Test Prioritization. Разом ці кошти дозволяють прискорити розробку додатків і підвищити їх якість за рахунок поліпшення процесу тестування програмного забезпечення.

Засіб Code Coverage в ході тестування програми надає повні відомості про використання логіки програми та про розташування використовуваних ділянок у вихідному коді програми. У разі, якщо в додаток вносяться зміни або якщо даний тест не дозволяє перевірити частина програми, що цікавить розробника, засіб Test Prioritization дозволяє перевірити роботу обраної ділянки програмного коду.

Нові компілятори Intel випускаються в різних комплектаціях вартістю від 399 до 1499 доларів. Їх можна придбати вже сьогодні в корпорації Intel або у реселерів по всьому світу, список яких розташований на сайті http://www.intel.com/software/products/reseller.htm#Russia.

Підтримка процесорів Prescott

Підтримка процесора Intel Pentium 4 (Prescott) у восьмій версії компілятора полягає в наступному:

1. Підтримка команд SSE3 (або PNI, Prescott New Instructions). Тут варто виділити три способи:

а. Асемблерні вставки (Inline assembly). Наприклад, компілятор розпізнає наступне використання команди з набору SSE3 _asm (addsubpd xmm0, xmm1). Таким чином користувачі, зацікавлені в низкоуровневой оптимізації, можуть отримати прямий доступ до асемблерним командам.

б. В С / C ++ компіляторі нові інструкції доступні і з більш високого рівня, ніж використання ассемблерних вставок. А саме, за допомогою вбудованих функцій (intrinsic functions):

вбудовані функції

Вбудована функція	генерируемая команда
_mm_addsub_ps	Addsubps
_mm_hadd_ps	Haddps
_mm_hsub_ps	Msubps
_mm_moveldup_ps	Movsldup
_mm_movehdup_ps	Movshdup
_mm_addsub_pd	Addsubpd
_mm_hadd_pd	Haddpd
_mm_hsub_pd	Hsubpd
_mm_loaddup_pd	movddup xmm, m64
_mm_movedup_pd	movddup reg, reg
_mm_lddqu_si128	Lddqu

У таблиці показані вбудовані функції і відповідні асемблерні команди з набору SSE3. Така ж підтримка існує і для команд з наборів MMX \\ SSE \\ SSE2. Це дозволяє програмісту здійснювати низкоуровневую оптимізацію коду, не вдаючись до програмування на асемблері: компілятор сам піклується про відображення (mapping "е) вбудованих функцій на відповідні команди процесора і раціональне використання регістрів. Програміст може сконцентруватися на створенні алгоритму, ефективно використовує нові набори команд.

в. Автоматична генерація нових команд компілятором. Попередні два способи припускають використання програмістом нових команд. Але компілятор здатний також (при використанні відповідних опцій - см. Секцію 3 нижче) автоматично генерувати нові команди з набору SSE3 для програмного коду на мовах С / C ++ і Fortran. Наприклад, оптимізовану команду невирівняного завантаження (lddqu), використання якої дозволяє отримати виграш по продуктивності до 40% (наприклад, в задачах відео- і аудіокодірованія). Інші команди з набору SSE3 дозволяють отримати суттєве прискорення в задачах 3D графіки або розрахункових задачах з використанням комплексних чисел. Наприклад, графік в секції 3.1 нижче показує, що для додатка 168.wupwise з набору SPEC CPU2000 FP прискорення, отримане від автоматичної генерації команд SSE3 склало ~ 25%. Продуктивність цього додатка істотно залежить від швидкості роботи арифметики комплексних чисел.

2. Використання мікроархітектурнимі переваг процесора Prescott. При генерації коду компілятор враховує мікроархітектурнимі зміни в новому процесорі. Наприклад, виконання деяких операцій (таких як цілочисельні зрушення, множення цілих чисел або перетворення чисел між різними форматами з плаваючою точкою в SSE2) прискорилося на новому процесорі по відношенню до попередніх версій (скажімо, цілочисельний зрушення займає тепер один процесорний такт проти чотирьох для попередньої версії процесора Intel Pentium 4). Більш інтенсивне використання таких команд дозволяє отримати істотне прискорення роботи додатків.
Іншим прикладом мікроархітектурнимі змін служить покращений механізм store forwarding (швидкого завантаження даних, що зберігаються раніше в пам'яті); реальне збереження відбувається навіть не в кеш-пам'ять, а в певний проміжний буфер збереження, що дозволяє здійснити потім дуже швидкий доступ до даних. Така особливість архітектури дає можливість, наприклад, здійснити більш агресивну автоматичну векторизацію програмного коду.
Компілятор також враховує зрослий обсяг кеш-пам'яті першого і другого рівня.

3. Покращена підтримка технології Hyper-Threading. Даний пункт цілком може бути віднесений до попереднього - мікроархітектурнимі змін і їх використання в компіляторі. Наприклад, бібліотека часу виконання, в якій реалізується підтримка галузевої специфікації OpenMP, була оптимізована для виконання на новому процесорі.

продуктивність

Використання компіляторів є простим і ефективний спосіб скористатися перевагами процесорних архітектур Intel. Нижче умовно (вельми) виділені два способи використання компіляторів: а) перекомпіляція програм з можливою зміною налаштувань компілятора, б) перекомпіляція зі зміною як налаштувань компілятора, так і вихідного тексту, а також використанням діагностики компілятора по проведеним оптимізаціям і можливим застосуванням інших програмних засобів ( наприклад, профілювальник).

1.1 Оптимізація програм за допомогою перекомпіляції і зміни налаштувань компілятора

Найчастіше першим кроком в переході на новий оптимізуючий компілятор є його використання з настройками за замовчуванням. Наступний логічний крок - використання опцій для більш агресивної оптимізації. На малюнках 1, 2, 3 і 4 показаний ефект від переходу на интеловский компілятор версії 8.0 в порівнянні з використанням інших лідируючих в галузі продуктів (-O2 - налаштування компіляторів за замовчуванням, base - налаштування на максимальну продуктивність). Порівняння проводиться на 32- і 64-бітних архітектур Intel. В якості тестового набору використовуються додатки з SPEC CPU2000.

Малюнок 1

малюнок 2

малюнок 3

малюнок 4

Нижче перераховані деякі опції (далі по тексту опції наведені для сімейства ОС Windows; для сімейства ОС Linux існують опції з тим же дією, але назва може відрізнятися, наприклад, -Od або QxK для Windows надають аналогічну дію з -O0 або -xK для Linux відповідно; докладнішу інформацію можна знайти в керівництві по використанню компілятора), підтримувані компілятором Intel.

Контроль рівнів оптимізаціїОпції -Od (відсутність оптимізацій; застосовується для налагодження програм), -O1 (максимальна швидкість при мінімізації розміру коду), -O2 (оптимізація за швидкістю виконання коду; застосовується за умовчанням), -O3 (включає найбільш агресивні оптимізації за швидкістю виконання коду ; в деяких випадках може призводити до зворотного ефекту, тобто до уповільнення; потрібно відзначити, що на IА-64 використання -O3 веде до прискорення в більшості випадків, тоді як позитивний ефект на IA-32 менш яскраво виражений). Приклади оптимізацій, що включаються по -O3: перестановка порядку вкладених циклів (loop interchange), злиття циклів (loop fusion), поділ циклу (-ів) (loop distribution; оптимізація, зворотна loop fusion), програмна предвибірки (software prefetch) даних. Причина, по якій можливо уповільнення при використанні -O3, може полягати в тому, що компілятор використовував евристичний підхід до вибору агресивної оптимізації для конкретного випадку, не маючи достатньої інформації про програму (наприклад, згенерував команди передвибірки для даних, які використовуються в циклі, вважаючи, що цикл виконується велика кількість раз, тоді як насправді він має лише кілька ітерацій). Інтерпроцедурная оптимізація по профілізації, а також різноманітні "підказки" програміста (див. Секцію 3.2) можуть допомогти в даній ситуації.

Інтерпроцедурная оптимізація: -Qip (в рамках одного файлу) і -Qipo (в рамках декількох або всіх файлів проекту). Включає такі оптимізації, як, наприклад, інлайн-підстановка часто використовується коду (скорочення витрат на виклик функції / процедури). Надає інформацію іншим стадіях оптимізації - наприклад, інформацію про верхню межу циклу (скажімо, якщо це константа часу компіляції, певна в одному файлі, а використовувана в багатьох) або інформацію про вирівнювання даних в пам'яті (багато команд MMX \\ SSE \\ SSE2 \\ SSE3 працюють швидше, якщо операнди вирівняні в пам'яті на кордон в 8 або 16 байт). Аналіз процедур аллокации пам'яті (реалізованих \\ викликаних в одному з файлів проекту) передається в ті функції \\ процедури, де ця пам'ять використовується (це може допомогти компілятору відмовитися від консервативного припущення, що дані не вирівняні в пам'яті належним чином; а припущення повинно бути консервативним при відсутності додаткової інформації). Ще одним прикладом може служити аналіз перетинів по пам'яті (disambiguation, data aliasing analysis): при відсутності додаткової інформації та неможливості довести відсутність перетинів, компілятор виходить з консервативного припущення, що перетинання є. Таке рішення може негативно позначитися на якості таких оптимізацій, як, наприклад, автоматична векторизація на IA-32 або програмна конвейеризация (software pipelining або SWP) на IA-64. Інтерпроцедурная оптимізація може допомогти в аналізі наявності перетинів по пам'яті.

Оптимізація по профілізації: Включає в себе три стадії. 1) генерацію інструментованого коду за допомогою опції -Qprof_gen. 2) отриманий код запускається на репрезентативних даних, під час роботи збирається інформація про різні характеристики виконання коду (наприклад, ймовірності переходу або типове значення для кількості ітерацій циклу). 3) Повторна компіляція з опцією -Qprof_use, яка забезпечує використання компілятором інформації, зібраної на попередньому кроці. Таким чином, компілятор має можливість використовувати не тільки статичні оцінки важливих характеристик програми, але і дані, отримані під час реального прогону програми. Це може допомогти при подальшому виборі тих чи інших оптимізацій (наприклад, більш ефективне розташування в пам'яті різних гілок програми, грунтуючись на інформації про те, які гілки виконувалися з якою частотою; або застосування оптимізації до циклу на основі інформації про типовий кількості ітерацій в ньому) . Оптимізація по профілізації особливо корисна в тих випадках, коли вдається підібрати невеликий, але репрезентативний набір даних (для кроку №2), який добре ілюструє найбільш типові випадки майбутнього використання програми. У деяких предметних областях вибір такого репрезентативного набору цілком можливий. Наприклад, оптимізація по профілізації використовується розробниками СУБД.

Оптимізації, перераховані вище відносяться до загального (generic) типу, тобто згенерований код буде працювати на всіх різних процесорах сімейства (скажімо, в разі 32-х розрядної архітектури - на всіх нижчеперелічених процесорах: Intel Pentium-III, Pentium 4, включаючи ядро \u200b\u200bPrescott, Intel Pentium M). Існують також оптимізації під конкретний процесор.

Оптимізації, орієнтовані на конкретний процесор: -QxK (Pentium-III; використання команд набору SSE, особливостей мікроархітектури), -QxW і -QxN (Pentium 4; використання команд SSE і SSE2, особливостей мікроархітектури), -QxB (Pentium M; використання команд SSE і SSE2, особливостей мікроархітектури ), QxP (Prescott; використання команд SSE, SSE2, і SSE3, особливостей мікроархітектури). В даному випадку код, згенерований з використанням таких опцій, може не працювати на інших представниках процесорної лінійки (наприклад, -QxW код може привести до виконання неприпустимою команди, якщо виконується на системі на базі процесора Intel Pentium-III). Або працювати не з максимальною ефективністю (наприклад, -QxB код на процесорі Pentium 4 в силу відмінностей в мікроархітектурі). При таких опціях можливо також використання бібліотек часу виконання, оптимізованих під конкретний процесор з використанням його системи команд. Для контролю того, що код виконується дійсно на цільовому процесорі, реалізований механізм диспетчеризації (cpu-dispatch): перевірка процесора під час виконання програми. У різних ситуаціях цей механізм може бути або задіяний, або ні. Диспетчеризація використовується завжди, якщо застосовується варіація опцій -Qax (KWNP). В цьому випадку генерується дві версії коду: оптимізована під конкретний процесор і "загальна" (generic), вибір відбувається під час виконання програми. Таким чином, за рахунок збільшення розміру коду можна домогтися виконання програми на всіх процесорах лінійки і оптимального виконання на цільовому процесорі. Інший варіант полягає у використанні оптимізації коду під попереднього представника лінійки і використання цього коду на цьому і наступних процесорах. Наприклад, -QxN код може виконуватися на Pentium 4 як з ядром Northwood, так і Prescott. Збільшення розміру коду не відбувається. При такому підході можна отримати хорошу, але все-таки не оптимальну продуктивність на системі з процесором Prescott (тому що не використовується SSE3 і не враховуються відмінності в мікроархітектурі) при оптимальній продуктивності на Northwood. Для процесорів архітектури IA-64 також існують подібні опції. На даний момент їх дві: -G1 (Itanium) і -G2 (Itanium 2; опція за замовчуванням).

Наведений нижче графік (рисунок 5) показує прискорення (за початок відліку прийнята одиниця - відсутність будь-якого прискорення) від використання деяких перерахованих вище оптимізацій (а саме -O3 -Qipo -Qprof_use -Qx (N, P)) на процесорі Prescott в порівнянні з установками за замовчуванням (-О2). Використання -QxP допомагає в деяких випадках отримати прискорення в порівнянні з -QxN. Найбільше прискорення досягається в додатку 168.wupwise, вже згадуваному в попередньому розділі (за рахунок інтенсивної оптимізації комплексної арифметики з використанням команд SSE3).

малюнок 5

На малюнку 6 нижче показано співвідношення (в разах) швидкості роботи коду з оптимальними настройками в порівнянні з зовсім неоптимізованими кодом (-Od) на процесорах Pentium 4 і Itanium 2. Видно, що Itanium 2 набагато сильніше залежить від якості оптимізації. Особливо яскраво це виражено для обчислень з плаваючою точкою (FP), де відношення становить приблизно 36 раз. Обчислення з плаваючою точкою є сильною стороною архітектури IA-64, але при цьому треба ретельно підходити до використання максимально ефективних налаштувань компілятора. Отриманий виграш в продуктивності окупає трудовитрати на їх пошук.

Малюнок 6. Прискорення при застосуванні кращих опцій оптимізації SPEC CPU200

Компілятори Intel підтримують галузеву специфікацію OpenMP для створення багатопотокових додатків. Підтримуються явний (опція -Qopenmp) і автоматичний (-Qparallel) режим розпаралелювання. У випадку з явним режимом програміст відповідальний за коректне та ефективне використання коштів стандарту OpenMP. У випадку з автоматичним розпаралелюванням на компілятор лягає додаткове навантаження, пов'язана з аналізом програмного коду. З цієї причини в даний час автоматичне розпаралелювання ефективно працює лише на досить простих кодах.

Графік на малюнку 7 показує прискорення від використання явного розпаралелювання на інженерному (pre-production) зразку системи на базі процесора Intel Pentium 4 (Prescott) з підтримкою технології Hyper-Threading: 2.8GHz, 2GB RAM, 8K L1-Cache, 512K L2-Cache . Як набору тестів використовується SPEC OMPM2001. Цей набір орієнтується на малі і середні SMP системи, витрата пам'яті становить до двох гігабайт. Додатки скомпільовані за допомогою Intel 8.0 C / C ++ і Fortran c двома наборами опцій: -Qopenmp -Qipo -O3 -QxN і -Qopenmp -Qipo -O3 -QxP, з кожним з яких додатки запускалися з включеною і вимкненою технологією Hyper-Threading. Значення прискорень на графіку нормалізовані на продуктивність однопотокові версії при вимкненому технології Hyper-Threading.

Малюнок 7: За допомогою програми набору SPEC OMPM2001 на процесорі Prescott

Видно, що в 9-ти з 11-ти випадків використання явного розпаралелювання за допомогою OpenMP дає приріст продуктивності при включенні технології Hyper-Threading. В одному з додатків (312.swim) спостерігається уповільнення. Це відомий факт: дане додаток характеризується високим ступенем залежності від пропускної здатності пам'яті. Так само, як і у випадку зі SPEC CPU2000, додаток wupwise значно виграє від застосування оптимізацій під Prescott (-QxP).

1.2 Оптимізація програм з внесенням змін у вихідний текст і використанням діагностики компілятора

У попередніх секціях ми розглядали вплив компілятора (і його налаштувань) на швидкість виконання програмного коду. У той же час компілятори Intel представляють більш широкі можливості для оптимізації коду, ніж просто зміни налаштувань. Зокрема, компілятори дають можливість програмісту робити "підказки" (hints) в коді програми, які дозволяють здійснювати генерацію більш ефективного коду з точки зору продуктивності. Нижче - деякі приклади для мови С / C ++ (для мови Fortran існують аналогічні засоби, що відрізняються лише синтаксисом).

#pragma ivdep (де ivdep означає ignore vector dependencies) застосовується перед програмними циклами, щоб повідомити компілятору, що всередині немає залежностей за даними. Ця підказка працює в тому випадку, коли компілятор (на основі аналізу) консервативно передбачає, що такі залежності можуть бути (якщо компілятор в результаті аналізу може довести, що залежність існує, то "підказка" не робить ніякого дії), тоді як автор коду знає , що таких залежностей не може виникнути. За допомогою цієї підказки компілятор може згенерувати більш ефективний код: автоматична векторизація для IA-32 (використання векторних команд з наборів MMX \\ SSE \\ SSE2 \\ SSE3 для програмних циклів на С / C ++ і Fortran; більш докладно познайомитися з цією технікою можна, наприклад, в наступній статті в Intel Technology Journal), Програмна конвейеризация (SWP) для IA-64.

#pragma vector always застосовується, щоб компілятор змінив рішення про неефективність векторизації циклу (як автоматичної для IA-32, так і SWP для IA-64), зроблене на основі аналізу кількісних і якісних показників роботи на кожній ітерації.

#pragma novector надає дію, зворотне #pragma vector always.

#pragma vector aligned використовується, щоб повідомити компілятору, що дані, які використовуються в циклі, вирівняні на кордон в 16 байт. Це дозволяє генерувати більш ефективний і / або компактний (через відсутність перевірок під час виконання) код.

#pragma vector unaligned надає дію, зворотне #pragma aligned. Про виграш в продуктивності в цьому випадку говорити складно, але можна розраховувати на більш компактний код.

#pragma distribute point використовується всередині програмного циклу, для того, щоб компілятор міг розбити цикл (loop distribution) в цій точці на кілька дрібніших. Наприклад, подібна "підказка" може бути використана в тому випадку, коли компілятор не вдається зробити автоматичну векторизацію вихідного циклу (наприклад, через залежність за даними, яку не можна ігнорувати навіть при наявності #pragma ivdep), тоді як кожен (або частина) з новостворених циклів може бути ефективно векторизованних.

#pragma loop count (N), застосовується для того, щоб повідомити компілятору, що найбільш ймовірне значення кількості ітерацій циклу дорівнюватиме N. Ця інформація допомагає прийняти рішення про найбільш ефективної оптимізації для цього циклу (наприклад, чи потрібно робити розгортку, чи потрібно робити SWP або автоматичну векторизацію, чи потрібно використовувати команди програмної передвибірки даних, ...)

"Підказка" _assume_aligned (p, base) застосовується для того, щоб повідомити компілятору, що область пам'яті, що асоціюється з покажчиком p, вирівняна на кордон в base \u003d 2 ^ n байт.

Це далеко не повний список різних "підказок" компілятору, які можуть істотно вплинути на ефективність генерованого коду. Може виникнути питання про те, як визначити, що компілятору потрібна підказка.

По-перше, можна використовувати діагностику компілятора у вигляді звітів, які він надає програмісту. Наприклад, при використанні опції -Qvec_reportN (де N змінюється від 0 до 3 і означає рівень деталізації) можна отримати звіт про автоматичну векторизації. Програмісту буде доступна інформація про те, які цикли були векторизованних, а які - ні. У негативному випадку компілятор вказує в звіті причини, за якими векторизация не вдалася. Припустимо, що причиною стала консервативно передбачувана залежність за даними. У такому випадку, якщо програміст впевнений, що залежно виникнути не може, то можливе застосування #pragma ivdep. Аналогічні (порівнюючи з Qvec_reportN для IA-32) можливості компілятор являє на IA-64 для контролю наявності та ефективності SWP. В цілому, компілятори Intel представляють широкі можливості для діагностики оптимізацій.

По-друге, інші програмні продукти (такі, наприклад, як профілювальник Intel VTune) можуть використовуватися для пошуку "вузьких місць" в коді з точки зору продуктивності. Результати аналізу можуть допомогти програмісту зробити необхідні зміни.

Можна також використовувати для аналізу асемблерний лістинг коду, що генерується компілятором.

малюнок 8

Вище на малюнку 8 показаний покроковий процес оптимізації програми за допомогою компілятора (і інших програмних продуктів) Intel на мові Fortran для архітектури IA-64. Як приклад розглядається неадіабатичних регіональна схема прогнозу на 48 годин Росгідрометцентру (можна прочитати про неї, наприклад, в цій статті. У статті йдеться про час розрахунку близько 25 хвилин, але з часу її написання відбулися значні зміни. В якості точки відліку взята продуктивність коду на системі Cray-YMP. Незмінений код з опціями компілятора за замовчуванням (-O2) показав приріст продуктивності в 20% на чотирипроцесорний системі на базі процесора Intel Itanium 2 900 MHz. Застосування більш агресивною оптимізації (-О3) привело до прискорення в ~ 2.5 рази без зміни коду в основному за рахунок SWP і передвибірки даних. Аналіз за допомогою діагностики компілятора і Профілювальники Intel VTune виявив деякі "вузькі місця". Наприклад, компілятор не зробив програмну конвейеризацию кількох важливих для продуктивності циклів, повідомивши в звіті, що передбачає залежність за даними . Невеликі зміни коду (директива ivdep) допомогли добитися еффе ктівной конвейеризации. За допомогою Профілювальники VTune вдалося виявити (а звіт компілятора це підтвердив), що компілятор не зробив зміни порядку вкладених циклів (loop interchange) для більш ефективного використання кеш-пам'яті. Причиною знову з'явилися консервативні припущення про залежність за даними. Зміни були зроблені в початковому тексті програми. В результаті вдалося домогтися 4-кратного прискорення по відношенню до початкової версії. Використання явного розпаралелювання за допомогою директив стандарту OpenMP, а потім перехід на систему з процесорами більш високої частоти дозволили скоротити час рахунку до показника менше 8 хвилин, що дало більш ніж 16-кратне прискорення в порівнянні з початковою версією.

Intel Visual Fortran

В Intel Visual Fortran 8.0 використовуються front-end (частина компілятора, що відповідає за перетворення програми з тексту на мові програмування у внутрішнє представлення компілятора, яке багато в чому не залежить ні від мови програмування, ні від цільової машини) технології компілятора CVF і компоненти интеловского компілятора, що відповідають за набір оптимізацій і генерацію коду.

малюнок 9

малюнок 10

На малюнках 9 і 10 дано графіки порівняння продуктивності Intel Visual Fortran 8.0 з попередньою версією Intel Fortran 7.1 і з іншими популярними в галузі компиляторами з цієї мови, що працюють під управлінням ОС сімейств Windows і Linux. Для порівняння використовувалися тести, вихідні тексти яких, задовольняють стандартам F77 і F90, доступні на сайті http://www.polyhedron.com/. На цьому ж сайті доступна більш детальна інформація про порівняння продуктивності компіляторів (Win32 Compiler Comparisons -\u003e Fortran (77, 90) Execution Time Benchmarks і Linux Compiler Comparisons -\u003e Fortran (77, 90) Execution Time Benchmarks): показано більше різних компіляторів, а геометричне середнє дано в поєднанні з індивідуальними результатами кожного тесту.

Ти - не раб!
Закритий освітній курс для дітей еліти: "Істинне облаштування світу".
http://noslave.org

Матеріал з Вікіпедії - вільної енциклопедії

Intel C ++ Compiler