Почему интерпретируемые языки медленные?

Википедия говорит ,

Интерпретация кода медленнее, чем выполнение скомпилированного кода, потому что интерпретатор должен анализировать каждый оператор в программе каждый раз, когда он выполняется, а затем выполнить желаемое действие, тогда как скомпилированный код просто выполняет действие в фиксированном контексте, определяемом компиляцией . Этот анализ во время выполнения известен как «интерпретирующие накладные расходы». Доступ к переменным также медленнее в интерпретаторе, потому что отображение идентификаторов на места хранения должно выполняться многократно во время выполнения, а не во время компиляции.

См. Это IBM doc ,

Интерпретируемая программа должна переводиться каждый раз, когда она выполняется. Таким образом, интерпретируемый язык обычно больше подходит для специальных запросов, чем предопределенных запросов.

В Java, хотя он рассматривается как интерпретируемый язык, он использует компиляцию JIT (Just-in-Time), которая смягчает вышеуказанную проблему, используя технику кэширования для кэширования скомпилированного байт-кода.

JIT-компилятор считывает байт-коды во многих разделах (или полностью, редко) и динамически компилирует их в машинный код, чтобы программа могла работать быстрее. Это может быть сделано для каждого файла, для каждой функции или даже для любого произвольного фрагмента кода; код может быть скомпилирован, когда он должен быть выполнен (отсюда и название «точно в срок»), а затем кэширован и использован повторно, без необходимости перекомпиляции.

Да, интерпретируемые языки работают медленно ...

Однако учтите следующее. У меня была проблема, чтобы решить. Мне потребовалось 4 минуты, чтобы решить проблему в Python, а запуск программы занял 0,15 секунды. Затем я попытался написать это на C, и у меня было время выполнения 0,12 секунды, и мне потребовался 1 час, чтобы написать это. Все это потому, что практическим способом решения рассматриваемой проблемы было использование хеш-таблиц, и хеш-таблица все равно доминировала во время выполнения.

По той же причине, что разговаривать через переводчик медленнее, чем на родном языке. Или, читая со словарем. Перевод требует времени.

Обновление: нет, я не видел, что мой ответ в какой-то степени совпадает с принятым; -)

Очень немногие современные языки сценариев "интерпретируются" в наши дни; они обычно компилируются на лету, либо в машинный код, либо в некоторый промежуточный язык байт-кода, который (более эффективно) выполняется в виртуальной машине.

Сказав это, они работают медленнее, потому что ваш процессор выполняет намного больше инструкций для каждой «строки кода», поскольку многие инструкции тратятся на понимание кода, а не на то, что предлагает семантика строки!

Интерпретируемые языки должны читать и интерпретировать ваш исходный код во время выполнения. В случае скомпилированного кода большая часть этой интерпретации выполняется заранее (во время компиляции).

Из about.com :

Интерпретируемый язык обрабатывается во время выполнения. Каждая строка читается, анализируется и выполняется. Необходимость повторной обработки строки каждый раз в цикле делает интерпретируемые языки такими медленными. Это означает, что интерпретируемый код выполняется в 5–10 раз медленнее, чем скомпилированный код. Интерпретируемые языки, такие как Basic или JavaScript, являются самыми медленными. Их преимущество не нуждается в перекомпиляции после изменений, и это удобно, когда вы учитесь программировать.

Однако в 5-10 раз медленнее не всегда верно для таких языков, как Java и C #. Они интерпретируются, но компиляторы «точно в срок» могут генерировать инструкции машинного языка для некоторых операций, что значительно ускоряет процесс (в разы, около скорости компилируемого языка).

Прочитайте это . Плюсы и минусы интерпретируемых языков.

. Эта идея относится к вашей проблеме.

Выполнение интерпретатором обычно намного менее эффективно, чем обычное выполнение программы. Это происходит потому, что каждая инструкция должна проходить интерпретацию во время выполнения или как в более новых реализациях, код должен быть скомпилирован в промежуточное представление перед каждым выполнением.

Цикл 100 раз, содержимое цикла 100 раз интерпретируется в низкоуровневый код.

Не кэшируется, не используется повторно, не оптимизируется.

Проще говоря, компилятор интерпретирует один раз в код низкого уровня

Редактировать после комментариев:

• JIT - это скомпилированный код , не интерпретируется. Это просто скомпилировано позже, не заранее
• Я имею в виду классическое определение, а не современные практические реализации

В дополнение к другим ответам есть оптимизация: когда вы компилируете программу, вам, как правило, не важно, сколько времени занимает компиляция - у компилятора есть много времени для оптимизации вашего кода. Когда вы интерпретируете код, это должно быть сделано очень быстро, поэтому некоторые из более умных оптимизаций могут быть невозможны.

Простой вопрос, без реального простого ответа. Суть в том, что все компьютеры действительно «понимают», это двоичные инструкции, в которые «быстрые» языки, такие как C, компилируются.

Кроме того, существуют виртуальные машины, которые понимают разные двоичные инструкции (например, Java и .NET), но их нужно переводить на лету в машинные инструкции с помощью Just-In-Compiler (JIT). Это почти так же быстро (даже быстрее в некоторых конкретных случаях, потому что JIT имеет больше информации, чем статический компилятор о том, как используется код.)

Затем существуют интерпретируемые языки, которые обычно также имеют свои промежуточные бинарные инструкции, но интерпретатор функционирует во многом как цикл с большим оператором switch, в котором указывается регистр для каждой инструкции и как ее выполнять. Этот уровень абстракции над основным машинным кодом является медленным. В интерпретаторе задействовано больше инструкций, длинные цепочки вызовов функций для выполнения даже простых задач, и можно утверждать, что в результате память и кэш не используются так эффективно.

Но интерпретируемые языки часто бывают достаточно быстрыми для тех целей, для которых они используются. Веб-приложения неизменно связаны IO (обычно доступом к базе данных), который на порядок медленнее, чем любой интерпретатор.

Думайте о интерпретаторе как о эмуляторе для машины, которой у вас нет

Короткий ответ: скомпилированные языки выполняются машинными инструкциями, а интерпретируемые - программой (пишутся на скомпилированном языке), который читает либо исходный код, либо байт-код, а затем, по существу, эмулирует гипотетическую машину, которая могла бы запустить программу напрямую, если бы машина существовала.

Думайте о интерпретируемой среде выполнения как о эмуляторе для машины, которой у вас на самом деле нет в данный момент.

Это очевидно усложняется компиляторами JIT (Just In Time), которые есть в Java, C # и других. Теоретически они так же хороши, как и компиляторы «AOT» («в одно время»), но на практике эти языки работают медленнее и имеют недостатки, так как необходимо, чтобы компилятор занимал много памяти и времени во время выполнения программы. Но если вы скажете что-либо из этого здесь, на SO, будьте готовы привлечь бешеных защитников JIT, которые настаивают на том, что между JIT и AOT нет теоретической разницы. Если вы спросите их, работают ли Java и C # так же быстро, как C и C ++, они начнут оправдываться и немного успокоятся. : -)

Итак, C ++ полностью правил в играх, где всегда можно использовать максимальное количество доступных вычислений.

На настольных компьютерах и в Интернете задачи, ориентированные на информацию, часто выполняются языками с большей абстракцией или, по крайней мере, меньшей компиляцией, поскольку компьютеры работают очень быстро и проблемы не требуют больших вычислительных ресурсов, поэтому мы можем потратить некоторое время на такие задачи, как время выхода на рынок, производительность программистов, надежные безопасные для памяти среды, динамическая модульность и другие мощные инструменты.

Это хороший вопрос, но, на мой взгляд, его следует сформулировать немного иначе, например: «Почему интерпретируемые языки медленнее, чем скомпилированные языки?»

Я думаю, что это интерпретированное понимание медленны сами по себе. Интерпретируемые языки не медленны , но, в зависимости от варианта использования, могут быть медленнее , чем скомпилированная версия. В большинстве случаев интерпретируемые языки на самом деле достаточно быстры !

«достаточно быстры», плюс увеличение производительности от использования языка, такого как Python, например, над C, должно быть достаточным основанием для интерпретируемый язык. Кроме того, вы всегда можете заменить определенные части вашей интерпретируемой программы быстрой реализацией C, если вам действительно нужна скорость. Но опять же, сначала измерьте и определите, действительно ли проблема в скорости, а затем оптимизируйте.

Не существует такой вещи, как интерпретируемый язык. Любой язык может быть реализован интерпретатором или компилятором. В наши дни большинство языков имеют реализации, использующие компилятор.

Тем не менее, интерпретаторы обычно работают медленнее, потому что им нужно обрабатывать язык или что-то довольно близкое к нему во время выполнения и переводить его в машинные инструкции. Компилятор выполняет этот перевод для машинных инструкций только один раз, после чего они выполняются напрямую.

Кажется, что все ответы здесь упускают очень важный момент. Подробно, как реализован «интерпретируемый» код.

Интерпретируемые языки сценариев медленнее, потому что их метод, объект и модель пространства глобальных переменных являются динамическими. На мой взгляд, это реальное определение языка сценариев, а не факт его интерпретации. Это требует много дополнительных поисков хеш-таблицы при каждом доступе к переменной или вызову метода. И это главная причина, почему все они ужасны при многопоточности и использовании GIL (Global Interpreter Lock). Этот поиск - то, где большая часть времени проведена. Это болезненный случайный поиск в памяти, который действительно больно, когда вы получаете ошибку кэша L1 / L2.

Google Javascript Core8 настолько быстр и нацелен почти на скорость C для простой оптимизации: они принимают объектную модель данных как фиксированную и создают внутренний код для доступа к ней, как структуру данных встроенной скомпилированной программы. Когда новая переменная или метод добавляются или удаляются, весь скомпилированный код отбрасывается и компилируется снова.

Техника хорошо объяснена в статье Дойча / Шиффмана «Эффективное внедрение системы Smalltalk-80».

На вопрос, почему php, python и ruby ​​не делают этого, довольно просто ответить: метод чрезвычайно сложен в реализации.

И только у Google есть деньги, чтобы заплатить за JavaScript, потому что быстрый интерпретатор JavaScript на основе браузера является их фундаментальной потребностью в их бизнес-модели на миллиард долларов.