Python 3.13 pravděpodobně dostane JIT kompilaci

Python 3.13 pravděpodobně dostane JIT kompilaci. Pokud bude schválen pull-request 113465. Díky JIT (just-in-time) kompilaci by se běh programů mohl zrychlit o 2 až 9 procent.

10.1.2024 15:00 | Ladislav Hagara | Komunita

Komentáře

[koroptev]

2-9% neni to preklep??

[koroptev]

odpovim si sam: neni

ze jim to za tu namahu stalo

[xkucf03]

Pro srovnání:

On average, GraalPy is 4.3x faster than CPython.

Python v GraalVM.

P.S. z diskuse na HN v roce 2021:

Wonder if the techniques can be upstreamed to upcoming JIT in CPython

tak se to přeci jen povedlo, akorát místo 4× rychlejší je to o 4 % rychlejší (místy až 9).

[koroptev]

pry neumi udelat full blown jit, aniz by to nemelo fixni 1GB RAM penalty a nemelo to 100x pomalejsi startup

premyslim, proc je node.js tak rychle, hmmm

[xkucf03]

Java měla vždycky pomalejší start, ale to už se hodně zlepšilo. I na 11 let starém CPU a Javě 17 trvá hello world tzn. start a ukončení JVM 35 ms:

$ time java Hello 
ahoj

real    0m0,035s
user    0m0,015s
sys     0m0,026s

Není to sice jako nativní AOT kompilovaná binárka třeba v C/C++, ale i tak to už asi ničemu nevadí.

Co se týče paměti: 36 MB. To taky na dnešní poměry není špatné (a rozhodně to není 1 GB).

[koroptev]

citoval jsem ten linkovanej clanek, kde oni zduvodnuji tohle 2-9% design decision a proc neudelali full blown jit

[kutr]

pry neumi udelat full blown jit, aniz by to nemelo fixni 1GB RAM penalty a nemelo to 100x pomalejsi startup

premyslim, proc je node.js tak rychle, hmmm

Vtipálku, slušný python programátor porazí node.js i bez jit, rychlost pythonu neví v rychlosti interpretru ani v optimalizacích, ale z dobře použitých knihoven. Kdybys uměl číst, viděl bys, že JIT v pythonu 3.13 je experimentální featura, která nemá za cíl cokoliv zrychlovat, jen přidat API, aby se s tím do budoucna počítalo. Až se udělá opravdový jit, pak bude python konečně dostatečně použitelný i pro debily co dneska píšou v nodu nebo komentují tady.

[Erin]

A ty rychlé knihovny ale nejsou napsané v Pythonu (nebo alespoň ne celé) takže »Python« programátor*ka je porazí tak svým C, C++, FORTRAN, Rust,… kódem.

[koroptev]

co prosimte znamena to "porazi"?

to budou nejak sermovat mecema?

[B]

Hlavní problémy Pythonu jsou dva:

• první je, že se to vyučuje všude, takže se ho učí kdejaké jelito.
• druhý je, že většina lidí nechápe, že Python je lepidlo a pokud chci psát program, který je delší než 100 řádků, tak bych si měl vybrat nějaký jiný jazyk.

A úplně nejhorší jsou Python fanatici co chcou přepisovat program z kompilovaného jazyka do Pythonu, protože si myslí, že pak budou více cool. Jednu takovou jsem potkal v práci. Raději jsem s ní dále nediskutoval.

[Erin]

Python že má hodně knihoven na všechno. To je pravda ale jak

>první je, že se to vyučuje všude, takže se ho učí kdejaké jelito.

tak na některé věci nějaké knihovny jsou opravdu ňamka.

[xkucf03]

Tipnu si: něco kolem kryptoměn nebo AI (dosaď si aktuální módní trend).

Další výživná oblast je „datová analytika“ – to totiž jsou totiž lidé, kteří nechtějí vyvíjet software, dělat inženýrství, ale potřebují přeházet nějaká data z jedné hromady na druhou a při tom je trochu upravit. Výsledkem jejich práce není software ale data přeházená na jinou hromadu. Ono je to fajn a když jim to slouží jako nástroj, tak proč ne, jen by se tyhle výtvory neměly zaměňovat se softwarem.

Zrovna nedávno na jednom IRC kanálu:

to mi přijde podobné, jako to bylo u kryptoměn, jak je něco v kurzu, tak se tam software píše hrozně ve spěchu, bez ohledu na kvalitu, většinou je to nějak narychlo poslepovaný prototyp, který najednou lidi začnou používat v produkci

[koroptev]

to je dnesek

je tez nutny se divat, odkud python prisel - z doby, kdy konkurenty byly tcl a perl, tozn. naprosty silenosti a python byl oproti nim "normalni" programovaci jazyk

[Erin]

Interakce s nějakými embedded věcmi v konzumní elektronice :D

»AI« a kryptu se vyhýbám jako čert kříži.

[xkucf03]

Hodně lidí ti právě řekne:

Python je bezva, protože je bezpečný, vysokoúrovňový, není to Céčko…

a zároveň ale, když upozorníš na pomalost Pythonu:

Python je lepidlo a výkonný kód je stejně v nativní kompilované knihovně, takže nevadí, že samotný Python je pomalý.

Jenže ty knihovny jsou typicky psané v Céčku, což jaksi popírá tu výhodu vysokoúrovňosti a bezpečnosti. To by se musely psát třeba v Rustu, C++, D, Go (?) nebo Javě kompilované přes GraalVM do nativní binárky. Pak by to bezpečné bylo. Ale když už člověk místo C dokáže použít Rust/C++/D/Go/Javu, tak proč vůbec potřebovat nějaké lepidlo v podobě Pythonu? Argument, že se nemusí kompilovat moc neberu, protože malé programy jsou zkompilované hned a automatizace je otázkou jednoho jednoduchého Makefilu nebo něčeho podobného. Navíc nutnost přepínat mezi jazyky podle toho, zda člověk chce zrovna „lepit“ nebo „programovat“ je dost nešikovná. Nemluvě o tom, že i při použití vyššího jazyka bude to rozhraní mezi Pythonem a nativní knihovnou mít nejspíš podobu céčkového API.

Zrovna teď jsem potřeboval napsat „skript“ který mi z LDAPu vytáhne určité osoby a výsledek vypíše jako CSV. Mohl bych to udělat v shellu nad příkazy ldapsearch, grep, sed, awk atd. ale převádět ta strukturovaná data na text a ten zase parsovat a převádět dál na CSV mi bylo proti srsti. Tak jsem to napsal v Javě. A přijde mi to jako nejlepší řešení – je to jednoduché, nemá to žádné závislosti (klient pro LDAP je ve standardní knihovně a generátor CSV je jedna třída na pár řádků). Kdybych měl naučenou/vyzkoušenou LDAP knihovnu v jiném jazyce, tak bych to napsal třeba v C++, Rustu, D. Ale proč bych to měl psát v Pythonu?

[tacoberu]

Ale když už člověk místo C dokáže použít Rust/C++/D/Go/Javu, tak proč vůbec potřebovat nějaké lepidlo v podobě Pythonu? Argument, že se nemusí kompilovat moc neberu, protože malé programy jsou zkompilované hned a automatizace je otázkou jednoho jednoduchého Makefilu nebo něčeho podobného.

Protože když dáváš zákazníkovi aplikaci, kterou si může customizovat programováním, tak mu tam nebudeš na systém instalovat komplet vývojovej stack.

Já teda Python nepoužívám, ale význam lepidla celkem chápu. V mém případě je to Rust jako ten kompilovaný jazyk, a Rune jako lepidlo.

[Erin]

Lua je skvělá pro embedded. Já jsem u svého posledního programu na kterém jsem dělala který používá embedded jazyk použila Rhai protože lidi co ho budou používat ho rádi a do Rustu se zabudovává hezčeji, ale jinak... LuaJIT.

[kutr]

Jenže ty knihovny jsou typicky psané v Céčku, což jaksi popírá tu výhodu vysokoúrovňosti a bezpečnosti. To by se musely psát třeba v Rustu, C++, D, Go (?) nebo Javě kompilované přes GraalVM do nativní binárky. Pak by to bezpečné bylo. Ale když už člověk místo C dokáže použít Rust/C++/D/Go/Javu, tak proč vůbec potřebovat nějaké lepidlo v podobě Pythonu? Argument, že se nemusí kompilovat moc neberu, protože malé programy jsou zkompilované hned a automatizace je otázkou jednoho jednoduchého Makefilu nebo něčeho podobného. Navíc nutnost přepínat mezi jazyky podle toho, zda člověk chce zrovna „lepit“ nebo „programovat“ je dost nešikovná. Nemluvě o tom, že i při použití vyššího jazyka bude to rozhraní mezi Pythonem a nativní knihovnou mít nejspíš podobu céčkového API.

Spousta těch knihoven je v Cythonu (např. numpy), což je takový podivný hybrid mezi pythonem a C. Výhoda v bezpečnosti je stejná jako u toho rustu: mám pevně oddělené safe a unsafe části. Výhoda oproti tomu to psát v jazycích co zmiňuješ je mnohem vyšší produktivita a menší množství kódu, při hodně podobné rychlosti běhu programu. A když už rychlost nestačí neni zase problém přepsat výkonově kritický python modul do rustu nebo C++, oba mají efektivní a jednoduše použitelné knihovny pro python bindingy.

Pokud seš tak starej, že píšeš nejradši skripty v javě, k asi nemá cenu tě přesvědčovat, dožij si s tím co umíš :) Já ani nevim jestli mám v počítači překladač javy nainstalovanej.

[xkucf03]

Pokud seš tak starej, že píšeš nejradši skripty v javě, k asi nemá cenu tě přesvědčovat…

Ještě jsem zapomněl dodat, že k jejich sestavení/spuštění rád používám Make.

[Erin]

S tímhle musím souhlasit. Klasické UNIXové text-proudově orientované nástroje mě děsivostí v noci připravují o spánek, tak jsem hledala nějaký skriptovací jazyk na takové věci. Python jsem vyloučila protože mi nevyhovuje jako celek. Ruby je hodně (bohužel) orientované vůči Rails a ten ekosystém okolo je takový ne moc živý. I zprovoznit LSP byla ňamka. Lua je moc minimální a víc na embedded (jasně mohu snadno s LuaJIT dělat C interop ale to poté postrádá smysl). A ty ostatní mají ekosystémy ještě méně živé. Možná ještě zvážit Racket, to by šlo, ale tam také mohu narazit na podobné ekosystémní problémy.

Tak jsem nakonec to napsala v Rustu, ve kterém umím. Trocha maker (ty já ráda :D) a jde to poměrně pěkně. Jasně musí se to kompilovat a Rust je znám svými nepříliš krátkými dobami překladu, ale co s tím nadělám, zase taková hrůza to není, zvlášť když je to jednoduchý program a s inkrementálním překladem to jde docela rychle.

Lidi hodně dělají v Pythonu věci, protože Python umí a umí rychle něco naplácat. Pak jsou tu jedinci jako já kteří rádi modelují kód i pomocí typů a rádi nějakou kulturu v kódu. Já i radši strávím hodinku psaním makra v Rustu než 15 minut copy-paste :D

[Michal]

Mno a tu zrusnist s nazvem GIL se jim z cpythonu podari odebrat kdy? Ptam se jen tak ze zvedavosti, jazyk, kde ma odsazeni syntakticky vyznam, budu stejne porad povazovat za vtip

[koroptev]

mne teda vic vadi ochota delat veci typu Python 2 -> Python 3

ten jazyk uz asi ma svoji niku docela pevne obsazenou

[sid]

Inac by ma naozaj zaujimala motivacia tohoti stupidneho napadu a preco dotycny miesto toho neurobil tool na reformat zdrojakov.

[tacoberu]

Protože jsi konzerva

Nestačí jen prohlásit, že je to stupidní nápad. Ale pokud by si to doložil nějakým argumentem, to by bylo jiná.

Formátování odsazováním mi subjektivně přijde čistější, je tam méně balastu. Kromě Pythonu to používá Haskell, Yaml, Neon, CoffeScript, F#, Slim, Idris, Lean. Nevýhoda je v tom, že parser zdrojáků je trochu složitější.

Dá se tedy spekulovat, že důvod, proč se používají semanticky významné odsazování souvisí s vývojem. Máme lepší parsery.

[sid]

Povedal by som, ze dizajn ktory nemoznuje taketo veci je podstatne blbuvzdornejsi a jednoznacny. Tj predstavujem si, ze napr mam definiciu jazyka var a = 223 233. Ked bude jedna medzera bude to oddelovanie v ramci cisla. Ked dve a viac medzier bude to pole. Usetrit dva znaky mi v pripade pythonu pride neatatne. Yaml to skoda menovat. Presne "konfigurak" ktory na "riesi" veci tym, ze dalsich 10 novych vytvori

[tacoberu]

Povedal by som, ze dizajn ktory nemoznuje taketo veci je podstatne blbuvzdornejsi a jednoznacny.

Vidiš to. Já to vnímám naopak. Nikdy jsem neměl třeba v Haskellu problém s tím, že odsazoval. Stejně bych to dělal. A tak skutečnost, že tam není smetí považuji za plus. Pokud něco špatně napsal, tak mě srozumitelně vynadal. V Javě, C#, etc které používají volný styl, tak tam to vždycky řvalo nějaké haluze, a poradil jsem si jen díky tomu, že už prostě mám nějaké zkušenosti. Takže v tom to nebude.

A co třeba skutečnost, že u volného stylu vždycky probíhá řežba, jak se bude kód formátovat. O to jsem v Pythonu ochuzenej (a mohu se soustředit na jiné spory).

(zbytek textu jsem nepochopil, tak jsem to ignoroval)

[sid]

Smeti a java a c# na teba rvalo? To by ma zajimalo seriozne co.

[Erin]

Zrovna u Haskellu mi to odsazování nepřijde zase nějak takové zlé jelikož kód v Haskellu nevyužívá bloků zase tolik jako Python.

Nebo můžeme zrušit nějaké syntaktické věci celkově, mít zdrojáky jen AST a syntaxi si zvolit jakou chceme. Klidně i lokalizovanou :D

[Peter Golis]

Lokalizovaná bola napríklad OSTRAJava, to ten čas letí...

[kutr]

Od verze 3.13 je plánované vydávat i experimentální verzi pythonu bez GILu (viz. info z léta). Plán je se během pár let GILu úplně zbavit, teď se bude hlavně tlačit na knihovny, aby právě testovali tu nogil verzi. V posledních letech se hodně zvýšil tlak na rychlost python interpretru, hlavně kvůli tomu že python je dneska jazyk číslo 1 pro práci s velkými daty. Microsoft dokonce vytáhnul Guida van Rossuma z důchodu, právě kvůli práci na zrychlování pythonu.