Чи компілятори Intel справді краще, ніж Microsoft? [зачинено]

Роки тому я був здивований, коли виявив, що Intel продає компілятори, сумісні з Visual Studio. Я спробував це, зокрема, для C / C ++, а також фантастичних засобів діагностики. Але код просто не був таким обчислювально інтенсивним, щоб помітити різницю. Єдине враження було: чи справді Intel це зробив для мене просто зараз, дивовижні інструменти з роздільною здатністю наносекунд, неймовірні. Але судовий процес закінчився, і команда ніколи серйозно не розглядала покупку.

З вашого досвіду, якщо вартість ліцензії не має значення, який постачальник є переможцем?

Це не широке чи розпливчасте питання чи спроба розпалити святу війну. Таке питання стосується двох дуже помітних інструментів. Ніхто не любить, коли в інструментах є якісь таємниці чи сюрпризи. І вибір між найкращим і найкращим - це завжди біль. Я також розумію, що трава завжди більш зелений аргумент. Я хочу почути всі історії про "що таке".

Що робити, якщо Intel просто локально оптимізує його для того, щоб чіп місяця почався, і не кожна апаратна ціль справді буде працювати так само добре, як Microsoft зібрана? Що робити, якщо апаратне забезпечення AMD є цільовим, і все сповільниться без причини? Або, з іншого боку, що робити, якщо апаратне забезпечення Intel має стільки непомітних можливостей, що письменники-компілятори Microsoft занадто повільно сприймають і ніколи не реалізують його у компіляторі? Що робити, якщо обидва точно однакові, насправді єдина кодова база, просто загорнута у дві різні коробки та ліцензована обома постачальниками стороннім магазином?

І так далі. Але хтось знає деякі відповіді.

ПОПЕРЕДЖЕННЯ: Відповідь на основі власного досвіду - YMMV

Якщо код справді обчислювально дорогий, так, безумовно . Я бачив покращення в 20 разів у порівнянні з колишнім компілятором Intel C ++ (тепер, якщо я правильно пам'ятаю Intel Studio) порівняно зі стандартним компілятором Microsoft Visual C ++. Це правда, що код був дуже далекий від ідеального, і це, можливо, зіграло певну роль (насправді саме тому ми потрудилися використовувати компілятор Intel. Це було простіше, ніж рефакторинг гігантської кодової бази); також процесор, який використовувався для запуску коду, був Intel Core 2 Квадрат, який є ідеальним процесором для такої речі, але результати були шокуючі. Сам компілятор містить безліч способів оптимізації коду, включаючи націлювання на певний процесор з точки зору, скажімо, можливостей SSE . Це справді змушує -O2/ -O3тікає соромно. І це булоперед використанням профілера.

Зауважте, що, якщо включити дійсно агресивні оптимізації, компіляція змусить зайняти досить багато часу, дві години для великого проекту зовсім не неможливі. Крім того, при високому рівні оптимізації є більша ймовірність виявлення помилки в коді (це може спостерігатися і при gcc -O3). Для добре знайомого вам проекту це може бути плюсом, оскільки ви знайдете і виправите будь-які можливі помилки, яких ви не спіймали раніше, але при складанні волохатого безладу ви просто схрещуєте пальці і молитеся богам x86.

Щось про продуктивність на машинах AMD: Це не так добре, як процесори Intel, але все-таки набагато краще, ніж компілятор MS C ++ (знову ж таки, з мого досвіду). Причина полягає в тому, що ви також можете орієнтуватися на загальний процесор із підтримкою SSE2 (наприклад). Тоді процесори AMD із SSE2 не будуть сильно дискриміновані. Хоча компілятор Intel на процесорі Intel справді краде шоу. Однак це не всі подвійні веселки та блискучі єдинороги. Були важкі звинувачення у тому, що бінарні файли взагалі не працюють на не-справжніх процесорах InternetIntel, і (це визнано) штучно спричинені низькою продуктивністю на процесорах інших постачальників. Також зауважте, що це інформація щонайменше 3 роки тому, і термін її дії на сьогоднішній день невідомий, АЛЕ нові описи продуктів дають бінарним файлам карт-бланш працювати так само повільно, як Intel вважає за потрібне на процесорах, що не є Intel.

Я не знаю, про що йдеться в Intel і чому вони роблять такі хороші інструменти для числення, але погляньте і на це: http://julialang.org/ . Існує порівняння, і якщо ви подивитесь на останній рядок, MATLAB світиться, перемігши і код C, і Julia , мене вражає те, що автори вважають, що причина - бібліотека Math Kernel Intel від Intel .

Я усвідомлюю, що це дуже схоже на рекламу інструментарію Intel Compiler, але, на моєму досвіді, це справді добре зробило цю роботу, і навіть проста логіка наказує, що хлопці, які складають процесори, повинні найкраще знати, як програмувати для них. IMO, компілятор Intel C ++ видавлює кожен останній можливий приріст продуктивності.

Intel Compiler має репутацію виробника дуже ефективного цифрового коду:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Зверніть увагу , що я не стверджую , що він є найшвидшим компілятором там, але це , безумовно , має дуже хорошу репутацію ефективності. Зауважте, що автори "офіційних" бінарних файлів LAPACK для Windows використовують компілятор Intel Fortran для їх побудови: http://icl.cs.utk.edu/lapack-for-windows/ і вони повинні знати щось про ефективність.

Крім генератора коду, Intel C ++ має кілька переваг перед gcc. Обидва вони випливають (в основному) з того, що він заснований на передній частині EDG . На краще чи гірше, і те й інше (повільно) стираються, тому переваги не є настільки великими, як колись.

Перший полягає в тому, що він, як правило, видає набагато кращі повідомлення про помилки. Ви можете переглянути порівняння повідомлень про помилки між Clang та gcc. Intel C ++ (нарівні з більшістю інших на базі EDG-інтерфейсу) впродовж багатьох років випускає діагностику, подібну до Кланг.

По-друге, це те, що передній край EDG приблизно так само відомий надзвичайно хорошою мовою, оскільки генератор коду Intel призначений для створення швидкого коду. Практично за будь-якої розумної міри, передній край EDG забезпечує кращу відповідність C ++ 98, 03 або (у сучасних версіях) C ++ 0x, ніж будь-який інший доступний компілятор.

Як я вже говорив, обидва ці переваги з часом стиралися в різній мірі. Останні версії gcc мають досить гідну відповідність мові. Clang має значно кращі повідомлення про помилки, і він непогано просувається на шляху впровадження всієї мови C ++. Якщо ви перейдете до цього, Intel C ++ все-таки краще, ніж будь-який з обох питань, і це єдиний пакет, який робить більшість справ правильно, замість того, що потрібен один компілятор для гарної діагностики та інший для кращої відповідності та створення коду.

Ми спробували це на роботі деякий час назад. Більшість нашої кодової бази знаходиться в Delphi, але у нас є кілька високо обчислювальних функціональних можливостей, які хтось вважав, що це було б хорошою ідеєю зробити на C ++ DLL зворотній шлях, коли. І один з моїх колег чув чудові речі про компілятор Intel, тому він вирішив спробувати це. Ми відновили DLL у компіляторі Intel і провели кілька тестів на швидкість, і результати його настільки здивували, що він зрозумів, що він повинен щось робити не так.

DLL повинен обчислити деякі дуже складні проблеми з компонентами комбінаторики та топології, які технічно знаходяться в NP-важкому класі складності, якщо ми зробили їх «правильно», але ми використовуємо різні евристики, щоб уникнути продуктивності NP. Незважаючи на це, відбувається велика кількість хрускіт у кількості. А для тестів, які ми проводили, різниця між компілятором VS та компілятором Intel була або в межах epsilon, або компілятор Intel був помітно повільнішим, як правило, десь у районі 20%. І це було так, незалежно від того, які зміни він вніс у параметри компіляції, щоб спробувати змусити компілятор Intel створити швидший код. Отже ми не перейшли на це.

Це, звичайно, лише один приклад із реального світу. Ваш пробіг може відрізнятися.

У вбудованому додатку, над яким я колись працював, випробування компілятора Intel показало, що це допоможе нам врятувати нове обладнання з більш високою продуктивністю. Вартість нового обладнання склала близько 10 доларів / одиниця, прогнозований продаж у 1 мільйон одиниць, додайте вартість розробки та затримки проекту. Варіант 2 був профілем / мікрооптимізацією вже досить добре профільованої / оптимізованої бази коду - невідомі результати, невідомий час.

Як ви думаєте, що сказав бос, коли ми попросили кошти на придбання компілятора .......

Однак - це був дуже вдалий і рідкісний випадок - 10% швидший вихід коду з компілятора Intel підштовхнув нас до правильної сторони продуктивності. Якби ми вже були з правого боку або були на 10% більше, це не мало б значення. Якби у нас були інженери, ми, ймовірно, могли б оптимізувати код і врятували апаратне обертання, і не знадобився компілятор Intel, але ризик був високим і компілятор Intel працював дешевше, ніж інженерний час.

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

Я зіткнувся лише з трьома перевагами:

1. Він підтримує функції новіших процесорів Intel набагато швидше, ніж інші компілятори.

2. Це чудовий додатковий компілятор для видачі попереджень та пошуку проблем, які пропускають інші компілятори. GCC вловлює деякі речі, які ICC не робить, і навпаки. Візуальна студія вловлює деякі речі, яких ICC не робить, і навпаки.

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

Ми використовуємо компілятор Intel для кожного проекту критичної продуктивності нашої кодової бази. Чудова річ у тому, що вона робить оптимізацію коду справді бездоганною. Замість того, щоб вручну додавати __мм дзвінки скрізь і казати компілятору попередньо вибирати дані, що в наступному випуску знову буде оптимальним, ви просто переставите код і отримаєте шалене прискорення.

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

Те ж саме стосується і компілятора arm (from arm, not intel), якщо ваш випуск на руку робить велику роботу у векторизації для вас.

Перевірте цю сторінку орієнтирів. Коротше кажучи, Intel виграє.

Але маржа може бути не такою великою: якщо ви компілюєте в 32 біт і ваша система збирання не може підтримувати профільну оптимізацію профілю, коефіцієнт виграшу складає близько 10%. Невже таке вдосконалення вартує клопоту і довших термінів складання?

Повідомлялося, що Intel випустила Intel C ++ Compiler v13.0 для ОС Android, його перша спроба поставити оптимізуючий компілятор C / C ++, розроблений спеціально для мобільної платформи Google.

Розробники можуть використовувати компілятор у системах на базі Linux * для створення додатків для пристроїв Android на базі процесорів Intel, включаючи процесор Intel® Atom ™. Компілятор Intel сумісний з GNU C ++ та інструментами для розробників в Android Native Development Kit (NDK). Ви також не можете використовувати компілятор на будь-якій машині розробки. Ні Windows, ні OS X не підтримуються; інструменти сертифіковані лише для використання з Ubuntu 10.04 або 11.04

Поточна версія Android NDK використовує за замовчуванням версію 4.6 відкритого коду Gnu Compiler Collection (GCC). Але компілятори Intel включають безліч фірмових оптимізацій для власних чіпів, і вони часто можуть виводити виконуваний код, який працює краще, ніж той, який виробляють сторонні компілятори, такі як GCC.