[PYTHON, C] Beyond bytecode: a wordcode-based Python

[cdimauro]

Ho finito poco fa di creare su Google Code tutto il materiale relativo al mio progetto, che potete anche scaricare con SubVersion.

Trovate tutto a questo indirizzo.

Nella sezione download trovate le slide che ho presentato alla PyCon3 in formato sia PowerPoint che PDF.

Le critiche, manco a dirlo, sono bene accette (se costruttive), come pure eventuali richieste di chiarimento (a cui risponderò non appena possibile ).

[cdimauro]

Segnalo un resoconto della seconda giornata della PyCon3, in cui si parla anche del mio talk.

E un mio articolo incentrato sul solo talk che ho tenuto.

[Tommo]

Ci capisco poco e niente di quello che hai scritto nell'articolo (che era decisamente interessante)...
cmq complimenti per l'idea e per il lavoro, sembra davvero un passo avanti anche "ad occhio"

Ma esistono altri linguaggi che usano le words per le istruzioni?

[cdimauro]

Può darsi, ma non ne ho la minima idea.

Comunque se dai un'occhiata alle slide dovresti capire meglio come funziona.

Grazie comunque.

[AnonimoVeneziano]

Complimenti, ottimo lavoro

Ho leggiucchiato le slide e devo dire che hai avuto una gran bella idea
In media credo che una riduzione del numero di istruzioni per programma in un interprete identifichi un aumento prestazionale proprio per il fatto che bisogna stare meno nel ciclo di decoding delle istruzioni.
Ma l'aumento prestazionale in media quant'è? Ho visto dalle slide le percentuali su pybench e sembra una percentuale altissima

A quando l'introduzione nella mainline?

Ha qualche problema di compatibilità questo sistema o funziona bene con tutti i programmi python?

Ciao

[~FullSyst3m~]

Originariamente inviato da AnonimoVeneziano

Complimenti, ottimo lavoro

Ho leggiucchiato le slide e devo dire che hai avuto una gran bella idea
In media credo che una riduzione del numero di istruzioni per programma in un interprete identifichi un aumento prestazionale proprio per il fatto che bisogna stare meno nel ciclo di decoding delle istruzioni.
Ma l'aumento prestazionale in media quant'è? Ho visto dalle slide le percentuali su pybench e sembra una percentuale altissima

A quando l'introduzione nella mainline?

Ha qualche problema di compatibilità questo sistema o funziona bene con tutti i programmi python?

Ciao

Mi sembra abbia lavorato per la 2.6. Dovrebbe fare il backport per la 3.

[cdimauro]

Originariamente inviato da AnonimoVeneziano

Complimenti, ottimo lavoro

Ho leggiucchiato le slide e devo dire che hai avuto una gran bella idea

Grazie.

In media credo che una riduzione del numero di istruzioni per programma in un interprete identifichi un aumento prestazionale proprio per il fatto che bisogna stare meno nel ciclo di decoding delle istruzioni.

Esattamente. Questa era l'idea che mi trascinavo da tempo.

Ma l'aumento prestazionale in media quant'è? Ho visto dalle slide le percentuali su pybench e sembra una percentuale altissima

Ho messo soltanto i peggiori 10 e i migliori 10 risultati. Comunque il trend è del 20-25% circa di tempo in meno con PyBench.

A quando l'introduzione nella mainline?

Prima devo rimuovere degli hack, altrimenti gli sviluppatori ufficiali mi seviziano (Guido in primis).

Ha qualche problema di compatibilità questo sistema o funziona bene con tutti i programmi python?

Ciao

No, dovrebbe funzionare su tutto. A parte un paio di test su un caso molto particolare (le funzioni di tracing), l'intera batteria di test di Python viene eseguita con successo.

Diciamo che, risolto questo problemino (che riguarda più che altro i debugger, non le applicazioni comuni), dovrebbe essere pronta per andare in produzione a tutti gli effetti.

[AnonimoVeneziano]

Originariamente inviato da ~FullSyst3m~

Mi sembra abbia lavorato per la 2.6. Dovrebbe fare il backport per la 3.

più che il backport un frontport

[cdimauro]

Originariamente inviato da ~FullSyst3m~

Mi sembra abbia lavorato per la 2.6. Dovrebbe fare il backport per la 3.

Sì, chiaro.

Originariamente inviato da AnonimoVeneziano

più che il backport un frontport

In effetti...

[AnonimoVeneziano]

Originariamente inviato da cdimauro

Diciamo che, risolto questo problemino (che riguarda più che altro i debugger, non le applicazioni comuni), dovrebbe essere pronta per andare in produzione a tutti gli effetti.

Ottimo, non vedo l'ora

[cionci]

Complimenti Cesare
Bel progetto, molto interessante, soprattutto l'ideaa di evitare i salti rendendo il formato dell'opcode fisso.

Se hai bisogno di qualche test su Linux a 64 bit (Core 2 Duo 2.16 Ghz) sono disponibile, però mi dovresti fornire anche la suite di test

[Tommo]

Originariamente inviato da cdimauro

Può darsi, ma non ne ho la minima idea.

Comunque se dai un'occhiata alle slide dovresti capire meglio come funziona.

Grazie comunque.

Letto le slides, è molto più chiaro ora.
Cmq pensavo che i linguaggi in VM funzionassero GIA' in questa maniera, che senso ha costringersi ad usare i byte quando il computer stesso li digerisce peggio?

Cmq le istruzioni in wordcode sono di una complessità eccessiva, fortuna che le scrive il compiler

Un'idea: vista la quantità di istruzioni che si hanno ora a disposizione, potrebbe essere possibile profilare il codice e trovare le sequenze di istruzioni più comuni, quindi creare un singolo super-opcode che faccia esattamente la stessa operazione?

[cdimauro]

Originariamente inviato da cionci

Complimenti Cesare
Bel progetto, molto interessante, soprattutto l'ideaa di evitare i salti rendendo il formato dell'opcode fisso.

Se hai bisogno di qualche test su Linux a 64 bit (Core 2 Duo 2.16 Ghz) sono disponibile, però mi dovresti fornire anche la suite di test

Grazie.

Ti do delle indicazioni intanto su come compilarlo su Linux, visto che c'è un mio amico che ha avuto qualche problema.

Dopo averlo configurato (con ./configure immagino), copia il mio file Python_ast.h su quello che è stato generato automaticamente.

Per i test, in Tools/pybench c'è il file pybench.py. Basta eseguirlo nel seguente modo (supponendo che python si trovi nella root):

python Tools/pybench/pybench.py -f pybench_results.log

e postare i risultati (magari compressi in formato zip). Così posso confrontarli con quelli della versione base (che si trovano nel sito del progetto).

Per PyStone, invece, basta eseguire questo:

python Lib/test/pystone.py

Ma è meglio farlo per un certo numero di volte, scartare il primo risultato e fare la media degli altri. Questo perché è un po' "ballerino" come test (almeno nelle macchine in cui l'ho provato).

[cionci]

Originariamente inviato da Tommo

Letto le slides, è molto più chiaro ora.
Cmq pensavo che i linguaggi in VM funzionassero GIA' in questa maniera, che senso ha costringersi ad usare i byte quando il computer stesso li digerisce peggio?

In effetti...

Comunque le strade da percorrere ora potrebbero essere molteplici: gli opcode a 16 bit rendono secondo me il parsing un filo inefficiente. Forse la dimensione migliore sarebbe 32 bit, ma ovviamente si perderebbero i vantaggi nel risparmio di spazio. Però con l'idea di Tommo la cosa potrebbe divenire interessante, la fusione di una sequenza di istruzioni in un solo opcode a 32 bit farebbe risparmiare ancora spazio e renderebbe il tutto più veloce (ovviamente senza mescolare opcode a 16 e a 32 bit).

[cdimauro]

Originariamente inviato da Tommo

Letto le slides, è molto più chiaro ora.
Cmq pensavo che i linguaggi in VM funzionassero GIA' in questa maniera, che senso ha costringersi ad usare i byte quando il computer stesso li digerisce peggio?

Perché non è semplice altrimenti. Leggere singoli byte non ti crea problemi di endianess e di allineamento delle word, come ho scritto nell'apposita slide.

Con la mia soluzione ho dovuto prendere adeguate misure per garantire che il codice funzionasse sia su macchine little-endian che su macchine big-endian, e coi relativi problemi di allineamento (ad esempio su ARM non è possibile leggere word a indirizzi dispari).

Insomma, c'è da sbatterci un po' per avere una soluzione che sia compatta, performante, ma soprattutto... funzionante su modelli diversi dai bytecode.

Infine c'è da considerare anche l'architettura che si vuole creare, che in genere si pensa e realizza sulla base del linguaggio. Ad esempio la VM di Java è molto diversa da quella di .NET, ed entrambe le sono rispetto alla soluzione bytecode dell'attuale Python e della mia wordcode.

Cmq le istruzioni in wordcode sono di una complessità eccessiva, fortuna che le scrive il compiler

Veramente le ho scritte io. Una per una.

Un'idea: vista la quantità di istruzioni che si hanno ora a disposizione, potrebbe essere possibile profilare il codice e trovare le sequenze di istruzioni più comuni, quindi creare un singolo super-opcode che faccia esattamente la stessa operazione?

Già fatto.

Nel repository SVN in Tools trovi la cartella codebench che ho creato, in cui si trovano due applicazioni python da eseguire rigorosamente e rispettivamente per la versione bytecode e per quella wordcode.

Lanciate senza parametri compilano tutti i file .py che trovano nelle cartelle Lib e Tools, e riportano poi tutta una serie di statistiche.

E' così che ho trovato un bel po' di pattern a cui ho dedicato poi degli opportuni opcode.

Ce ne sarebbero altri, ma al momento ho altre cose da fare, per cui magari tornerò a metterci mano dopo che avrò stabilizzato il progetto.

[cdimauro]

Originariamente inviato da cionci

In effetti...

Comunque le strade da percorrere ora potrebbero essere molteplici: i dati a 16 bit rendono secondo me il parsing un filo inefficiente. Forse la dimensione migliore sarebbe 32 bit, ma ovviamente si perderebbero i vantaggi nel risparmio di spazio.

Non solo: si aumenterebbe anche il consumo di bandwidth, e aumenterebbero le istruzioni necessarie per estrarre i dati che servono (opcode e relativi parametri), in particolare sulle architetture big-endian.

Però con l'idea di Tommo la cosa potrebbe divenire interessante, la fusione di una sequenza di istruzioni in un solo opcode a 32 bit farebbe risparmiare ancora spazio e renderebbe il tutto più veloce (ovviamente senza mescolare opcode a 16 e a 32 bit).

Lo faccio già.

Nella mia implementazione ho opcode a 16 e 32 bit, e alcune fanno un mare di lavoro (arrivo a eseguire gli stessi compiti di ben 4 istruzioni della vecchia implementazione).

Il modello che ho proposto non ha opcode di dimensione fissa: la dimensione è variabile, e attualmente posso avere istruzioni di 1, 2 o 3 word (quindi 2, 4 o 6 byte).

Un modello "CISC", appunto, che è il nome che ho dato a questa versione.

Altre VM, come quella di LUA ad esempio, utilizzano invece opcode a 32 bit di dimensione fissa.

[~FullSyst3m~]

C'è poco da dire. Gran bel lavoro davvero. Mi stupisce sempre di più vedere quante cose conosci. Complimenti.

[Tommo]

Capito...
cmq io intendevo "fortuna che all'utente finale le scrive il compiler"... lo so che al compiler le hai scritte te

La mia idea nasce proprio da questo punto: in pratica, creare un wordcode generator, che trova le sequenze più comuni in bytecode e genera le corrispondenti opcode, diverse per ogni programma.
Ovviamente il tutto non sarebbe solo a compile time, perchè una sequenza che compare una volta sola nel codice potrebbe essere ripetuta milioni di volte a runtime...

Quindi, dopo che lo fai girare un pò di tempo sulla tua applicazione, genera un wordcode "personale" che contiene words uniche per le parti critiche del tuo programma.
IMHO avrebbe senso, perchè ora che avete 32768 comandi disponibili è follia pensare di riempirli tutti a mano
Ovviamente, è solo un'idea random

[cdimauro]

Originariamente inviato da Tommo

Capito...
cmq io intendevo "fortuna che all'utente finale le scrive il compiler"... lo so che al compiler le hai scritte te

Sì, avevo capito, e ho fatto una battuta giusto per sdrammatizzare un po'.

La mia idea nasce proprio da questo punto: in pratica, creare un wordcode generator, che trova le sequenze più comuni in bytecode e genera le corrispondenti opcode, diverse per ogni programma.
Ovviamente il tutto non sarebbe solo a compile time, perchè una sequenza che compare una volta sola nel codice potrebbe essere ripetuta milioni di volte a runtime...

Quindi, dopo che lo fai girare un pò di tempo sulla tua applicazione, genera un wordcode "personale" che contiene words uniche per le parti critiche del tuo programma.
IMHO avrebbe senso, perchè ora che avete 32768 comandi disponibili è follia pensare di riempirli tutti a mano
Ovviamente, è solo un'idea random

Ho capito. Ci sono tre problemi con questa soluzione.

Il primo è che dipende tutto dal codice eseguito. Se n'è già discusso nella mailing list di Python, e purtroppo le prestazioni delle versioni "profile guided" dipendono appunto dal profilo scelto (es: template HTML, conversione dalla 2 alla 3, problema delle 8 regine, ecc. ecc.).

Il secondo è che gli opcode prodotti non sarebbero ottimizzati, perché non si può semplicemente prendere una sequenza di bytecode e tirare fuori una wordcode corrispondente. Le wordcode che ho creato arrivano da opportuni "tweak" che mi hanno permesso di compattare il più possibile le informazioni che mi interessavano in poco spazio (infatti al più utilizzo 2 word per le "macroistruzioni" più complesse).

Il terzo è che... la opcode table è rimasta di 256 elementi, e non 32768. Quindi c'è poco spazio, e infatti con le istruzioni che ho creato me ne sono mangiato già ben più della metà.

[Tommo]

Ok come non detto

Ma prima i 256 opcode con cosa erano riempiti allora?