Názory k článku
Python 3.14 bude mít nový interpreter tail-call, je rychlejší o 10-40 %
-
Optimalizace koncové rekurze má svůj smysl, nejde jen o optimalizaci času, ale i o optimalizaci paměti. A tady se snadno můžeme dostat na o stupeň jinou asymptotickou složitost. Což už může být významné, a může to ovlivnit, jak si můžeme dovolit napsat kód. A v tomto mi přijde, že koncová rekurze je často to hlavní, a obecnější optimalizace koncového volání už nepřinese až o tolik navíc.
V tomto případě jsem rychle přečetl popis a přijde mi, že spíše než o optimalizaci koncového volání jde o interpret, který nějak využívá koncového volání.
-
radekmStříbrný podporovatelNa druhé straně člověk ztrácí stack trace, takže ladění je těžší a obvykle tail call trvá déle než normální call, protože se tam nějak manipuluje se zásobníkem (něco jiného je, když se podaří volání funkce úplně odstranit).
-
> člověk ztrácí stack trace, takže ladění je těžší
Jo, to je jedna ze stinných stránek, a tuším i důvod, proč to nedělá automaticky třeba JVM. (Tuším, že byla nějaká iniciativa, která by umožnila označit invoke* instrukce, které lze takto optimalizovat, ale nevím o tom, že by to bylo dokončeno.) A I důvod, proč omezení na rekurzi může být dobrý trade-off.
> obvykle tail call trvá déle než normální call, protože se tam nějak manipuluje se zásobníkem
To by mě zajímalo. Měl jsem za to, že v podstatě místo přidání stack frame se poslední stačí frame přepíše. Jo, bude to vyžadovat nějakou opatrnost – naivně bych prvně nový stack frame vytvořil někde bokem, a pak teprve přepsal starý, protože při tvorbě nového stack frame potřebuju starý. (Představme si situaci, kdy funkce f(a, b) bude volat f(b, a).) Při kompilaci bych čekal, že si s tím poradí optimalizátor, při interpretaci je to trošku otázka, ale nečekal bych, že to bude mít zásadní roli.
-
On sa namiesto call pouzije jmp, takze existujuci stack frame sa zrecykluje (uz sa tam vraciat nebude, vsak to bolo posledne volanie v tele funkcie, aj v pripade a->b a b->a, pokial nemaju funkcie tolko argumentov, ze musia ist na stack) a az niekedy nastane ret, tak sa vrati tam, odkial sa povodne funkcia volala.
-
Ondřej KolínZlatý podporovatel
A patche by mohly přidávat desetinná místa. Prostoru to nabízí dost.
-
Aby sme pri pohlade na nejake cislo vedeli co sa tam vlastne deje bez toho aby sme museli studovat nejaku 'vtipnu' prirucku k verzovaniu. Ustalili sme sa nejakej forme semantickeho verzovania pre 90% projektov: https://semver.org
Nepotrebujeme dalsiu vedecku disciplinu na hlupost akou je vyjadrenie verzie. -
Abys poznal co se tam vlastně děje, tak v každém případě musíš porovnávat dvě verze. Dvě různé hodnoty. Pak je v principu jedno, jestli porovnáváš třeba verzi 134 a 135, nebo 6.12.10 a 6.12.13, nebo 24.04 a 24.10, nebo 3.14159 a 3.141592.
Ve výsledku musíš stejně číst ten verzovací manuál pro každý projekt zvlášť, protože třeba 24.10 verze u Ubuntu znamená něco jiného než u LibreOffice. A 133.1 znamená něco jiného u Firefoxu než 6.12 u jádra (když odhlédneš od velikosti čísel). Aneb, co ti řekne číslo verze 2.11.5 aplikace MyCoolApp jen tak, bez ničeho dalšího?
Navíc, zrovna ten TeX je svým ne-běžným způsobem verzování známý, skoro bych řekl, že je to legenda, která je starší, než mnoho z nás zde.
-
Mimochodem, zrovna linuxové jádro je krásný příklad. Na první pohled to vypadá jako klasický model <major>.<minor>.<fix>, ale v reálu je to <inkrementující se číslo>.<fix>. Z hlediska vývoje jádra odpovídá jádro 6.12.X něčemu jako 3.72.X. Major se mění jen proto, aby minor nebylo moc veliké. Tříčíselné verzování zůstává jen kvůli kompatibilitě.
11. 2. 2025, 11:17 editováno autorem komentáře
-
DannyStříbrný podporovatelNo, kolem toho pred par lety byla zabavna debata, kdys se <fix> priblizilo k 255...
-
To sice vypadá jako zásadní argument, ale není. Pokud někdo verzuje tak, že přidává další a další číslice nějakého iracionálního čísla, de facto jenom vyjadřuje jejich počet. Tzn. namísto v3.14159 bych mohl napsat v6 a bylo by vymalováno. Pořád to je lidsky použitelnější a dává to okamžitou představu a srovnání. Sémantické verzování je IMO nejlepší, ale každé schema, které je vedeno snahou pomoci čtenáři, je lepší než nějaká geekovská hříčka.
-
Pořád to je lidsky použitelnější a dává to okamžitou představu a srovnání.
Jaké srovnání? S čím? Jakou představu mi to dává? O čem? Opět platí, že bez znalosti kontextu je to jen a pouze číslo. Stejně jako použitá délka Pi.
S tím lidsky použitelnější bych i souhlasil, ale to je tak vše, protože jediné kritérium je snadná rozpoznatelnost přírůstků při srovnání dvou čísel verzí. U délky Pi je ta rozpoznatelnost už horší. Zjisti si ale aktuální verzi TeX-u a zjistíš, že jich zase tak moc nebylo. Za celou historii. Ten SW je psaný prostě jinak, než je dnes zvykem.
-
Zrovna TeX je software, který je od verze 3 koncipován tak, že je „tesán do kamene“ a neměnný, s výjimkou (vzácných) bugfixů. Navíc, Knuth oznámil svůj záměr zakončit vývoj TeXu tím, že bude zakonzerovaný tak, jak je, tzn. že z bugů už vlastně budou featury.
Jakmile máte verzi 3.něco, tak máte jistotu, že se to bude chovat v zásadě stejně.
-
nojo a koukam ze je kolem toho je i nejaka podpora https://github.com/python/cpython/pull/125035
