[Python-de] Minimal Python (war: [Langer, leicht ins OT driftende Sermon] Was mir an Python gef?llt)

Christian Tismer tismer at tismer.com
Sat Jan 4 16:30:35 EST 2003


holger krekel wrote:
...

>>>welche teile meinst du genau mit kernel?
>>
>>Der Kernel ist für mich zunächst das absolute
>>Minimalsystem, damit's läuft. Dieser Teil ist
>>in C geschrieben.
>>
>>Es ist mehr ein Scripting-Kernel, weniger auf
>>Python fixiert.
>>
>>Als implementierte Grundstrukturen schweben mir
>>vor (aber diese könnten evtl. noch reduziert werden):
>>
>>allg. Sequence, List, Tuple
>>allg. Mapping, Dictionary, String-Dict
>>Integers
> 
> 
> bis hierhin ist es wohl keine Frage, das in C zu machen
> bzw. zu belassen.  Allerdings ist 'Sequence' kein Type. 
> Das ist ein Protokol auf einer hoeheren Ebene oder 
> was meinst du genau? 

Ich meine die Sequence-Implementierung als
Protokoll, also die nötigen Definitionen,
um entsprechende Methoden aufrufen zu können,
vgl. etwa abstract.c und object.c . Nicht daß
ich diese kopieren will, aber im Prinzip
implementieren diese Module Operationen auf
gewissen Objekten, die das Protokoll unterstützen.

Ich halte es für wichtig, nicht einfach nur
Listen und Dicts zu implementieren, sondern
von vornherein deren Abstraktion.
Python hat dies erst relativ spät getan, und mit
dem bereits vorhandenen Wissen haben wir die
Chance, evtl. besser starten zu können.
Ebenso würde ich gern alle Objekte von vornherein
total virtualisieren, also mit Methodentabellen
ausstatten und von Python aus überschreibbar machen,
mit dem neuen Objekt-Ansatz und evtl. meinem
Flextype-Ansatz obendrauf.

>>Frames
> 
> 
> [zu meiner vergewisserung]
> ein Frame ist ja das objekt, mit dem der interpreter arbeitet.
> Es enthaelt Informationen darueber, was die VM gerade abarbeitet,
> ueber 'code bloecke' wie z.B. try-finally Konstrukte, damit im
> Falle einer Exception der Stack zurueckgerollt werden kann.

Ganz recht.

> Zudem kennt es alle Konstanten und lokalen, globalen und freien
> Variablen(namen).  Frei sind Variablen z.B. wenn sie einen
> nested Scope referenzieren. 

Genau. Soweit der Python-Teil.
Dann kommen noch eine Handvoll C-Variablen dazu,
damit der Interpreter seinen Zustand dort ablegen
und später wieder abholen kann. Damit haben wir
alles, um in den meisten Fällen keine rekursiven
Calls zu benötigen.

>>Interpreter für Bytecode Python 2.3
> 
> 
> Vielleicht liesse sich der schon in Python schreiben? 
> Erst mal klingt das widerspruechlich. Wie sollte der Interpreter
> jemals einen bytecode interpretieren, wenn diese interpretation
> auch wieder aus der interpretation von bytecodes besteht.  

Also zwei Sachen:
Zunächst is ja mal noch nicht klar, ob wir überhaupt
einen Bytecode-Interpreter als zentralen Kern der
Sprache wollen, oder ob die Reise woandershin geht.
Die Anforderung war ja, Python-Code ausführen zu
können, Bytecode muß nicht unbedingt sein.
Davon ganz abgesehen, aus Gründen des einfachen
Bootstrappings macht es natürlich sehr viel Sinn,
einen Bytecodeinterpreter zu haben, denn dadurch
kann "die Kiste loslegen", sobald das Dings läuft,
egal auf welche Weise wir den Bytecode erzeugen.
(Michael Hudson hat sicher eine bestimmte Idee dazu :-)

Was wir gewiß brauchen werden, ist eine Schnittstelle,
die die Interpreter-Variablen zugreifbar macht, also
Operationen, die mit Frames arbeiten können.
Sicherlich kann der erste Interpreter zumindest
teilweise selbst aus Bytecode bestehen, wenn der sich
per Schnittstelle auf andere Sequenzen abbilden läßt.
Beispiel: BUILD_CLASS ist ein Opcode, den ich wirklich
nicht in C implementieren würde.

Damit die Codes irgendwann mal wirklich die CPU zu sehen
bekommen, wird man ein wenig C-Code schon brauchen.
Aber das heißt noch immer nicht, daß es einen Interpreter
in C geben muß. Es wäre auch ein Maschinensprache-
-Interpreter möglich, wie unten angedeutet, welcher
nur ein paar gut ausgesuchte Speicheroperationen kann,
und man kann für den dann Code erzeugen, per Rigo-mat.
Dazu unten mehr...

> Andererseits ist es durchaus vorstellbar, einen Interpreter 
> komplett in python zu schreiben.  Es hindert uns nichts daran, 
> die C-Frame Funktionalitaet in python zu implementieren, oder?  
> Insofern duerfte das "nur" ein bootstrapping problem sein.  

Richtig. Ein minimales Set von Operationen in C ist
nötig, damit irgendwas geht. Sobald man es schafft,
darin den Großteil der nötigen Bytecodes zu
interpretieren, ist bereits das Meiste geschafft.
Die Kiste läuft, wenn auch sehr langsam (schätze
so etwa 30 mal langsamer als Python heute).

Das wäre dann eine Mini-Engine in C, die eine virtuelle
Registermaschine interpretiert, sowie eine Handvoll
von System-Interfaces, ohne die es nicht geht.
Diese Engine implementiert die Bytecodes, und wir können
Python .pyc files ausführen.

Dann kann man überlegen, ob man Bytecode weiter
unterstützt, oder ob die Opcodes durch Armin
gleich auseinandergedröselt und direkt ersetzt
werden. Hier kann man viel spielen.

Naja, und dann geht's los: Statt der virtuellen
CPU nehmen wir dann ein paar richtige, zuerst
natürlich X86, und lassen dafür Code generieren.
Vielleicht läßt sich die virtuelle CPU auch so
schön machen, daß man sie als Zwischensprache
beibehaltn kann und erst nachträglich in die reale
CPU umsetzt -- keine Ahnung!

Jedenfalls sehe ich es so, daß auf diesem Wege
fast die gesamte vorhandene C-Bibliothek total
aufgeweicht werden und in Python geschrieben
werden kann. Dadurch verschmelzen alle Teile,
es gibt nicht mehr "außen" (Python Code) und
"innen" (C-Funkionen), sondern die Grenzen
verwischen, und es kann komplett durchoptimiert
werden. Letztlich träume ich von einem dynamischen
Python mit JIT, welches drastisch performanter
ist als das heutige Python.

> "Of course, you tell, the Python interpreter is meant to be executed, as
>  fast as possible. Wrong! There are cool things we can do about it
>  without blindly running it. If (portions of) the core interpreter were
>  written in a higher-level language --- say Python --- we would have more
>  control over it." Armin Rigo in http://psyco.sourceforge.net/plans.html

Totally agreed. Don't be greedy for speed. Find
abstractions and use them, and you will create
interpreters nobody has dreamt about, before.

> Wenn Frame+Interpreter in python geschrieben waeren, waeren
> das Probleme [toedliche "Rekursion":-] fuer Stackless?  

Ganz im Gegentum, was besseres könnte Stackless
überhaupt nicht passieren. Alles was nicht in C
geschrieben ist, läßt sich ganz problemlos stackless
machen.

>>Function objects
>>
>>New-Style classes
> 
> 
> da kenne ich mich noch gar nicht aus (auf der C-Ebene). 

Das ist ein recht komplexes Teil. Die wichtigsten
Sachen sind in typeobject.c implementiert. Die
Lektüre kann ich nur empfehlen. Dort sind die ganzen
neuen Inheritance-Sachen implementiert, die Slots usw.,
es werden die ganzen Property-Objekte angelegt, jede
Methode bekommt dynamisch ihren eigenen Wrapper...
Diese Ecke ist genial, etwas besseres habe ich von
Guido noch nicht gesehen.
Mit einem kleinen Patch bekommt man da auch noch
dynamisch überschreibbare Methodentabellen hinein,
die ich inzwischen in meinem Projekt dauernd
einsetze. Aber das ist schon wieder statisch an C
gedacht. Wenn wir erstmal richtige Datenstrukturen
von Python aus generieren, ist das wahrscheinlich
alles kalter Kaffee!

>>Minimales File-Interface
> 
> 
> was ist mit den ganzen os.path, socket und sonstigen 
> lowleveligen systemgeschichten?  Die sind weiterhin
> in C (moeglichst unveraendert) zu belassen, oder?

Ich würde das Geraffel erstmal so übernehmen, wie's
ist. Leider muß man es haben und es ist nicht trivial.
Eine minimalistische Version würde ich später angehen,
wenn wir entsprechende Erfahrung gesammelt haben.

>>wenige, essentielle builtins.
> 
> 
> Auf dem Namespace-Level wuerde ich die Kompatibilitaet
> nicht ueber den Haufen werfen.  

Nein, dazu bestht kein Grund.

> Auf der Frame, bytecode und Interpreterebene kann man ja 
> ggf. aendern.  Aber die effektiven namespaces, mit denen 
> Python Module laufen, sollten wir nicht veraendern.  Ist 
> doch auch kein grosses Thema, weil die meisten builtins sich
> doch schnell in python (statt in C) formulieren lassen. 

Sehe ich genauso.

[MMIX]

> Ist MMIX wirklich schon so weit?  Wie 'minimal' ist
> denn MMIX?  Da es von Donald Knuth kommt, wird es 
> wohl sehr gut sein.  Kannst du ein paar Eckpunkte
> benennen?

MMIX ist eigentlich etwas zu groß, man müßte evtl.
abspecken. Es hat viele Register, überlappende
Ausführungseinheiten und weißgottwasalles, was
wir alles (zunächst) nicht brauchen. Aber die
Architektur ist hochmodern, es ist von vonherein
eine 64 Bit-Maschine, und es wird nicht lange
dauern, bis ähnliche Maschinen au den Markt
kommen. Nicht schlecht, wenn man dann schon etwas
halbwegs passendes in der Tasche hat.

Ich fand das Modell interessant, weil's eine
3-Adreß-Maschine ist. Von Stack-Maschinen habe
ich die Nase voll. Das ist was für hand-Fummler,
aber compiler-generierter COde für Registermaschinen
ist effizienter.

Ich habe das MMIX-Handbuch erworben, kannst Du
gerne drin lesen, wenn Du zum BPS kommst.

>>mehr eigentlich nicht.
> 
> 
> Threading?  Auf irgendeine Weise muss Threading 
> zumindest mitgedacht werden, aber frag mich nicht
> auf welche :-)

Habe ich, zugegeben, total ausgeklammert.
Dies ist eine komplett eigenständige Wurmkanne,
einen extra-Thread wert.
Aus meiner Stackless-Sicht brauche ich eigentlich
fast kein Threading, höchstens für MPU-Support
wird's leider wieder nötig, echt parallele
Ausführung zu unterstützen.

Von Seiten Python's haben wir eigentlich alles in
der Hand, unser eigenes Threading zu basteln, da
wir alles komplett in der Hand haben.
Threads für externe Bibliotheken, die dann vielleicht
auch noch Callbacks in Python haben wollen, machen
das Leben leider schwer. Ich habe keine große Lust
auf den Global Interpreter Lock, ebenso nicht auf
eine total thread-safe Implementierung, bei der
man sämtliche Objekte andauernd schützen muß.

Am liebsten würde ich reale Threads vom Namensraum
her komplett disjunkt halten und nur explizite
Rendevouz zulassen, bei dnen Daten durch Kopieren
ausgetauscht werden, oder read-only geshared.
Das wäre eher mehreren Prozessen ähnlich.

Vielleicht wäre aber auch das etwas, was ein Compiler
zur Laufzeit erkennen kann: Welche Objekte müssen
geschützt werden? Der nötige Code könnte evtl.
unmittelbar generiert werden. Aber das Thema
führt im Moment zu weit.

Zunächst würde ich die Basisstrukturen für Threading
mit einbauen, also tstate wie gehabt, das Locking
usw., rausschmeißen kann man's immer noch.

>>Alles obige genannte sehe ich ebenso auf's
>>Minimum reduziert.
>>
>>Eigentlich ist mir das immer noch zuviel.
>>Aber das System wird und in die Lage versetzen,
>>die nächste, noch weiter abgespeckte Version
>>darin zu implementieren. Hoffe ich.
> 
> 
> zumal nur das umsetzen koennen, was innerhalb
> einer woche zu einem release fuehrt :-)

Also wenn's gut geplant ist, sollte schon etwas
dabei herauskommen. Datenstrukturen können wir
viele übernehmen, ebenso die Basisobjekte, um
etwas zum Loslegen zu haben. Es könnten ein paar
Grupen gebildet werden und Teilprojekte bearbeiten,
wie etwa den Bytecode-Interpreter teilweise in
Python zu schreiben, primitive Opcodes auf die
virtuelle Maschine abbilden, für letztere würde
ich mich anbieten...

Wichtig ist, das am Ende der Woche ein *irgendwie*
funktionierendes Dingbums herauspurzelt und "Wääh"
sagt, mit minimalem C, egal welcher Performance,
aber in der Lage, große Teile der Python-Bibliothek
auszuführen.

>>>wann ist denn der naechste BPS?   
>>
>>Am 24.01.03 Heilbronner Str. 10, 10709 Berlin, 18:00
> 
> 
> werde versuchen, da zu sein.  (Kann ich ggf. bei dir 
> uebernachten?)

Wahrscheinlich ja, manchmal sind wir zwar überbelegt,
aber wir kriegen Dich ganz sicher irgendwie
untergebracht.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/






More information about the Python-de mailing list