LLVM, Pappagallo, JVM, PyPy + pitone

https://stackoverflow.com/questions/5328295

26-10-2019
|

Domanda

Qual è il problema nello sviluppo di alcune lingue, ad esempio Python per alcune tecniche ottimizzate con alcuni dei LLVM / Parrot.

PyPy, LLVM, Parrot sono le principali tecnologie per lo sviluppo comune della piattaforma.
Vedo questo come:

PyPy - quadro per costruire VM con configurazione in ottimizzato VM per Python
Quindi è una soluzione del tutto generale. Il processo va come elencato in basso:
1. lasciando codice PyPy e:
  un. PyPy backend per un po 'di VM (come JVM)
  b. som Kit di fare propria VM
  c. elaborazione / corsa codice interno PyPy

ho ragione su questo processo? Per pitone non è ottimizzato VM? In particolare per default non v'è accumulo in VM per il codice ottimizzato PyPy (passo 5.c) - che è per python ed ogni elaborazione del linguaggio può fermarsi qui ed essere in esecuzione da esso

Parrot - molto simile PyPy, ma senza 5.a e 5.b? Alcuni miglioramenti interni per l'elaborazione dinamica ( Parrot magia cookie ).

Sia Parrot e PyPy sono progettati per creare una piattaforma che creano una dinamica comune lingue runtime, ma PyPy vuole di più - anche per creare più VM.
Dove sono i sens di PyPy? Per quello che abbiamo bisogno di creare più VM? Non dovrebbe essere meglio concentrarsi su una VM (come in pappagallo) - perché non v'è comune livello di codice uno - o bytecode interna PyPy o quelli Parrot. Credo che non possiamo ottenere niente di meglio da tradurre in PyPy bytecode per appena creato con PyPy macchine virtuali.

LLVM -. Vedo questo molto simile a PyPy ma senza generatore VM
E 'maturo, ambiente ben progettato con obiettivi simili come PyPy (ma senza generatore VM) ma lavorando sulla struttura di basso livello e di grande ottimizzazione / tecniche JIT implemeted

E 'vedere questo come: LLVM è l'uso generale, ma Parrot e ** * PyPy progettato per linguaggi dinamici. In PyPy / Parrot è più facile introdurre alcune tecniche complicate - perché è più alto livello allora LLVM - come compilatore sofisticato che può meglio capire il codice di alto livello e produrre meglio codice assembler (che gli esseri umani non possono scrivere in tempi ragionevoli), poi la LLVM uno?

Domande:

ho ragione? C'è qualche ragione per cui il porting di un linguaggio dinamico sarebbe meglio LLVM poi per esempio Parrot?
non ho vedere l'attività sul pitone di sviluppo su Parrot. È perché utilizzando le estensioni python C non funziona su pappagallo? Lo stesso problema è nella PyPy
Perché le altre macchine virtuali non vogliono passare a LLVM / pappagallo. Ad esempio ruby ??-> pappagallo, CLR / JVM -> LLVM. Non sarebbe meglio per loro di muoversi a soluzione più sofisticata? LLVM è nel processo di sviluppo di altezza e ha grandi aziende che investono in.
So che il problema potrebbe essere nel ricompilazione sono risorse, se non v'è necessità di cambiare bytecode - ma non è obbligatoria - come si può cercare di porto vecchio bytecode di nuovo, e nuovi compilatori produrre nuove bytecode ( mai meno java ancora bisogno di proprio bytecode interpretato -? in modo che il front-end in grado di controllare e tradurre al nuovo bytecode)
Quali sono i problemi con il collegamento per le librerie esempio JVM all'interno LLVM (se si porta in qualche modo java / jvm / Scala a LLVM)?
Si può correggetemi se sto da qualche parte sbagliata

Alcuni addings:

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

Chiarimento

Voglio figura come tutto questo software consiste -. E qual è il problema di porting uno ad altro

Soluzione

Non roba chiunque può possibile risposta a una serie di domande StackOverflow ma io dare un colpo minmal.

Per prima cosa problemi non i 3 progetti risolvere?

PyPy consente di implementare un interprete in un linguaggio di alto livello e si ottiene un JIT generato gratuitamente. La cosa buona di questo è che non si dispone di una mancata corrispondenza dipendenza tra la langauge e la piattaforma. Questo è il motivo per cui PyPy-CLR è più veloce allora IronPython. Maggiori informazioni qui: http://codespeak.net/pypy/dist/pypy/doc implementazione> ad alte prestazioni di Python per CLI / NET con la generazione compilatore JIT per dinamica)

- /extradoc.html

LLVM è un'infrastruttura di basso livello per i compilatori. L'idea generale è quella di avere un "alto livello di assieme". Tutti i optomizations lavorare su quella lingua. Poi ci sono tonnellate di infrastrutture intorno per aiutarvi a costruire compilatori JIT (o AOT). L'implementazione di un linguaggio dinamico su LLVM è possibile, ma ha bisogno di più lavoro, allora la sua attuazione sul PyPy o pappagallo. È, ad esempio, non è possibile ottenere un GC per libero (ci sono GC è possibile utilizzare insieme a LLVM vedere http://llvm.org/devmtg/2009-10/ -> il video vmkit) ci sono tentativi di costruire una migliore piattaforma per i linguaggi dinamici sulla base di LLVM: http://www.ffconsultancy.com/ocaml/hlvm/
Non so che molto di pappagallo, ma mi pare di capire che vuole costruire uno standard di VM specializzato per linguaggi dinamici (Perl, PHP, Python ....). Il problema qui è lo stesso che con la compilazione di JVM / CLR c'è un missmatch dipendenza, solo un molto più piccolo. La VM ancora non conosce la semantica del vostro langauge. Come ho pappagallo Unterstand è ancora piuttosto lento per codice utente. ( http://confreaks.net/videos/118-elcamp2010-parrot )

La risposta alla tua domanda:

ho ragione? C'è qualche ragione per cui il porting di un linguaggio dinamico sarebbe meglio LLVM poi per esempio Parrot?

Questo è una questione di sforzo. Costruire everthing la vostra auto e specializzato per vi troverete infine a essere più veloce, ma è uno sforzo molto di più.

Non ho vedere l'attività sul pitone di sviluppo su Parrot. È perché utilizzando le estensioni python C non funziona su pappagallo? Lo stesso problema è in PyPy.

Targeting pappagallo avrebbe (a questo punto) non è probabilmente un vantaggio rispetto PyPy. Perché nessun altro lo fa non lo so.

Perché le altre macchine virtuali non vogliono passare a LLVM / pappagallo. Ad esempio ruby ??-> pappagallo, CLR / JVM -> LLVM. Non sarebbe meglio per loro di muoversi a soluzione più sofisticata? LLVM è in forte processo di sviluppo e ha grandi imprese che investono in.

Ok c'è un sacco di roba in quella domanda.

Come ho detto LLVM è difficile muoversi da e pappagallo non è così veloce (mi corregga se im sbagliato).
Ruby ha Rubinius tentativi streghe di fare un sacco di rosso rubino e SIC a LLVM ( http: // LLVM .org / devmtg / 2009-10 / -> Accelerare rubino con LLVM).
C'è un'implementazione di CLR / JVM su LLVM ma entrambi già essere molto maturo implemantations che hanno grandi investimenti.
LLVM non è di alto livello.

So che il problema potrebbe essere nel ricompilazione sono risorse, se non v'è necessità di cambiare bytecode - ma non è obbligatoria - come si può cercare di porto vecchio bytecode di nuovo, e nuovi compilatori produrre nuove bytecode (mai meno java ancora bisogno di proprio bytecode interpretato -? in modo che il front-end in grado di controllare e tradurre al nuovo bytecode)

Non ho idea di quello che la domanda è.

Quali sono i problemi con il collegamento per le librerie esempio JVM all'interno LLVM (se si porta in qualche modo java / jvm / Scala a LLVM)?

Guarda il video di VMKit ho linkato sopra che mostrano fino a che punto sono arrivati ??e qual è il problema (e il modo in cui risolto).

Si può correggetemi se sto da qualche parte sbagliata

Un sacco di roba che hai scritto è sbagliato o che semplicemente non anderstand cosa vuoi dire, ma la roba ho collegato dovrebbe fare un sacco di cose più chiara.

Alcuni esempi:

Clojure

Il creater non voleva che tutto il lavoro di attuare la propria vm e tutte le librerie. Allora, dove andare? Dal momento che Clojure è un nuovo langauge si può costruire in un modo che funziona bene su una piattaforma come la JVM limitando un sacco di roba dinamica un linguaggio come Python o Ruby avrebbe avuto.

Python

Il linguaggio non può (praticamente) essere modificato per funzionare bene su JVM / CLR. Così attuazione pitone su quelle suole portare enormi incrementi nella velocità. compilatore statico non funziona molto bene o perché non ci sono molte garanzie statiche. Scrivi JIT in C sarà veloce ma molto difficile da cambiare (si veda il progetto psyco). Utilizzando JIT LLVM potrebbe funzionare ed è esplorato dal progetto a vuoto Swallow (nuovo http://llvm.org/ devmtg / 2009-10 / -> vuoto Rondine: Python su LLVM). Alcune persone volevano avere python in pitone così hanno iniziato PyPy e le loro cuciture idea di lavorare molto bene (vedi sopra). Parrot potrebbe funzionare pure, ma non ho visto qualcuno ha prova (sentitevi liberi).

In tutto:

Credo che sei confuso e posso capire che. Prendete il vostro tempo e leggere, ascoltare, guardare tutto ciò che si può ottenere. Non te lo stress. Ci sono un sacco di parti a questo e alla fine si vedere come quello che si adatta insieme e ciò che ha senso e anche quando si sa molto c'è ancora un sacco di discutere si può fare. La domanda è: dove per implementare una nuova lingua o come accelerare una lingua vecchia avere molte risposte e se chiedete 3 persone è probabile che per ottenere tre risposte diverse.

Altri suggerimenti

Che cosa stai cercando di implementare? La sua domanda è molto confusamente formulata (mi rendo conto che l'inglese non è probabile che la vostra prima lingua).

LLVM e PyPy sono entrambi maturi, progetti utili, ma in realtà non si sovrappongono molto a questo punto. (A un certo punto, PyPy potrebbe generare bytecode LLVM-che è stato staticamente compilato per un interprete-al contrario di codice C, ma non ha fornito molto di un miglioramento delle prestazioni e non è più supportato.)

PyPy consente di scrivere un interprete in RPython e l'uso che, come una descrizione per generare un interprete di codice nativo o JIT; LLVM è un framework C ++ per costruire un toolchain compilatore che può anche essere utilizzato per implementare un JIT. ottimizzatori di LLVM, generazione del codice e il supporto della piattaforma sono molto più avanzate di quelle di PyPy, ma non è così adatto alla costruzione di un runtime linguaggio dinamico (vedere la vuoto Rondine retrospettiva per alcuni esempi del perché). In particolare, non è così efficace a raccogliere / con retroazione di runtime (che è assolutamente essenziale per fare linguaggi dinamici eseguire bene) come JIT traccia a base di PyPy. Inoltre, il supporto garbage collection di LLVM è ancora un po 'primitivo, e manca la capacità unica di PyPy per generare automaticamente un JIT.

Per inciso due implementazioni Java sono costruite su LLVM- J3 / VMKit e Shark .

Si potrebbe prendere in considerazione guardando il discorso PyPy presso la Stanford la settimana scorsa; fornisce una panoramica abbastanza decente di come funziona PyPy. di Carl Friedrich Bolz presentazione fornisce anche una panoramica buona dello stato di attuazione VM.

Il motivo principale? Perché il design VM è non di una tecnologia consolidata, e con una varietà di macchine virtuali con gli obiettivi e gli obiettivi diversi permette una varietà di mechnisms per essere processato in parallelo piuttosto che tutti dover essere giudicato in serie.

La JVM, CLR, PyPy, Pappagallo, LLVM e il resto tutti i target di diversi tipi di problemi in modi diversi. E 'simile ai motivi per cui Chrome, Firefox, Safari e IE tutto l'uso i propri motori Javascript.

a vuoto Rondine tentato di applicare LLVM per CPython, e ha trascorso più del loro tempo a risolvere i problemi in LLVM quello che ha fatto a fare qualcosa di Python specifica.

Python-on-Parrot soffriva di differenze semantiche tra Perl 6 e Python, causando problemi con il processo di compilazione di front-end, quindi i futuri sforzi in questo settore sono in grado di utilizzare il front-end PyPy di ??indirizzare il Parrot VM.

Diversi sviluppatori VM certamente tenere d'occhio ciò che gli altri stanno facendo, ma anche quando si alzano le buone idee che metteranno il loro spin proprio su di loro prima di incorporare.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow