Llvm, Parrot, JVM, Pypy + Python

StackOverflow https://stackoverflow.com/questions/5328295

Вопрос

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

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

  • Пип - Структура для построения виртуальной машины с Build in Optimize VM для Python
    Так что это довольно общее решение. Процесс идет как указано:
    1. dynamic_language_code ->
    2. PYPY Frontend ->
    3. Внутренний код pypy - Bytecode ->
    4. Оптимизация PYP ->
    5. оставив код PYPY и:
      а PYPY Backend для какого -то виртуальной машины (например, JVM)
      беременный SOM Kit, чтобы сделать собственную виртуальную машину
      в Обработка/Запуск внутреннего кода PYPY

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

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

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

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

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

Вопросы:

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

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

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

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

  5. Каковы проблемы с связыванием, например, библиотеками JVM внутри LLVM (если мы каким -то образом перенесем Java/JVM/Scala к LLVM)?

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

Некоторые приложения:

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

Разъяснение

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

Это было полезно?

Решение

Это не вещал, что кто -либо может ответить в вопросы Stackoverflow, но я делаю это в Minmal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каковы проблемы с связыванием, например, библиотеками JVM внутри LLVM (если мы каким -то образом перенесем Java/JVM/Scala к LLVM)?

Посмотрите видео vmkit, которое я связал выше, показывающим, как далеко они достигли и в чем проблема (и как они его решили).

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

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

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

Clojure

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

Python

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

На всем:

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

Другие советы

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

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

Pypy позволяет написать интерпретатора в RPYTHON и использовать его в качестве описания для генерации нативного интерпретатора кода или JIT; LLVM - это структура C ++ для построения инструментального оборудования компилятора, который также можно использовать для реализации JIT. Оптимизаторы LLVM, генерация кодов и поддержка платформы значительно более продвинуты, чем у Pypy, но это не так хорошо для создания динамического языка (см. Unleden Wallow Retroscome Для некоторых примеров почему). В частности, он не так эффективен в сборе/использовании обратной связи во время выполнения (что абсолютно необходимо для того, чтобы динамические языки работали хорошо), как JIT на основе трассировки Pypy. Кроме того, поддержка мусора LLVM все еще несколько примитивна, и ей не хватает уникальной способности PYPY автоматически генерировать JIT.

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

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

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

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

Незаправленная ласточка попыталась применить LLVM в CPYTHON, и потратил больше времени на исправление проблем в LLVM, чем они делали, делая что -либо специфичное для питона.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top