LLVM, Parrot, JVM, PyPy + python

Question

В чем проблема при разработке некоторых языков, например, python для некоторых оптимизированных методов с некоторыми из LLVM / Parrot.

PyPy, LLVM, Parrot - основные технологии для разработки общей платформы.
Я вижу это как:

• PyPy - инфраструктура для сборки виртуальной машины со встроенной оптимизированной виртуальной машиной для Python
  Так что это довольно общее решение. Процесс идет так, как указано ниже:
  dynamic_language_code ->
  
• Интерфейс PyPy ->
• PyPy внутренний код - байт-код ->
• Оптимизация PyPy ->
• оставив код PyPy и:
  а. Бэкэнд PyPy для некоторых виртуальных машин (например, jvm)
  б. Сом Кит, чтобы сделать собственную виртуальную машину
  с. обработка / запуск внутреннего кода PyPy
  

Прав ли я об этом процессе? Для питона есть оптимизированная ВМ? В частности, по умолчанию имеется встроенная виртуальная машина для оптимизированного кода PyPy (шаг 5.c) - что для python, и любая языковая обработка может останавливаться и запускаться на нем?

• Parrot - очень похоже на PyPy, но без 5.a и 5.b? Некоторые внутренние улучшения для динамической обработки ( Parrot Magic Cookies ).

Оба Parrot и PyPy предназначены для создания платформы, которая создает общую динамическую среду исполнения языков, но PyPy хочет большего - также для создания большего количества виртуальных машин.
Где смысл PyPy? Для чего нам нужно создать больше ВМ? Не должно быть лучше сосредоточиться на одной виртуальной машине (как в попугайчике) - потому что есть общий один уровень кода - либо внутренний байт-код PyPy, либо Parrot. Я думаю, что мы не можем получить ничего лучше, чтобы перевести байт-код PyPy во вновь созданные с помощью виртуальных машин PyPy.

• LLVM - я вижу это очень похоже на PyPy, но без генератора ВМ.
  Это зрелая, хорошо спроектированная среда с такими же целями, как PyPy (но без генератора виртуальных машин), но работающая на низкоуровневой структуре и реализованная великолепная техника оптимизации / JIT

Это выглядит так: LLVM - это обычное использование, но Parrot и ** PyPy * предназначены для динамических языков. В PyPy / Parrot проще вводить некоторые сложные методы - потому что это более высокий уровень, чем LLVM - как сложный компилятор, который может лучше понимать высокоуровневый код и производить лучший ассемблерный код (который люди не могут написать в разумные сроки), затем LLVM один?

Вопросы:

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

2. Я не видел действия по разработке Python на Parrot. Это потому, что использование расширений Python C не работает на попугаях? Та же проблема в PyPy

3. Почему другие виртуальные машины не хотят переходить на LLVM / parrot. Например, рубин -> попугай, CLR / JVM -> LLVM. Не лучше ли им перейти к более сложному решению? LLVM находится в процессе высокого развития, и в него инвестируют крупные компании.

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

5. Какие проблемы возникают при связывании, например, библиотек jvm внутри llvm (если мы каким-то образом портируем java / jvm / scala на llvm)?

6. Можете ли вы исправить меня, если я где-то не так

Некоторые добавления:

• Как Parrot сравнивается с другими виртуальными машинами
• В чем преимущество Parrot VM для конечных пользователей
• В чем различия между LLVM и java / jvm

=============

ПОЯСНЕНИЯ

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

Answer 1

На этот вопрос никто не может ответить в вопросах stackoverflow, но я даю ему минимальный шанс.

Во-первых, какие проблемы решают 3 проекта?

1. pypyпозволяет реализовать переводчик на языке высокого уровня, и вы получите сгенерированный JIT бесплатно.Хорошая вещь об этом - то, что у вас нет несоответствия зависимости между языком и платформой.Вот почему pypy-clr работает быстрее, чем IronPython.Более подробная информация здесь: http://codespeak.net/pypy/dist/pypy/doc/extradoc.html -> Высокопроизводительная реализация Python для CLI / .NET с генерацией JIT-компилятора для динамического)

2. llvm - инфраструктура низкого уровня для компиляторов,Общая идея состоит в том, чтобы иметь одну «сборку высокого уровня».Все optomizations работают на этом языке.Кроме того, существует множество инфраструктур, помогающих создавать компиляторы (JIT или AOT).Реализация динамического языка на llvm возможна, но требует больше работы, чем реализация на pypy или parrot.Например, вы не можете получить GC бесплатно (есть GC, который вы можете использовать вместе с LLVM, см. http://llvm.org/devmtg/2009-10/ -> видео vmkit). Есть попытки улучшить платформу для динамических языков на основеllvm: http://www.ffconsultancy.com/ocaml/hlvm/

3. Я не так много знаю о попугаях, но, насколько я понимаю, они хотят создать одну стандартную виртуальную машину, специализирующуюся на динамических языках (perl, php, python ....).Проблема здесь та же, что и при компиляции в JVM / CLR существует несоответствие зависимостей, только намного меньшее.ВМ до сих пор не знает семантику вашего языка.Как я понимаю, попугай все еще довольно медленный для пользовательского кода.(http://confreaks.net/videos/118-elcamp2010-parrot)

Ответ на ваш вопрос:

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

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

Я не виделдеятельность по разработке Python на Parrot. Это потому, что использование расширений Python C не работает на Parrot? Та же проблема в PyPy.

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

Почему другие виртуальные машины не хотят переходить на LLVM / parrot. Например, ruby ​​-> parrot, CLR / JVM -> LLVMНе лучше ли им перейти к более сложному решению? LLVM находится в процессе высокого развития и в него инвестируют крупные компании.

Хорошо, в этом вопросе много материала.

• Как я и сказал LLVMтрудно перейти к и попугай не так быстро (поправьте меня, если я не прав).
• У Руби есть ведьма Рубиниус, которая пытается сделать много в рубине и достигает 11vm (http://llvm.org/devmtg/2009-10/ -> Ускорение Ruby с помощью LLVM).
• Существует реализация CLR / JVM в LLVM, но обе они уже имеют очень зрелые реализации, которые требуют больших инвестиций.
• LLVM не является высоким уровнем.

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

Я понятия не имею, в чем вопрос.

Какие проблемы возникают при подключении, например, библиотек jvm внутри llvm (если мы каким-либо образом портируем java / jvm / scala на llvm)?

Смотрите видео VMKit Iвыше показано, как далеко они продвинулись и в чем проблема (и как они ее решили).

Можете ли вы исправить меня, если я где-то не так

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

---

Некоторые примеры:

Clojure

Создатель не хотел всю работу по реализации своего собственного vm и всех библиотек.Так куда же пойти?Поскольку Clojure - это новый язык, вы можете построить его так, чтобы он хорошо работал на такой платформе, как JVM, ограничивая множество динамических вещей, которые мог бы иметь язык, такой как python или ruby.

Python

Язык можетне должно быть (практически) изменено, чтобы хорошо работать на JVM / CLR.Таким образом, реализация Python на этих платформах не приведет к значительному ускорению.Статический компилятор также не будет работать очень хорошо, потому что не так много статических гарантий.Написание JIT на C будет быстрым, но очень сложным для изменения (см. Психопроект).Использование llvm jit может работать, и его исследует проект Unladen Swallow (снова http://llvm.org/devmtg/2009-10/ -> Unladen Swallow: Python на LLVM).Некоторые люди хотели иметь Python в Python, поэтому они начали Pypy, и их идея выглядит очень хорошо (см. Выше).Попугай тоже мог бы сработать, но я не видел, чтобы кто-нибудь пробовал (не стесняйтесь).

---

На всем:

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

Answer 2

Что вы пытаетесь реализовать?Ваш вопрос сформулирован очень запутанно (я понимаю, что английский, вероятно, не ваш родной язык).

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

PyPyпозволяет вам написать интерпретатор в RPython и использовать его в качестве описания для генерации интерпретатора собственного кода или JIT;LLVM - это фреймворк C ++ для построения цепочки инструментов компилятора, который также может быть использован для реализации JIT.Оптимизаторы LLVM, генерация кода и поддержка платформы значительно более продвинуты, чем у PyPy, но они не так хорошо подходят для создания динамической среды исполнения языка (см. Ретроспективу Unladen Swallow для некоторых примеров того, почему).В частности, он не так эффективен для сбора / использования обратной связи во время выполнения (что абсолютно необходимо для эффективной работы динамических языков), как основанный на трассировке JIT PyPy.Кроме того, поддержка сборки мусора в LLVM все еще несколько примитивна, и ей не хватает уникальной способности PyPy автоматически генерировать JIT.

Кстати, две реализации Java построены на LLVM - J3 / VMKit и Акула .

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

Answer 3

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

JVM, CLR, PyPy, Parrot, LLVM и все остальные по-разному нацелены на разные проблемы. Это похоже на причины, по которым Chrome, Firefox, Safari и IE используют свои собственные движки Javascript.

Unladen Swallow попытался применить LLVM к CPython и потратил больше времени на устранение проблем в LLVM, чем на что-то специфичное для Python.

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

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