Чи можемо ми зробити загальні твердження про ефективність інтерпретованого коду та складеного коду?

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

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

Отже, моє запитання: чи можемо ми коли-небудь сказати про продуктивність компільованих / інтерпретованих технологій? Якщо ми можемо сказати, що складене, як правило, швидше, ніж інтерпретоване, як я можу переконати рецензента в моєму пункті?

Немає.

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

А конкретно, ефективність певної програми в першу чергу залежить від кількості думки, вкладеної в її алгоритми.

Є кілька дуже швидких перекладачів, а також деякі компілятори, які генерують дуже повільний код.

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

Узагальнення та конкретні сценарії - це буквально протилежність.

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

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

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

Залежно від структури перекладача можуть бути дуже суттєві відмінності. Існують дві суперечливі школи дизайну перекладача: Один каже, що кодування повинно бути якомога меншим, щоб вони могли легше оптимізуватися, а інші кажуть, що коди повинні бути максимально великими, щоб ми зробили більше роботи в інтерпретаторі. Коли структура вашої програми відповідає філософії перекладача, накладні витрати стають незначними.

Наприклад, Perl - це інтерпретована мова, орієнтована на маніпулювання текстом. Ідіоматична програма Perl, що здійснює маніпуляцію текстом, не буде набагато повільніше, ніж програма C, а в деяких випадках може навіть перевершити програму C (можливо, оскільки Perl використовує інше представлення рядків і вбудовані різні оптимізації, пов'язані з текстом та IO). Однак, скорочення чисельності в Perl буде нестерпно повільним. Приріст ++x- це одна інструкція по збірці, але включає в себе кілька переходів та гілок для перекладача Perl. Нещодавно я переніс сценарій Perl, пов'язаний з процесором, на C ++ і отримав 7x-20-кратну швидкість, залежно від рівня оптимізації компілятора.

Говорячи про оптимізації тут важливо, оскільки відшліфований, оптимізований перекладач може розумно перевершити неаптимізуючий наївний компілятор. Оскільки створити оптимізаційний компілятор складно і вимагає великих зусиль, навряд чи ваша "технологія B" має такий рівень зрілості.

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

Вибираючи технологію, виконання мовної роботи само по собі абсолютно не має значення. Більш імовірно, що важливо, щоб техніка відповідала деяким базовим обмеженням (наш бюджет становить $ x, ми повинні бути в змозі поставити перед yyyy-mm-dd, ми повинні задовольнити різні нефункціональні вимоги), і щоб вона мала нижчі загальна вартість власності (факторинг продуктивності розробника, витрати на обладнання, витрати на бізнес-можливості, ризик виникнення помилок та несподівані обмеження в техніці, витрати на обслуговування, витрати на навчання та найм тощо). Наприклад, у галузі, де час на ринок є найважливішим фактором, технологія з найкращою продуктивністю розробника найкраще підходить. Для великої організації рентабельність та довгострокові витрати можуть бути цікавішими.

Ви абсолютно можете сказати щось про продуктивність компільованих / інтерпретованих технологій. Але спочатку потрібно визначити "продуктивність". Якщо ви будуєте обчислювально просту вбудовану систему, то "продуктивність", ймовірно, буде нахилена до сторони використання пам'яті. Тоді як обчислювально складна система, що працює на великих наборах даних, виявила б, що визначає "продуктивність" у кількості обчислень за одиницю часу, оскільки накладні витрати на пам'ять від JVM або .NET були б незначними.

Після того, як ви вирішите, що таке "продуктивність", тоді ви можете сказати щось на кшталт "у нас в будь-який момент буде 50 мільярдів об'єктів в пам'яті. Інтерпретована технологія додає до кожного об'єкта додаткові 8 байт для внутрішнього управління, що прирівнюється до накладних пам'яті на 400 ГБ порівняно з techB, який не додає ці дані "

Це технічне запитання, і ви вже отримали багато хороших технічних відповідей, але я хотів би зазначити дещо інший аспект вашої ситуації: той факт, що ви не можете просто базувати рішення на зразок "технології А чи технології Б". з технічних та / або причин ефективності.

Технічні аспекти такого подібного є лише невеликою частиною рішення між А та В. Існують десятки інших факторів, про які слід пам’ятати:

• чи пов'язані вони з будь-якими витратами на ліцензування? Наприклад: вам доведеться заплатити (значну суму) за використання кластера машин SQL Server порівняно з використанням кластера машин PostgreSQL.
• чи є у мене співробітники, які знайомі з цією технологією (стеком) та її екосистемою? Якщо так, чи доступні вони? Якщо ні, то я можу найняти якусь? Скільки це буде коштувати мені? Або я треную існуючі? Скільки це буде коштувати мені?
• що хоче клієнт? Це може бути проблемою багато часу.
• чи технологія, яку я рекомендую, готова до використання у виробництві? Або це лише поточний ажіотаж, який, можливо, згасне? (наприклад, подумайте про Node.js, коли він вперше вийшов)
• чи відповідає технологія, яку я рекомендую, існуючій архітектурі чи архітектурі, яку я мав на увазі? Або мені доведеться витратити багато грошей, змушуючи їх працювати безперешкодно?
• та багато інших аспектів, які залежать від вашої конкретної ситуації.

Як бачите, при прийнятті такого рішення слід врахувати ТОН речі.

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

Часткове оцінювання - це концептуальна основа, що стосується співвідношення перекладачів та упорядників.

Чи можемо ми зробити загальні твердження про ефективність інтерпретованого коду та складеного коду?

Мови програмування - це специфікації (написані в деякому звіті, наприклад, R5RS або n1570 ). Вони не є програмним забезпеченням, тому про продуктивність навіть не має сенсу говорити . Але деякі мови програмування можуть мати кілька реалізацій, включаючи інтерпретаторів та компіляторів .

Навіть у традиційно складених мовах (тобто мовах, реалізація яких часто є компіляторами), як C, деякі частини часто інтерпретуються. Наприклад, рядок керування форматом printf (визначений у стандарті C) часто "інтерпретується" ( бібліотекою стандартних стандартів C , яка має printf функцію за допомогою методів змінних аргументів), але деякі компілятори (включаючи GCC ) здатні - в обмежених конкретних випадки - оптимізувати його та "компілювати" його у виклики нижчого рівня.

А деякі реалізації, навіть у межах "інтерпретаторів", використовують методи компіляції JIT (тому генеруйте машинний код під час виконання ). Хороший приклад - луаджіт . Інші реалізації (наприклад, Python, Ocaml, Java, Parrot, Lua) переводять вихідний код у байт-код, який потім інтерпретується.

SBCL - це звичайний "компілятор" Lisp, який динамічно переводить кожну взаємодію REPL (і дзвінки в evalінше ...) в машинний код. Тож ви відчуваєте, що це перекладач. Більшість реалізацій JavaScript у браузерах (наприклад, v8 ) використовують методи компіляції JIT.

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

Реалізація може бути швидкою або повільною незалежно від використання більшості подібних методів "компілятор" або "інтерпретатор".

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

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

Дивіться також це пов'язане питання про Python, і це

Для такого коду A = A + B, який може скласти одну або дві інструкції на машині, кожна з яких виконує певну кількість циклів. Жоден перекладач не може зробити те ж саме в такій кількості циклів з простої причини.

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

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

З іншого боку...

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

Пам'ятайте, що інтерпретовані мови мають власне значення, наприклад, їх складати не потрібно. ("Компіляція" поверхневого синтаксису до байтових кодів займає тривіальний час. Наприклад, візьміть R або MATLAB.)

Також є гнучкість, необхідна для інтелектуальних рівнів програмування. У « Товаристві розуму Мінського» , розділ 6.4 B -Мережі, є програми A, які мають справу зі світом, і є B-програми, які займаються програмами A, і можуть бути подальші рівні. Програми, які записують та керують іншими програмами, можна простіше робити в інтерпретаційних системах.

У Lisp ви можете написати, (+ A B)щоб додати A і B, але як тільки це буде написано, у вас є лише вибір, запустити його чи ні. Ви також можете написати, (eval (list '+ 'A 'B))що будує програму, а потім виконати її. Це може побудувати щось інше.

Тема програми - інша програма . Це простіше писати інтерпретованою мовою (хоча, як зазначає Йорг, новіші версії Lisp, хоча вони є eval, складаються на ходу, тому вони не мають покарання швидкості інтерпретації).

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

Частина причини полягає в тому, що для інтерпретованих мов необхідно мати цикл інтерпретації - цикл, який читає інструкцію, вибирає відповідні дії для її виконання та виконання. У кращому випадку, як інтерпретація байт-коду Python або Java (як це робив старий JVM), він має накладні витрати з декількох вказівок і грає хаос із передбачувачем гілки - без останнього ви можете очікувати величезних штрафних санкцій через неправильні прогнози. Навіть дуже німий JIT повинен це значно прискорити.

Це говорить, що інтерпретована мова може обдурити. Наприклад, Matlab оптимізував підпрограми для множення матриці, і за допомогою декількох змін ви можете отримати код, що працює на GPU (відмова від відповідальності: я працюю на nVidia - будь-яка думка, висловлена ​​тут, моя і не представляє погляд мого роботодавця). Таким чином ви можете писати короткий та потужний код вищого рівня, не турбуючись про деталі - хтось подбав про це і вклав час та ресурси в оптимізацію його мовою низького рівня. У цьому немає нічого спадкового, і це не заважає, наприклад, Matlab до JIT-коду, але часто немає причин, оскільки накладні витрати на виклик розпорядження високого рівня мінімальні порівняно з часом, проведеним у низькорівневих.

TL; DR - складені програми мають величезні переваги у порівнянні з інтерпретованими (для порівняння яблук до яблук див. Швидкість PyPy ). Однак швидкість виконуваного файлу є лише частиною проблеми, і це може не сприяти загальній швидкості (якщо час в основному проводиться в бібліотеках). Також питання має значення.

Ваше припущення є обґрунтованим, хоча це припущення.

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

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

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

Але час від часу ви дійсно потрапляєте. Це сталося зі мною. Ви робите гарне припущення, і тоді виявляєте, що не змогли взяти до уваги дурість світу.

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

TL; DR: ви маєте рацію, але перевіряйте реальний світ на всякий випадок.

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

Тому що, якщо ви / ваша команда знаєте A, а не B, і тому ви пишете спосіб, що краще в коді A, ніж B, ви можете мати набагато кращі показники в A, ніж B. Якщо у вас є люди, які мають досвід однієї мови, і мова / бібліотеки можуть робити робота, яка вам потрібна, дотримуйтесь її.

Ось посилання про регулярний вираз на різних мовах; ви побачите, що регулярний вимір реалізований на якійсь мові, навіть якщо його складено чи ні: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

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

Я не думаю, що розумно розраховувати, що ви отримаєте підвищення продуктивності, якщо візьмете кілька відмінних інтерпретованих мовних кодерів і надасте їм певну технологію, з якою вони не знайомі - можливо, теоретично останні можуть МОЖАТИ привести до кращої роботи, але насправді, без необхідних навичок та досвіду ви не будете використовувати всі можливості оптимізації.

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

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

По-перше, вони можуть не захотіти вірити скромному інженеру, тому я знайшов кілька порівняльних тестів на еталон і процитував їх. Їх багато, від таких людей, як Microsoft або відомі університети. І вони скажуть такі речі, як: Метод A в 3 та 10 разів швидший, ніж метод B, залежно від змінних X та Y.

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

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

Я заперечую, що будь-яка динамічна мова має перевагу перед статично складеними: "Оптимізація виконання"

Це одна з причин, чому Java може бути швидшою, ніж C ++

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

ПРИМІТКА. Ну, Java - це інтерпретована мова, а не динамічна. Але це прекрасний приклад того, що ви можете пришвидшити інформацію про час виконання

... Я також заявляю, що оскільки програма може бути написана різними способами, все ж можлива, що програма, написана на техніці A, може перевершити програму, написану на техніці B.

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

Це мій підхід:

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

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

Слід додати, що будь-яке таке загальне твердження зовсім не допомагає при порівнянні двох конкретних технологій A і B. Там вибір A і B має значення набагато, набагато більше, ніж якщо вони інтерпретуються або складаються.