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

Ответ 1

Собственные программы выполняются с использованием инструкций, написанных для процессора, на котором они запускаются.

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

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

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

Итак, немного неверно сказать, что язык медленный, скорее это контекст, в котором он работает, который медленный.

С# не является интерпретируемым языком, хотя в нем используется промежуточный язык (IL), перед выполнением его выполняются JIT до нативных инструкций, поэтому он имеет некоторую скорость уменьшения скорости, но не все, но я ' d, что если вы построили полноценный интерпретатор для С# или С++, он будет работать медленнее, а также.

И просто чтобы быть ясным, когда я говорю "медленный", это, конечно, относительный термин.

Ответ 2

Все ответы, кажется, пропустят настоящий важный момент здесь. Это подробная информация о том, как реализован "интерпретируемый" код.

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

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

Этот метод хорошо объяснен в документе Deutsch/Schiffman "Эффективное внедрение системы Smalltalk-80".

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Изменить, после комментариев:

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

От about.com:

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

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Это соответствующая идея в этой статье для вашей проблемы.

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

Ответ 13

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

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

Ответ 14

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

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

Ответ 15

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

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

Обратитесь к IBM doc,

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

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

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