Байт-код Vs. Интерпретированный

Question

Я помню, как однажды профессор сказал, что интерпретируемый код примерно в 10 раз медленнее, чем скомпилированный. Какая разница в скорости между интерпретируемым и байт-кодом? (при условии, что байт-код не скомпилирован JIT)

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

Answer 1

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

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

Answer 2

Вы могли видеть довольно хороший импульс. Однако есть много факторов. Нельзя просто сказать, что скомпилированный код всегда примерно в 10 раз быстрее интерпретируемого кода или что байт-код в n раз быстрее интерпретируемого кода.

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

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

Answer 3

Кроме того, многие «классические» интерпретаторы также включают в себя фазу lex / parse и исполнение.

Например, рассмотрим выполнение скрипта Python. Когда вы это сделаете, у вас будут все расходы, связанные с преобразованием текста программы во внутренние структуры данных интерпретатора, которые затем выполняются.

Теперь сравните это с выполнением скомпилированного скрипта Python, файла .pyc. На этом этап lex и parse завершен, и у вас есть только среда выполнения внутреннего интерпретатора.

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

Answer 4

Есть ли сейчас какие-то основные "интерпретаторы", которые на самом деле не компилируют свой код? (Либо для байт-кода, либо для чего-то подобного.)

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

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

Answer 5

Я никогда не замечал сценарий Vim, который был достаточно медленным, чтобы заметить. Если предположить, что скрипт в первую очередь вызывает встроенный, собственный код, операции (регулярные выражения, операции с блоками и т. Д.), Которые реализованы в ядре редактора, даже 10-кратное ускорение «клейкой логики» в сценариях будет незначительным.

Тем не менее, профилирование - единственный способ быть уверенным.

Answer 6

Это в соответствии с вашей виртуальной машиной. Некоторые из ваших более быстрых виртуальных машин (JVM) приближаются к скорости кода C. Так как быстро работает ваш интерпретированный код по сравнению с C?

Не думайте, что если вы преобразуете интерпретированный код в ByteCode, он будет работать так же быстро, как Java (почти на скоростях C), были годы повышения производительности, но вы должны увидеть значительное увеличение скорости.

Emacs был перенесен в байт-код с повышенной производительностью. Может быть стоит посмотреть на тебя.