LLVM, Parrot, JVM, PyPy + python

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

PyPy, LLVM, Parrot - это основные технологии совместной разработки платформ.

Я вижу это как:

  • PyPy - инфраструктура для создания виртуальной машины с построением оптимизированной виртуальной машины для python
    Так что это довольно общее решение. Процесс идет, как показано ниже:
    • dynamic_language_code →
    • Интерфейс PyPy →
    • Внутренний код PyPy - байт-код →
    • Оптимизация PyPy →
    • оставляя код PyPy и:
      а. PyPy для некоторых VM (например, jvm)
      б. som Kit, чтобы создать собственную виртуальную машину

      с. обработка/запуск внутреннего кода PyPy

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

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

Оба Parrot и PyPy предназначены для создания платформы, которая создает общую динамическую среду исполнения, но PyPy хочет больше - также создавать больше виртуальных машин.

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

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

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

Вопросы:

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

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

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

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

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

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

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

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

РАЗЪЯСНЕНИЯ

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

ОТВЕТЫ

Ответ 1

Это не то, что кто-то может ответить на вопросы в stackoverflow, но я даю ему minmal shot.

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

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

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

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

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

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

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

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

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

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

Хорошо, в этом вопросе много чего.

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

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

Я не знаю, в чем вопрос.

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

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

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

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

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

Clojure

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

Python

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

Во всем:

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

Ответ 2

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

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

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

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

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

Ответ 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 VM.

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