Интерпретированные языки: более высокий уровень быстрее?

Ответ 1

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

Ответ 2

В конце концов, разбор строки текста на вашем языке займет примерно столько же времени, независимо от того, говорим ли мы о сборке по сравнению со следующим языком Big Thing Language (TNBL). Это не верно в буквальном смысле, но это верно в способе Turing-esque, Big-O-Notation.

Если для определения того, что это означает, требуется (опять же, "грубо" ) такое же количество времени:

mov $3, $4, $5

как это:

print "foo"

... тогда представим себе письмо Hello World на наших двух языках. У сборщика-переводчика будет более сложная программа для синтаксического анализа. Скажем, n строк длинный, что в n раз больше строк, чем TNBL Hello Wolrld. Таким образом, ваши основные накладные расходы в n раз.

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

Я уверен, что вы увидите некоторых программистов на Java, которые бы отказались от этого тезиса, но я хотел бы указать, что Java имеет несколько преимуществ для этого: промежуточный байт-код, который пытается получить код как можно ближе к как возможно, до его запуска, а тысячи человеко-лет погрузились в разработку компиляции и оптимизации времени выполнения этого языка. Они едва ли находятся на континууме с языком хобби. =]

Ответ 3

Реальность, конечно, немного сложнее. По мере того, как языки, интерпретаторы и компиляторы становятся более изощренными, возникают новые возможности для оптимизации работы машины. Кроме того, производительность любой данной программы во многом зависит от качества кода, написанного программистом.

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

Таким образом, изображение производительности не так просто, как может показаться.

Ответ 4

Ну, очевидно, это будет зависеть от того, как вы реализовали разные языки.

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

Ответ 5

Я бы сказал, что ты почти прав. Если вы оцениваете скорость интерпретации, уровень языка по оси X и скорость выполнения по оси Y, вы получите кривую "ванна" - интерпретация языка с очень низким уровнем может быть довольно быстрой и интерпретировать чрезвычайно высокий уровень уровень языка может быть довольно быстрым. Между ними интерпретация существенно медленнее.

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

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

Первоначальное намерение состояло в том, что большинство JVM, "управляемой" среды .NET, интерпретаторы байт-кода Smalltalk и т.д. соответствовали бы последнему случаю. Поскольку большинство тех, кто пытался их развить, быстро нашли, трудно удержать интерпретацию накладных расходов достаточно низко, чтобы выполнить это. Каждый, кого я знаю о том, что вписывается в этот класс, имеет внутреннюю петлю, написанную на ассемблере вручную, и обычно хорошим программистом на языке ассемблера. Я почти зашел так далеко, чтобы сказать, что если вы попытаетесь использовать язык более высокого уровня (даже C), он будет медленнее и, вероятно, значительно таким образом (когда вы добавляете накладные расходы для каждой инструкции ввода, даже один дополнительный инструкция во внутреннем цикле почти наверняка приведет к измеримому ограничению скорости).

Ответ 6

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

Ответ 7

Резюме: сравнительный анализ сложный. Вы не можете обобщать из анекдотов.

Это не правило, подтверждаемое доказательствами.

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

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

Например, если один интерпретируемый язык имеет оператор quicksort, вы можете подумать: "Ага! Быстрее!" чем язык, на котором вы должны выполнить сортировку вручную. Однако quicksort имеет худшую производительность O (n ^ 2). Если я передам вашу операцию более высокого уровня примером набора данных наихудшего случая, другой ручной вариант merge sort будет превзойти его.

Ответ 8

Как вы делаете честное сравнение?

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

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

Ответ 9

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

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

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

Я скажу, что проще реализовать более быстрый язык высокого уровня. (в моем ограниченном опыте)