Існує багато причин, які можуть враховувати вибір мови X на мові Y. Читання програми, простота програмування, переносимість на багатьох платформах, наявність хороших середовищ програмування можуть бути такими причинами. Однак я розглядаю лише швидкість виконання, як вимагається у питанні. Здається, питання не враховує, наприклад, швидкість розвитку.
Дві мови можуть компілювати в один і той же байт-код, але це не означає, що буде створений той самий код,
Насправді байт-код - це лише код для конкретної віртуальної машини. Він має інженерні переваги, але не вносить принципових відмінностей при складанні безпосередньо для конкретного програмного забезпечення. Тож ви можете також розглянути можливість порівняння двох мов, складених для прямого виконання на одній машині.
Це говорило, що питання відносної швидкості мов є старим, починаючи з перших укладачів.
Протягом багатьох років, у ті часи, професіонали вважали, що рукописний код був швидшим, ніж компільований код. Іншими словами, машинна мова вважалася швидшою, ніж мови високого рівня, такі як Cobol або Fortran. І було, і швидше, і зазвичай менше. Мова високого рівня все ще розвивалася, тому що їх було набагато легше використовувати для багатьох людей, які не були комп'ютерними науковцями. Витрати на використання мов високого рівня навіть мали назву: коефіцієнт розширення, який міг би стосуватися розміру згенерованого коду (дуже важлива проблема в ті часи) або кількості дійсно виконаних інструкцій. Концепція була в основному експериментальною, але спочатку це співвідношення було більшим, ніж 1, оскільки компілятори виконували досить просту роботу на сьогоднішній день.
Таким чином машинна мова була швидшою, ніж скажімо, Fortran.
Звичайно, це змінювалося з роками, коли компілятори ставали все більш досконалими, до того, що програмування мовою складання зараз дуже рідкісне. Для більшості програм програми мовної збірки погано конкурують з кодом, створеним оптимізацією компіляторів.
Це свідчить про те, що одним з головних питань є якість компіляторів, доступних для розглянутої мови, їх здатність аналізувати вихідний код та оптимізувати його відповідно.
Ця здатність може певним чином залежати від особливостей мови підкреслювати структурно-математичні властивості джерела, щоб полегшити роботу компілятору. Наприклад, мова може дозволити включення висловлювань про алгебраїчні властивості визначених користувачем функцій, щоб дозволити компілятору використовувати ці властивості для цілей оптимізації.
Процес компіляції може бути простішим, отже, створення кращого коду, коли парадигма програмування мови наближається до особливостей машин, які інтегруватимуть код, будь то реальна чи віртуальна машина.
Інший момент - чи парадигми, реалізовані мовою, закриті для типу проблем, що запрограмовані. Очікується, що мова програмування, спеціалізована для конкретних парадигм програмування, буде дуже ефективно збирати функції, пов'язані з цією парадигмою. Отже, вибір мови програмування може залежати, від ясності та швидкості, від вибору мови програмування, адаптованої до типу заданої програми.
Популярність C для системного програмування, ймовірно, пов'язана з тим, що C близький до машинної архітектури, і що системне програмування також безпосередньо пов'язане з цією архітектурою.
Будь-яка інша проблема буде легше запрограмована, швидше виконання за допомогою логічного програмування та мов вирішення обмежень .
Складні реактивні системи можуть бути дуже ефективно запрограмовані спеціалізованими мовами синхронного програмування, як Esterel, яка втілює дуже спеціалізовані знання про такі системи та генерує дуже швидкий код.
Або, якщо взяти крайній приклад, деякі мови є високоспеціалізованими, наприклад, мовами опису синтаксису, які використовуються для програмування парсерів. Генератор синтаксичний аналізатор не що інше, як компілятор для таких мов. Звичайно, це не Тюрінг повно, але ці компілятори надзвичайно гарні за своєю спеціальністю: створення ефективних програм розбору. Область знань обмежена, методи оптимізації можуть бути дуже спеціалізованими та налаштованими дуже тонко. Ці генератори аналізаторів зазвичай набагато кращі, ніж те, що можна отримати, написавши код іншою мовою. Існує багато вузькоспеціалізованих мов з компіляторами, які створюють відмінний та швидкий код для обмеженого класу проблем.
Отже, при написанні великої системи може бути доцільним не покладатися на одну мову, а вибрати кращу мову для різних компонентів системи. Це, звичайно, викликає проблеми сумісності.
Іншим моментом, який часто має значення, є просто наявність ефективних бібліотек для запрограмованих тем.
Нарешті, швидкість не є єдиним критерієм і може суперечити іншим критеріям, таким як безпека коду (наприклад, щодо поганого введення чи стійкості до системних помилок), використання пам’яті, простота програмування (хоча сумісність парадигми насправді може допомогти цьому ), розмір коду об'єкта, технічне обслуговування програми тощо.
Швидкість не завжди є найважливішим параметром. Крім того, це може мати різні форми, як складність, яка може бути середньої складності або гіршої складності. Також у великій системі, як у меншій програмі, є частини, де швидкість є критичною, та інші, де це мало важливо. І це не завжди легко визначити заздалегідь.