Почему Python компилирует исходный код в байт-код перед интерпретацией?

Почему Python компилирует исходный код в байт-код перед интерпретацией?

Почему бы не интерпретировать напрямую из источника?


python bytecode compiler-construction interpreter
person Community    schedule 20.05.2009    source источник
comment
Для меня это похоже на домашнее задание.   -  person S.Lott    schedule 20.05.2009

Ответы (6)


arrow_upward
38
arrow_downward

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

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

person Konrad Rudolph    schedule 20.05.2009
comment
Даже старый MS BASIC на моем TRS-80 использовал очень простую схему кодирования: как только я набирал или редактировал строку, ключевые слова BASIC превращались в отдельные байты. - person David Thornley; 27.07.2009
comment
@DavidThornley: Многие компьютеры 1980-х годов использовали производную от MS-basic, которая преобразовывала ключевые слова в токены, но сохраняла числа и имена переменных в текстовой форме, поэтому приходилось вычислять их значения или искать их во время выполнения. Atari BASIC проделала большую обработку, построив таблицу переменных и заменив их имена на индексы. Он также преобразовал числовые числа в числа с плавающей запятой BCD. В виде текста сохранялись только строковые литералы и комментарии. Такие вещи могли позволить Atari BASIC превзойти другие, за исключением того, что номер каждой строки хранился как двоичный, но цели GOTO ... - person supercat; 29.01.2014
comment
... хранились как BCD с плавающей запятой, поэтому каждый GOTO требовал преобразования из BCD в двоичное. Тем не менее, интересно, что автор Atari BASIC преобразовал программу в проанализированное представление, а не просто заменил ключевые слова токенами. - person supercat; 29.01.2014
comment
Очень хорошо объяснено !! - person coderboy; 24.11.2020

arrow_upward
8
arrow_downward

Потому что вы можете скомпилировать .pyc один раз и много раз интерпретировать из него.

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

person Dave Webb    schedule 20.05.2009

arrow_upward
7
arrow_downward

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

person Brian    schedule 20.05.2009

arrow_upward
6
arrow_downward

Повторная лексика и синтаксический анализ исходного кода снова и снова, вместо того, чтобы делать это только один раз (чаще всего в первый import), очевидно, были бы глупой и бессмысленной тратой усилий.

person Alex Martelli    schedule 20.05.2009
comment
Просто запуск файла .py приводит к повторной лексике и синтаксическому анализу исходного кода снова и снова, верно? Если файл большой, это может привести к значительным накладным расходам. Я не уверен, почему к импорту уделяется особое внимание. Буду очень признателен за любую помощь в понимании. - person batbrat; 17.02.2014

arrow_upward
3
arrow_downward

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

person Paul Biggar    schedule 27.07.2009

arrow_upward
0
arrow_downward

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

Редактировать:

Хорошо, ясно, кто когда-либо голосовал за мой пост, не оставляя разумного комментария для объяснения, очень мало знает о виртуальных машинах (средах выполнения).

http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine/

person John Leidegren    schedule 26.07.2009
comment
Я не -1, но буду честен, я не понял вашу точку зрения, особенно эту ее часть: было бы более практично, чем найти и заменить текст в некоторой строке исходного кода - person Joe Holloway; 05.08.2009
comment
Посмотрите видео на канале 9 или напишите свою собственную виртуальную машину - оба, вероятно, подробно объяснят вам весь процесс. Под этой цитатой я имел в виду то, что иногда проще выполнить оптимизацию на более высоком уровне абстракции, чем на сборке. Когда вы делаете это, обычно вы работаете с AST (абстрактным синтаксическим деревом), если у вас его нет, вы все равно можете выполнять те же оптимизации, но они должны перемещать исходный код, т.е. находить и заменять, а это действительно непрактично, среды выполнения по этой причине обычно используют другое промежуточное представление (см. трехадресный код). - person John Leidegren; 06.08.2009
comment
Байт-код - это просто более эффективное, компактное и практичное представление AST. - person John Leidegren; 12.06.2010