Як мова, чий компілятор написаний на C, коли-небудь може бути швидшою за C?

Переглянувши веб-сторінку Джулії , ви можете побачити деякі орієнтири з декількох мов через декілька алгоритмів (терміни, показані нижче). Як мова з компілятором, спочатку написаним на C, перевершує код C?

Малюнок: еталонні часи щодо C (менший, тим краще, продуктивність C = 1,0).

Немає необхідного зв’язку між реалізацією компілятора та результатом компілятора. Ви можете написати компілятор такою мовою, як Python або Ruby, найпоширеніші реалізації якої дуже повільні, і цей компілятор може вивести високооптимізований машинний код, здатний перевершити C. Сам компілятор зайняв би багато часу, тому що йогокод пишеться повільною мовою. (Якщо бути точнішим, написано мовою з повільною реалізацією. Мови насправді не є по суті швидкими чи повільними, як вказує Рафаель у коментарі. Я розширюю цю ідею нижче.) Складена програма буде такою ж швидкою, як і її власна реалізація дозволена - ми могли б написати компілятор у Python, який генерує той же машинний код, що і компілятор Fortran, і наші компільовані програми були б такими ж швидкими, як і Fortran, хоча їх збирання зайняло б тривалий час.

Це вже інша історія, якщо ми говоримо про перекладача. Перекладачі повинні працювати під час роботи програми, яку вони інтерпретують, тому існує зв'язок між мовою, якою реалізовано перекладач, та виконанням інтерпретованого коду. Для здійснення інтерпретованої мови, яка працює швидше, ніж мова, якою реалізований інтерпретатор, потрібна певна розумна оптимізація, і остаточна ефективність може залежати від того, наскільки придатний фрагмент коду до цього виду оптимізації. У багатьох мовах, таких як Java та C #, використовуються умови виконання з гібридною моделлю, яка поєднує деякі переваги перекладачів та деякі переваги компіляторів.

Як конкретний приклад, давайте докладніше розглянемо Python. У Python є кілька реалізацій. Найпоширеніший - CPython, інтерпретатор байт-кодів, написаний на C. Існує також PyPy, який написаний на спеціалізованому діалекті Python під назвою RPython, і який використовує гібридну компіляційну модель, схожу на JVM. PyPy набагато швидший, ніж CPython у більшості еталонів; він використовує всілякі дивовижні хитрощі для оптимізації коду під час виконання. Однак мова Python, якою керує PyPy, точно та сама мова Python що і CPython, забороняючи кілька відмінностей, які не впливають на продуктивність.

Припустимо, ми написали компілятор мовою Python для Fortran. Наш компілятор виробляє той же машинний код, що і GFortran. Тепер ми складаємо програму Fortran. Ми можемо запустити наш компілятор поверх CPython або ми можемо запустити його на PyPy, оскільки він написаний на Python і обидві ці реалізації реалізують одну й ту ж мову Python. Що ми знайдемо, це те, що якщо ми запустимо наш компілятор на CPython, потім запустимо його на PyPy, потім компілюємо той самий джерело Fortran з GFortran, ми отримаємо абсолютно один і той же машинний код усі три рази, тому скомпільована програма завжди буде працювати приблизно з однаковою швидкістю. Однак час, необхідний для створення цієї складеної програми, буде іншим. CPython, швидше за все, займе більше часу, ніж PyPy, а PyPy, швидше за все, займе більше часу, ніж GFortran, хоча всі вони будуть видавати один і той же машинний код в кінці.

Якщо сканувати таблицю орієнтирів веб-сайту Julia, схоже, що жодна з мов, що працюють на перекладачах (Python, R, Matlab / Octave, Javascript), не має жодних орієнтирів, де вони б'ють C. Це, як правило, відповідає тому, що я б очікував побачити, хоча я міг собі уявити код, написаний із високооптимізованою бібліотекою Numpy Python (написаною на C та Fortran), яка перемагає деякі можливі C-реалізації подібного коду. Мови, що дорівнюють або краще, ніж C, складаються (Fortran, Julia ) або використовуються гібридна модель з частковою компіляцією (Java, і, ймовірно, LuaJIT). PyPy також використовує гібридну модель, тому цілком можливо, що якби ми застосували той самий код Python на PyPy замість CPython, ми насправді побачимо, як він переміг C за деякими орієнтирами.

Як машина, побудована людиною, може бути сильнішою за людину? Це саме те саме питання.

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

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

Немає такого поняття, як повільна чи швидка мова. ¹

На нашому шляху до центрального процесора насправді щось робить, є багато кроків².

1. Принаймні один програміст з певними наборами навичок.
2. (Формальна) мова, якою вони запрограмовані ("вихідний код").
3. Бібліотеки, якими вони користуються.
4. Щось, що переводить вихідний код у машинний код (компілятори, інтерпретатори).
5. Загальна архітектура обладнання, наприклад, кількість процесорних одиниць та макет ієрархії пам'яті.
6. Операційна система, яка управляє обладнанням.
7. Оптимізація процесора.

Кожен окремий предмет вносить свій внесок у фактичний час виконання, який ви можете виміряти, іноді сильно. Різні "мови" орієнтуються на різні речі³.

Просто навести кілька прикладів.

• 1–2–4 : середній програміст на C може створити набагато гірший код, ніж середній програміст Java, як з точки зору правильності та ефективності. Це тому, що програміст має більше обов'язків у С.

• 1/4 проти 7 : мовою низького рівня, як C, ви можете користуватися певними функціями процесора як програміст . У мовах вищого рівня це може робити лише компілятор / інтерпретатор, і лише якщо вони знають цільовий процесор.

• 1/4 проти 5 : чи потрібно або потрібно контролювати макет пам'яті, щоб найкраще використовувати архітектуру пам'яті під рукою? Деякі мови дають вам контроль над цим, деякі - не.

• 2/4 vs 3 : Інтерпретований сам Python жахливо повільний, але існують популярні прив'язки до високооптимізованих , власне складених бібліотек для наукових обчислень. Тож виконання певних речей у Python в кінці кінців швидко , якщо більшість робіт виконується цими бібліотеками.

• 2 проти 4 : Стандартний перекладач Ruby досить повільний. JRuby, з іншого боку, може бути дуже швидким. Ця ж мова швидко використовується іншим компілятором / інтерпретатором.

• 1/2 проти 4 : Використовуючи оптимізацію компілятора, простий код можна перевести у дуже ефективний машинний код.

Суть полягає в тому, що знайдений вами орієнтир не має особливого сенсу, принаймні, не тоді, коли ви звернетесь до тієї таблиці, яку ви включите. Навіть якщо все, що вас цікавить, працює час, вам потрібно вказати весь ланцюг від програміста до процесора; заміна будь-якого з елементів може суттєво змінити результати.

Щоб було зрозуміло, це відповідає на питання, оскільки це показує, що мова, якою написаний компілятор (крок 4), є лише однією частиною головоломки і, ймовірно, зовсім не актуальною (див. Інші відповіді).

1. Звичайно, є мовні особливості, які дорожче реалізувати, ніж інші. Але наявність функцій не означає, що вам доведеться ними користуватися, а дорога функція може заощадити використання багатьох дешевших і, таким чином, оплатити в підсумку. (Є інші переваги, які не піддаються вимірюванню під час роботи.)
2. Я пропускаю алгоритмічний рівень, тому що він не завжди застосовується і здебільшого не залежить від мови програмування, що використовується. Майте на увазі, що різні алгоритми, наприклад, піддаються різному апаратному забезпеченню.

3. Я навмисно не вдаваюся в різні показники успіху тут: ефективність часу роботи, ефективність пам’яті, час розробника, безпека, безпека, (доказна?) Коректність, підтримка інструментів, незалежність платформи, ...

   Порівнювати мови wrt з однією метрикою, навіть якщо вони були розроблені для зовсім інших цілей - це величезна помилка.

Тут є одна забута річ щодо оптимізації.

Були тривалі дискусії з приводу того, що фортран випереджав C. Розрізнюючи неправильні дебати: той самий код був написаний на C та fortran (як вважали тестери), а ефективність тестувалася на основі тих же даних. Проблема полягає в тому, що ці мови відрізняються, C дозволяє вказувати вказівники, а fortran - ні.

Таким чином, коди були не однаковими, у тестованих файлах C не було __restrict, що дало відмінності, після переписування файлів, щоб сказати компілятору, що він може оптимізувати покажчики, час виконання стає подібним.

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

$X$

По-друге, VM може виконувати випробування тиском під час роботи, тому він може приймати тиск коду та оптимізувати його або навіть попередньо розраховувати його під час виконання. Заздалегідь складена програма C не очікує, де знаходиться тиск, або (більшість часу) є загальні версії виконуваних файлів для загального сімейства машин.

У цьому тесті є також JS, і є швидші VM, ніж V8, і він також виконує швидше, ніж C у деяких тестах.

Я перевірив це, і були унікальні методи оптимізації, які ще не доступні в компіляторах C.

Компілятору C доведеться одразу робити статичний аналіз цілого коду, піти на задану платформу та обійти проблеми з вирівнюванням пам’яті.

VM просто транслітерував частину коду, щоб оптимізувати збірку та запустити її.

Про Джулію - коли я перевіряв, що вона працює на коді AST, наприклад, GCC пропустив цей крок, нещодавно почав брати звідти інформацію. Це плюс інші обмеження та методи VM можуть трохи пояснити.

Приклад: візьмемо простий цикл, який бере початкову кінцеву кінцеву точку від змінних і завантажує частину змінних в обчислення, відомі під час виконання.

Компілятор C генерує змінні завантаження з регістрів.
Але під час виконання ці змінні відомі і трактуються як константи через виконання.
Тож замість завантаження змінних з регістрів (і не виконують кешування, оскільки це може змінитися, а зі статичного аналізу не зрозуміло) вони трактуються повністю як константи і складаються, поширюються.

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

Додаючи до цієї відповіді, слід зазначити, що нині компілятори C написані у C. Звичайно, як зазначає Рафаель, їх вихід та його продуктивність можуть залежати, серед іншого, від ЦП, на якому він працює. Але це також залежить від кількості оптимізації, виконаної компілятором. Якщо ви пишете на C кращий оптимізуючий компілятор для C (який ви потім компілюєте зі старим, щоб мати змогу запустити його), ви отримаєте новий компілятор, який робить C швидшою мовою, ніж це було раніше. Отже, яка швидкість С? Зауважте, що ви навіть можете скласти новий компілятор із собою, як другий прохід, щоб він компілював більш ефективно, хоча все ж давав той самий об'єктний код. І повна теорема зайнятості показує, що їхнім вдосконаленням не є кінцем (завдяки Рафаелю за вказівник).

Але я думаю, що варто спробувати формалізувати це питання, оскільки воно дуже добре ілюструє деякі фундаментальні поняття, а особливо денотаційне та оперативне бачення речей.

Що таке компілятор?

$C_{S\to T}$$C$$\mathcal C_{S\to T}$$P_{:S}$$\mathcal P$ $S$$P_{:T}$ $T$$\mathcal P$

$\mathcal C_{S\to T}$$C_{S\to T}$$\{(P_{:S},P_{:T})\mid P_S\in S \wedge P_T\in T\}$

$\mathcal C_{S\to T}$$P_S$$P_T$$\mathcal P$

$P_{:T}$$P_{:S}$$\mathcal C_{S\to T}$

Уточнюючи аргумент, ми, мабуть, хочемо, щоб компілятор мав хорошу ефективність, щоб переклад можна було виконати у розумні строки. Тому продуктивність програми компілятора має значення для користувачів, але це не впливає на семантику. Я кажу про ефективність, тому що теоретична складність деяких компіляторів може бути набагато вищою, ніж можна було б очікувати.

Про завантажувальне завантаження

Це проілюструє відмінність та покаже практичне застосування.

$S$$I_S$$C_{S\to T\,:S}$$S$$C_{S\to T\,:S}$$I_S$$P_{:S}$$P_{:T}$$S$$T$

Але ви можете використовувати цей інструмент компіляції для компіляції компілятора $C_{S\to T\,:S}$$S$$C_{S\to T\,:T}$$T$$T$$T$

За теоремою про прискорення Blum є програми, які записані та запущені на найшвидшій комбінації комп'ютер / компілятор, працюватимуть повільніше, ніж програма для того ж на вашому першому ПК, що працює з інтерпретованим BASIC. Просто немає "найшвидшої мови". Все, що ви можете сказати, це те, що якщо ви пишете один і той же алгоритм декількома мовами (реалізаціями; як зазначалося, навколо є багато різних компіляторів C, і я навіть натрапив на досить спроможного інтерпретатора C), він буде працювати швидше або повільніше в кожній .

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

Повернемось до початкового рядка: "Як мова, чий компілятор написаний на C, коли-небудь може бути швидшим, ніж C?" Я думаю, що це справді мало на меті сказати: як програма, написана на Джулії, серцевина якої написана на С, може бути швидшою, ніж програма, написана на С? Зокрема, як програма "мандель", написана в Джулії, може працювати у 87% часу виконання еквівалентної програми "мандель", написаної на C?

Трактат Бабу - єдина правильна відповідь на це питання поки що. Усі інші відповіді поки що більш-менш відповідають на інші запитання. Проблема з текстом бабу полягає в тому, що теоретичний опис "Що таке компілятор" довгий у кількох абзацах написано так, що оригінальний плакат, ймовірно, матиме проблеми з розумінням. Той, хто сприймає поняття, на які посилаються слова "семантичний", "денотаційно", "реалізація", "обчислюваний" тощо, вже знатиме відповідь на питання.

Найпростіша відповідь полягає в тому, що ні код C, ні код Джулії не виконуються безпосередньо машиною. Обидва повинні бути переведені, і цей процес перекладу вводить багато способів, щоб виконуваний машинний код міг бути повільнішим або швидшим, але все-таки давати однаковий кінцевий результат. І С, і Юлія роблять компіляцію, що означає серію перекладів на іншу форму. Зазвичай текстовий файл, прочитаний людиною, перекладається на деяке внутрішнє представлення, а потім виписується у вигляді послідовності інструкцій, які комп'ютер може зрозуміти безпосередньо. З деякими мовами є більше, ніж це, а Джулія - ​​одна з них - у неї є компілятор "JIT", що означає, що весь процес перекладу не повинен відбуватися відразу для всієї програми. Але кінцевим результатом для будь-якої мови є машинний код, який не потребує подальшого перекладу, код, який можна надіслати безпосередньо до процесора, щоб змусити його щось робити. Зрештою, ЦЕ "обчислення", і існує не один спосіб сказати ЦП, як отримати потрібну відповідь.

Можна було б уявити мову програмування, яка має і оператор "плюс", і "множити", і іншу мову, яка має лише "плюс". Якщо для ваших обчислень потрібне множення, одна мова буде "повільнішою", оскільки, звичайно, процесор може робити обидві безпосередньо, але якщо у вас немає ніякого способу висловити необхідність множення 5 * 5, вам залишається написати "5 + 5 + 5 + 5 + 5 ". Останні знадобиться більше часу, щоб дійти до тієї самої відповіді. Імовірно, щось таке відбувається з Джулією; можливо, мова дозволяє програмісту заявити бажану мету обчислити набір Мандельброта таким чином, що неможливо безпосередньо виразити C.

Процесор, який використовується для еталону, був вказаний як процесор Xeon E7-8850 2,00 ГГц. Тест C використовував компілятор gcc 4.8.2 для створення інструкцій для цього процесора, тоді як Julia використовує структуру компілятора LLVM. Можливо, що резервний сервер gcc (частина, яка виробляє машинний код для певної архітектури процесора) певним чином не є настільки розширеною, як резервний файл LLVM. Це може змінити продуктивність. Також відбувається багато іншого - компілятор може "оптимізувати", можливо, видаючи інструкції в іншому порядку, ніж визначено програмістом, або навіть взагалі не робити деякі речі, якщо він може проаналізувати код і визначити, що вони не необхідний для отримання правильної відповіді. І програміст, можливо, написав частину програми С таким чином, що робить це повільним, але хіба '

Все це - способи сказати: існує багато способів написання машинного коду для обчислення набору Мандельброта, і мова, якою ви користуєтесь, має великий вплив на те, як цей машинний код записується. Чим більше ви розумієте про компіляцію, набори інструкцій, кеші тощо, тим краще будете оснащені, щоб отримати бажані результати. Основним результатом результатів, які цитують Юлію, є те, що жодна мова чи інструмент не найкращий у всьому. Насправді найкращий коефіцієнт швидкості у всьому графіку був для Java!

Швидкість складеної програми залежить від двох речей:

1. Характеристики експлуатації машини, що її виконує
2. Вміст виконуваного файлу

Мова, якою написаний компілятор, не має значення для (1). Наприклад, компілятор Java може бути записаний на C або Java або Python, але у всіх випадках "машина", що виконує програму, є JVM.

Мова, якою написаний компілятор, не має значення для (2). Наприклад, немає жодної причини, чому компілятор C, написаний на Python, не може вивести точно такий же виконуваний файл, що і компілятор C, написаний на C або Java.

Спробую запропонувати більш коротку відповідь.

Суть питання полягає у визначенні "швидкості" мови .

Більшість, якщо не всі тести порівняння швидкості, не перевіряють, яка максимально можлива швидкість. Натомість вони пишуть невелику програму мовою, яку вони хочуть перевірити, щоб вирішити проблему. Під час написання програми програміст використовує те, що вони вважають найкращою практикою та умовами мови на момент тестування. Потім вони вимірюють швидкість, з якою виконувалася програма.

* Припущення періодично неправильні.

Код, написаний мовою X, компілятор якого написаний на C, може перевершити код, написаний на C, за умови, що компілятор C робить слабку оптимізацію порівняно з мовою X. Якщо ми будемо тримати оптимізацію поза дискусією, то якщо компілятор X міг би генерувати краще об'єктний код, ніж той, що генерується компілятором C, тоді також код, записаний у X, може виграти гонку.

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