LLVM, Parrot, JVM, PyPy + python

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

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

  • PyPy - фреймворк для сборки виртуальной машины со встроенной оптимизированной виртуальной машиной для Python
    Так что это довольно общее решение. Процесс идет так, как указано ниже:
    1. dynamic_language_code ->
    2. PyPy интерфейс ->
    3. Внутренний код PyPy - байт-код ->
    4. Оптимизация PyPy ->
    5. оставив код 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. Вы можете исправить меня, если я где-то не так

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

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

ПОЯСНЕНИЯ

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

Источник

3 ответа

Решение

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

Во-первых, какие проблемы решают 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 video). Есть попытки собрать Платформа лучше для динамических языков на основе llvm: http://www.ffconsultancy.com/ocaml/hlvm/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clojure

Создатель не хотел всю работу по внедрению своего собственного виртуального компьютера и всех библиотек. Так куда же пойти? Поскольку 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 человек, вы получите три разных ответа.

Источник

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

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

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

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

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

Источник

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

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

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

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

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

Источник
Другие вопросы по тегам