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

12

Я читал о мета-циклических интерпретаторах в Интернете (включая SICP) и изучил код некоторых реализаций (таких как PyPy и Narcissus).

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

Одна вещь, которую я не до конца понял, - как эти интерпретаторы / компиляторы могут достичь такой хорошей производительности, или, другими словами, почему PyPy быстрее, чем CPython? Это из-за рефлексии?

Кроме того, мои исследования в Smalltalk заставили меня поверить, что есть взаимосвязь между JIT, виртуальными машинами и рефлексией. Виртуальные машины, такие как JVM и CLR, позволяют проводить интроспекцию типов, и я полагаю, что они прекрасно используют ее при компиляции Just-in-Time (и AOT, я полагаю?). Но насколько я знаю, виртуальные машины похожи на процессоры в том смысле, что у них есть базовый набор команд. Являются ли виртуальные машины эффективными, потому что они включают тип и справочную информацию, которая позволила бы не зависящую от языка рефлексию?

Я спрашиваю об этом, потому что многие интерпретированные и скомпилированные языки в настоящее время используют байт-код в качестве цели (LLVM, Parrot, YARV, CPython), а традиционные виртуальные машины, такие как JVM и CLR, получили невероятное повышение производительности. Мне сказали, что речь идет о JIT, но, насколько я знаю, JIT не является чем-то новым, поскольку Smalltalk и собственная личность Sun занимались этим до Java. Я не помню, чтобы в прошлом виртуальные машины работали особенно хорошо, за пределами JVM и .NET не было много неакадемических, и их производительность была определенно не такой хорошей, как сейчас (хотелось бы получить эту заявку, но я говорю из личного опыта).

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

virtual-machine reflection jit smalltalk Гоми
источник
3
Деньги. Деньги, которые раньше выливались в С ++ и Фортран, теперь выливаются в HotSpot, CLR, Mono, V8, Nitro, SpiderMonkey и т. Д.
Йорг Миттаг,
Я могу только догадываться, но я думаю, что это просто улучшение со временем, как описано здесь joelonsoftware.com/articles/fog0000000017.html
Док Браун
1
RE, как PyPy может быть быстрее, чем CPython: он написан не на Python, а на совершенно другом языке, который может быть эффективно оптимизирован для AOT .
1
@Gomi Дело не в том, насколько язык реализации похож на язык реализации. Есть интерпретаторы JavaScript, Lisp, Prolog, SmallTalk и Ruby, написанные на RPython, и они получают точно такие же вкусности, которые предлагает PyPy. Единственная причина, по которой RPython основан на Python, заключается в том, что он был создан группой энтузиастов Python. Функции RPython, которые делают PyPy быстрым, не имеют ничего общего с Python: автоматическая генерация JIT-компилятора, сборщики мусора и т. Д. - и да, большинство из них в принципе может быть сделано с использованием других языков. Вы должны создать совершенно новый компилятор.
4
-1 потому что у вас, кажется, есть как минимум 3 разных вопроса: (a) Почему мета-циклические реализации так хороши? (b) Эффективны ли виртуальные машины из-за информации о типах, и полезен ли интроспекция для производительности? (c) Почему популярность виртуальных машин выросла в конце 2000-х годов, и почему у них вдруг появилась хорошая производительность? Я думаю, что лучше задать эти вопросы отдельно.
Дуб

Ответы:

1

2 из 3: Нет никакой связи между «мета-циклическим» и «высокопроизводительным» языковым временем выполнения. Метациклические среды выполнения, обеспечивающие высокую производительность, делают это путем JIT-компиляции в собственный код и запуска собственного кода. Нет никаких причин, по которым ваша приветливая среда исполнения Python должна быть написана на Python или Lisp на Lisp и т. Д. Но если вы считаете, что ваш язык более мощный, выразительный и т. Д., Чем другие, почему бы не использовать его для написания свое собственное время выполнения? Или, если вы не думаете, что ваш язык как-то «лучше», чем другие, почему вы вообще не можете его реализовать?

Алекс Д
источник