Dropbox bouwt Python-implementatie met snelle jit-compiler

Een aantal Dropbox-ontwikkelaars werkt aan een nieuwe Python-implementatie die de programmeertaal net zo goed moet laten presteren als code die in bijvoorbeeld C++ is geschreven. Daarvoor wordt bij het zogeheten Pyston gebruikgemaakt van een just-in-time-compiler.

De Dropbox-developers stellen dat Python in vrijwel alle gevallen de voorkeur krijgt, maar dat de programmeertaal in de praktijk tegen zijn grenzen aanloopt als software opgeschaald moet worden. Vooral de prestaties zouden in die situatie te laag zijn, waardoor code beter kan worden geschreven in een andere programmeertaal, zoals het snellere C++.

In een poging Python sneller te maken is het Dropbox-team de just-in-time-compilers gaan bekijken die in de afgelopen jaren verantwoordelijk waren voor forse prestatiewinsten in de JavaScript-verwerking van moderne browsers. Hoewel er al enkele Python-implementaties bestaan op basis van just-in-time-compilers, willen de Dropbox-developers in het Pyston-project gebruikmaken van method-at-a-time jit-compilers. Deze zouden nog aanzienlijk beter presteren dan oudere jit-implementaties. Verder wordt er gekeken naar een andere methode voor garbage collection.

Om het wiel niet geheel opnieuw uit te vinden maakt het Pyston-team gebruik van onderdelen van het llvm-project waarin diverse opensource-compilermodules zijn opgenomen. Verder is Pyston onder andere verantwoordelijk voor het voorspellen van het type object, een mechanisme dat bekendstaat als type speculation. Ook de technieken inline caches en fast attribute lookups worden toegepast.

Pyston is nog verre van compleet en de ontwikkelaars denken dat de bouw nog enige tijd zal duren. Ook voor het testen van de snelheid met behulp van benchmarks zou het nog te vroeg zijn. De code is echter beschikbaar gemaakt op GitHub, waarbij Dropbox hoopt dat meer developers gaan helpen bij de ontwikkeling.

Reacties (32)

[z.jeroen]

Het lijkt erop dat Guido van Rossum er niet direct bij betrokken is:

quote: https://tech.dropbox.com/...ation/#comment-1317209654

Kevin Modzelewski: Guido's advice has been extremely helpful, but so far we haven't been able to get any code from him

[:murb:]

Toch vreemd, het is hun collega: https://www.python.org/~guido/

[djc]

Er is eerder een poging geweest om een Python-interpreter met JIT gebaseerd op LLVM te bouwen:

http://qinsb.blogspot.nl/...wallow-retrospective.html

Maar volgens mij is de consensus onder VM-bouwers min of meer dat LLVM veelal ongeschikt is voor JIT-compilers, omdat het te traag (want omvangrijk) is om snel te compileren (wat wel belangrijk is als je probeert at run-time te compileren om sneller te zijn dan de interpreter). Zie bijvoorbeeld hier:

http://stackoverflow.com/...le-for-implementing-a-jit

[LOTG]

Volgens mij is het niet zo zeer dat een JIT compiler het probleem is, maar een JIT compiler voor een dynamically typed language. Dit is natuurlijk killing, als je moet weten wat voor data je aan het behandelen bent. Maar, zoals in het bericht staat willen ze type prediction gaan toepassen, misschien dat het daar mee beter gaat.

[djc]

Type prediction is nogal de basis van een dynamic language JIT. Toch maken V8, Mozilla's monkeys, LuaJIT, HotSpot, JavaScriptCore allemaal geen gebruik van LLVM.

[Verwijderd]

Van de github pagina:

Pyston currently targets Python 2.7

Helaas, het klinkt als een interessant project maar dit maakt het een stuk minder nuttig.

[Benji87]

Valt wel mee, Python 2.7 wordt naar mijn idee nog steeds meer gebruikt dan Python 3.x doordat er gewoon meer libraries voor Python 2.7 geschreven zijn. En de meeste libraries die voor Python 3.x geschreven worden worden compatible gehouden met Python 2.7.
Python 3.x zal Python 2.7 qua gebruik vast nog wel een keer inhalen, maar tegen die tijd zullen ze Pyston ook wel eens een keer compatible maken met Python 3.x

[Mathieu_Hinder]

Gezien 2.x en 3.x in de praktijk een andere taal is, en grote projecten gewoon niet zomaar op 3.x kunnen overschakelen, lijkt me dat redelijk logisch. Dat maakt het nuttig voor de vele software die hierop draait.

[J_Gonggrijp]

"Een aantal Dropbox-ontwikkelaars werkt aan een nieuwe Python-implementatie die de programmeertaal net zo goed moet laten presteren als code die in bijvoorbeeld C++ is geschreven. "

Zucht. Waarom moet een snelle taal altijd per sé meteen net zo snel zijn als C++? Als iets half zo snel is als C++ is dat ook al bijzonder snel. Als het 1/4 zo snel is als C++ eigenlijk ook. Kijk eens op the computer language benchmarks game om een realistischer indruk te krijgen van wat snel is en wat niet.

Als je goed leest zie je dat de makers ook helemaal niet claimen dat ze de Pyston net zo snel willen maken als C++:

"The goal of the project is to produce a high-performance Python implementation that can push Python into domains dominated by traditional systems languages like C++."

Kortom, in dezelfde orde van grootte, maar niet per sé gelijk.

Voor de duidelijkheid, het is heel onwaarschijnlijk dat Pyston uiteindelijk net zo snel wordt als C++, maar dat neemt niet weg dat het nog steeds heel interessant kan zijn vanwege de snelheid. Ik heb het project op GitHub in ieder geval gestarred.

[Goderic]

Omdat je anders 4x zoveel hardware nodig hebt om hetzelfde te doen? En dus 4x zoveel hardware en stroomkosten...

[J_Gonggrijp]

Dat is op zich wel waar, en ik ben het er ook mee eens dat je daarom in principe iets wilt dat zo efficiënt mogelijk is. Maar er is een enorme diversiteit in efficiëntie onder programmeertalen, en er is ook nog zoiets als de productiviteit van de programmeur. CPython haalt maar ongeveer 1/50 van de snelheid van C++, dus als de mensen bij Dropbox dat kunnen opkrikken naar 1/4 is dat al een enorme vooruitgang. Dat is dan ook al heel snel te noemen en daarom vind ik het nogal kort door de bocht om meteen maar te doen alsof het zo snel moet zijn als C++.

Mijn punt is eigenlijk vooral dat een vergelijking met C++ eigenlijk geen recht doet aan al die (implementaties van) talen die minder snel zijn maar nog steeds heel snel, en in ruil voor de iets lagere efficiëntie iets anders te bieden hebben. Denk aan Haskell, LuaJIT, SBCL, Forth, alle moderne implementaties van JavaScript, Pypy, Ada, Scala, Nemerle en met wat goede wil zelfs Java en C#. In dit kader vind ik het ook nogal vermoeiend dat Java-fans altijd zo graag willen geloven dat Java net zo snel (of zelfs sneller) is als C++.

Er is maar een handvol talen die echt consistent dezelfde snelheid halen als C++: C, ATS, Fortran, assembly, dan heb je het wel zo'n beetje. Dat zijn stuk voor stuk niet echt comfortabele talen om mee te werken.

[EpicEraser]

Maar er is toch al een Python implementatie met JIT?
Zie http://pypy.org/ .

[acemoo]

Als je verder leest kan je zien dat er een verschil is tussen de oude JIT compilers en de nieuwe technieken dat in JIT gebruikt worden.

[EpicEraser]

Nou ja, het leek me nuttig om Pypy in elk geval even te noemen.
Het artikel lijkt te zeggen dat JIT voor Python een nieuwe aanpak is.
Pypy geeft erg goede resultaten, maar compatibiliteit is (nog) niet 100% en de Python 3 implementatie is nog steeds niet af... Dat laatste is voor mij de reden dat ik het niet gebruik.

[acemoo]

". Hoewel er al enkele Python-implementaties bestaan op basis van just-in-time-compilers, willen de Dropbox-developers in het Pyston-project gebruikmaken van method-at-a-time jit-compilers. Deze zouden nog aanzienlijk beter presteren dan oudere jit-implementaties."

En ze willen dus gewoon betere performance als Pypy krijgen blijkbaar.

[davekok]

Type speculation is toch dat het type wordt voorspeld van een variabele en niet de waarde zoals hierboven staat.

[crumpyoldlord]

Ze zeggen toch van python dat waardes types hebben, en niet de variables à la statische talen? Afaik

[davekok]

Klopt, maar op het moment dat je compiler gaat bouwen voor welke taal dan ook ga je die als statische taal behandelen. Vandaar dat ze het type moeten weten. Anders kunnen ze de boel niet compileren en kun je niet op het performance niveau van C++ komen. Want dan zal je steeds bij elke operatie moeten checken om welk type het gaat om de juiste opcodes te kiezen. Dat is een hoop extra code die je weg kunt strippen als je het type al weet tijdens het compileren.

[Keneo]

Een reeds werkende python jit compiler die ook methode level jit kan doen en ook op het llvm project steunt is numba.

Met numba kan je bvb je zelf geschreven loopjes net zo snel maken als een zeer geoptimaliseerde cython implementatie, of numpy code. wat ik al zeer indrukwekkend vond.

[mad_max234]

Gebruik dan gelijk C/C++, waarom iets maken dat je na veel moeite ongeveer even goed kan krijgen dan iets wat al bestaat en al jaren de industriële standaard is, word het meest gebruikt in bijna alle sectoren, van uC's tot PC.

Enige wat uitmaakt is welke gecompileerde code word er gegenereerd, C is al hoge taal en zeer simpel, dat python minder regels gebruikt tijdens het code is totaal irrelevant voor meeste programmeurs. We gebruiken niet voor niks OOP stijl om alles overzichtelijk te houden en in te delen in classes, daarvoor bestaat C++.

[stereohead]

Wel eens een project gedaan met Python?

Het is niet alleen de syntax wat een taal maakt, o.a. beschikbare librarys hebben een grotere invloed op de 'programmeerervaring', daarnaast is ook de 'filosofie' van een taal een factor in deze ervaring.

Syntax is een bijzaak in een programmeertaal.

[Silmarunya]

Python is een erg eenvoudige taal met (dankzij uitstekende libraries) uitgebreide ondersteuning voor bijvoorbeeld wiskundige functies. Dat laat toe dat wetenschappers zoals ik die geen programmeur zijn maar af en toe wel wat code moeten schrijven toch relatief goede resultaten kunnen afleveren. In de C-familie wil ik dat niet proberen, toch niet als de code nog een klein beetje proper moet zijn.

Sure, python is niet 's werelds efficientste taal. Maar voor de meeste toepassingen is het goed genoeg, en zijn eenvoud en elegantie laten toe dat niet-professionals toch mooie resultaten behalen. Niet toevallig worden aan veel universiteiten wetenschappers eerst vertrouwd gemaakt met Python vooraleer ze andere talen leren.

Al zijn betaalde opties als Matlab of Mathematica vaak nog een stuk beter. Die combineren de kracht van de C-familie met enorme libraries en een bijzonder gebruiksvriendelijke omgeving.

[Reactie gewijzigd door Silmarunya op 23 juli 2024 20:43]

[PoweRoy]

Gebruik nu al een paar maanden python en ik vind het zeer prettig werken! Fatsoenlijke libraries die je eenvoudig kan gebruiken. Echt altijd heb ik weer problemen met een vage C library die weer vage opties nodig heeft om te werken.
Liefste heb ik C#, heb geen zin om het wiel weer 4x uit te vinden in C.

[Chip.]

Hmmm ik meen mij iets over een programmeer taal Go te herinneren.

[rosavanwinkle]

sinds men eerste programeer taal dat ik ooit geleerd heb python is zou ik hier best wel wat meer over willen weten ^^