PyPy 1.2

V pátek vyšlo PyPy 1.2, nová verze implementace Pythonu napsaná v Pythonu. Hlavní novinkou je JIT kompilátor, který je zatím dostupný jen pro 32bit x86, ale v některých případech rychlejší než CPython.

14.3.2010 20:06 | David Watzke | Nová verze

Komentáře

[multi]

implementace Pythonu napsaná v Pythonu - proc to delaj, k cemu je to prakticky dobre? (vazna otazka)

[Jamp]

Oni to pisu v RPython, podmnozine pythonu, ktoru vedia priamo prelozit. Dobre je to hlavne na ulahcenie experimentov s interpreterom a zvacsenie prehladnosti kodu, pre ilustraciu sucastny jit je v poradi asi piaty (toto cislo cucam z prsta, proste ich uz predtym skusili dost) pristum k optimalizaciam.

[Eddie]

IMHO se to může hodit na testování potenciálních nových vlastností - napsat je v Pythonu bude mnohem snazší než v C. Mohou si tedy vlastnost relativně rychle implementovat v PyPy, otestovat a v případě schválení pak (dlouze) implementovat v C.

[Martincek]

Navíc je to úplně normální, že se kompilátor jazyka programuje ve stejném jazyce.

Třeba první Pascal prý vznikl tak, že Wirth napsal překladač Pascalu v Pascalu, poté ho "na papíře" zkompiloval a výsledné instrukce teprve nacpal do počítače.

Jednak se tím ověří funkčnost nového jazyka a také to člověk píše v něčem, co do detailu zná.

[Jamp]

Toto tu uz bolo diskutovane, problem je v tom, ze PyPy je interpreter, nie kompilator, teda na to, aby ste zbehli interpreter v samom sebe, potrebujete tiez interpreter atd., teda niekde na konci by zrejme bol CPython.

[mj41]

Kolik programátorů v Pythonu umí Python a kolik Céčko?

Proč někdo píše v Pythonu, když v Céčku to bude rychlejší? Proč někdo píše v Céčku, když to bude v assembleru rychlejší?

Proč je většina velkých programů napsaných v Javě dnes na víceprocesorových strojích rychlejší než ty napsané v Céčku?

[maertien]

Nu, porad lepsi pypy nez chrochro.

[xm]

Nevíte někdo jak je na tom nový JIT v PyPy v porovnání s Psyco pro CPython? Vím že původní autor Psyco snad odešel právě dělat na PyPy, ale nějak jsem to delší dobu nesledoval...

[xm]

Odpovím si sám - wow, tohle jsem vážně nečekal! Konečně už nadešel čas na nasazení PyPy v reálu, na to jsem dlouho čekal, PyPy mi je nesmírně sympatické a už je na tom i výkonově výborně...

Teď jen aby si našli čas na implementaci Pythonu 2.6 a 3.0 ...

[.]

Hustý, fakt hustý. Dost mi to připomíná tvrzení, že Java je rychlejší, než C. V tomhle případě se ale mluví o interpretru, takže to lze tvrdit - PyPy má prostě lepší interpretr, než CPython

[David Watzke]

Konečně už nadešel čas na nasazení PyPy v reálu,

Nenadešel, přímo autoři PyPy píšou, že ještě ne.

[xm]

Tak jistě, na něco se PyPy nehodí (kvůli absenci podpory Cčkových modulů), ale pro spoustu věcí si již nasazení v reálu dovedu dobře představit.

[While Noise Junkie]

Spis slo o tu stabilitu, myslim :)

[xm]

Pokud vím, tak všechny testy ze standardního Pythonu pod PyPy prochází. A o žádné nestabilitě jsem nečetl.

Samozřejmě musí dát člověk pozor na drobné implementační rozdíly mezi interpretery. PyPy např. standardně používá úplně jiný typ garbage collectoru než primitivní reference counting v CPythonu, od čehož se odvíjí třeba to, že pokud napíšete něco jako open("soubor.txt", "w").write("ahoj"), tak na rozdíl od CPythonu tam to "ahoj" pravděpodobně nebude zapsáno okamžitě, jelikož GC v PyPy zasáhne až po nějaké chvíli. Ovšem to je samozřejmě chybný kód (spoléhající se na konkrétní chování GC v interpreteru CPythonu, což ovšem nikde není zaručeno, není to žádný standard).

[xxx]

na tomto kodu neni nic chybneho a unika mi i vliv GC, ktery by mel vracet nepouzivanou pamet systmu a uvedeny kod neni zavisly n vraceni pameti systemu

[xm]

Jde o to kdy je zavolána metoda __del__ objektu. V případě primitivního reference countingu je to okamžitě poté, co zmizí poslední reference na daný objekt. U jiných pokročilejších GC to tak však být nemusí (což ji i případ PyPy), metoda __del__ je zavolána až po nějaké době (když GC provede nejbližší kolekci).

No a z tohoto důvodu ve výše uvedeném případě (pokud člověk ručně nezavolá metodu close) může dojít ke skutečnému zápisu dat na disk v případě PyPy až později (v případě CPythonu okamžitě).

Správné je buď ručně zavolat metodu close nebo ještě lépe použít konstrukci with.

[JoHnY2]

PyPy je zajimavej projekt, ale osobne vkladam vetsi nadeje do http://code.google.com/p/unladen-swallow/

Unladen ma podle me proti vsem ostatnim implementacim (mimo CPythonu, samozrejme) vyhodu v tom, ze podporuje Python C API. Druha vec je potom fakt, ze za tim stoji google, kterej ma eminentni zajem z nej driv nebo pozdejc vykresat poradny vysledky.

Velkej skok v projektu by mel bejt videt nekdy mezi dubnem a kvetnem, protoze tedka se vic pracuje na vylepsovani LLVM (2.7) tak, aby se vubec pro python hodilo.

[xm]

Unladen Swallow ale pokud vím není (narozdíl od PyPy) interpreter Pythonu napsaný v Pythonu. Je to prostě jen upravený CPython s JITem postaveným nad LLVM. Tím pro mě ztrácí veškeré kouzlo :-P

A btw. současný JIT v PyPy dává větší výkon (podle těch testů co jsem viděl výše) než Unladen Swallow.

[While Noise Junkie]

Otazkou je taky v cem. Treba takovehle benchmarky http://shootout.alioth.debian.org/ by byly fajn.

[xm]

Podívejte se na speed.pypy.org, tak pěkně zpracované automatické testy se jen tak nevidí. Vyplývá z toho celkem jasně, že jediné v čem PyPy výkonnostně zaostává za CPythonem jsou regexpy (ty nejsou zatím vůbec JITované) a pak TCP spojení (tam ještě máme nějaké optimalizace očekávat).