-

21.10.2012 16:50 | deleted | | poslední úprava: 26.10.2021 01:17

-        

Komentáře

[Člověk z Horní Dolní]

Vypadá to zajímavě, tvoje další projekty na githubu taky. Proč se to jmenuje Vortex?

[----]

Protože design není finální a pořád se mění :) Ale po stabilizaci jméno zůstane.

[dumblob]

Moc hezke! Klobouk dolu.

Po prvnich radcich jsem si sice polozil otazku proc vlastni jazyk, kdyz tu mame Dao, ale po dalsich radcich koukam, ze se orientuje predevsim na "deklarativnejsi" zpusob zapisu, coz se mi moc libi (a to i presto, ze samotny Lua nepovazuji za prilis upovidany - zvlast kdyz se pridaji vychytavky jako operatory ++ -- apod., ktere jsou vsak bohuzel neoficialnim rozsirenim ).

[----]

Dao vypadá moc zajímavě, ani jsem o tom nevěděl :) Nicméně mým záměrem je spíš zjistit, co všechno se dá vyždímat z Lua při použití jako intermediate jazyka; Lua opravdu moc "upovídaný" jazyk není, a celkově je to jeden z nejlepších jazyků pro své určení (hlavně s LuaJIT, rychlejší beztypový JIT neznám), jen škoda, že se nedá použít na webu místo JS ..

co se týče "patchování" Lua, to se samozřejmě dá a není to ani takový problém, protože většinou aplikace mají svoji vlastní kopii, nicméně občas je to problém (hlavně když je potřeba podpora LuaJIT, ke kterému těch patchů moc není, portovat se samozřejmě dají, ale kód LuaJIT není zrovna triviální a dá to trochu práce se v tom vyznat). Zrovna v mém herním enginu je LuaJIT potřeba, protože klasický interpret už je moc pomalý (věci jako UI jsou kompletně skriptované)

[dumblob]

...a celkově je to jeden z nejlepších jazyků pro své určení (hlavně s LuaJIT, rychlejší beztypový JIT neznám), jen škoda, že se nedá použít na webu místo JS ..

Ctes primo z me hlavy .

co se týče "patchování" Lua, to se samozřejmě dá a není to ani takový problém, protože většinou aplikace mají svoji vlastní kopii, nicméně občas je to problém (hlavně když je potřeba podpora LuaJIT, ke kterému těch patchů moc není, portovat se samozřejmě dají, ale kód LuaJIT není zrovna triviální a dá to trochu práce se v tom vyznat).

Jo, presne tak s JIT. Proto jsem psal bohuzel .

[----]

Věci, které vyžadují jen patchování lexeru/parseru se dají do LuaJIT portovat snadno, horší je to tam, kde se mění codegen apod .. LuaJIT provádí spoustu optimalizací a hodně věcí se řeší v interních strukturách pomocí unionů a tak, tím pádem kód je sice optimalizovaný a běží rychle, nicméně vyznat se v tom chce trochu cviku :)

[Bystroushaak]

Pěkná práce.

[Bedňa]

Čo ťa zaujalo na Lua, keď som ho porovnal napríklad s JavaSriptom tak je niekoľkonásobne pomalší. Regex je určite zle implementovaný, tam prehráva voči všetkým jazykom, teda okrem Ruby :) Neber to že kritizujem, len sa pýtam prečo.

[----]

Porovnáváš nesrovnatelné, V8 (JIT kompilátor) vs Lua (interpret). LuaJIT poskytuje mnohonásobně vyšší výkon, ale ve shootoutu zařazený není; každopádně rychlostí se často vyrovná Cčku (v některých testech i předčí) Oproti V8 je rychlejší asi o 30% (aspoň co se týče benchmarku Node.JS vs Luvit (http://luvit.io/); celkově je LuaJIT považovaný za nejrychlejší beztypový/dynamický JIT co momentálně existuje). Tady si můžeš porovnat výkonnostní rozdíl Lua VS LuaJIT http://luajit.org/performance_x86.html Kromě toho LuaJIT má nativní C FFI, které umožňuje pracovat s C pamětí, strukturami, používat malloc/free, pracovat s pointery, volat přímo do C knihoven apod., což výkon ještě dále zlepšuje.

Kromě toho je v porovnání s JavaScriptem Lua o dost lepší jazyk, např. používá strong checking oproti JS který používá weak checking, je menší, flexibilnější, má lepší API a míň "wtf" momentů :)

Btw, i přes to, že Lua interpret se zdá v tom benchmarku pomalý, je to stále jeden z nejrychlejších interpretů, rychlejší než cpython například, LuaJIT interpret (bez JIT kompilace) je rychlejší asi 8x. Lua VM byl jeden z prvních rozšířených register-based VM pro programovací jazyky.

[Bedňa]

Dík za obsiahlu odpoveď, tak držím palce a asi sa na Lua/Vortex pozriem.

[Člověk z Horní Dolní]

Celkem se divím, že ještě nikdo nevzal V8 nebo LuaJIT a neportoval to pro Python nebo Ruby (port v tomhle kontextu = použití podobné architektury a optimalizací).

[Radek Miček]

Pro Python je tu PyPy.

port v tomhle kontextu = použití podobné architektury a optimalizací

V8 je tzv. method-based JIT, který je na rozdíl od tracing JITů mnohem složitější, takže se tolik nepoužívá (což je IMO je dobře).

[dumblob]

Rozdil mezi Pythonim VM a Lua VM je enormni, proto neni mozne vzit "backend" a naplacnout na nej napr. Python.

Jinak par pokusu o JIT u pythonu bylo, ale tusim, ze zustal pouze jediny (jiz zmineny PyPy), ktery sice oproti CPython (tzn. referencni implementaci) je v prumeru skoro 5x rychlejsi, ale oproti ostatnim JIT jazykum je to totalni propadak .

Ve skutecnosti je Python totiz tak "dobre" navrzeny, ze jde velice spatne optimalizovat, takze je imho i formalne dokazatelne (vychazejici primo ze specifikace Pythonu - staci si ji poradne procist), ze musi byt zakonite pomalejsi nez ostatni.

[----]

Python je prostě "spustitelný pseudokód" .. není to nijak výjimečně navržený jazyk ani optimalizovatelný .. ale na učení je dobrý :) a na web asi taky

[Miloslav Ponkrác]

Python je dobře optimalizovatelný.

Problém ovšem je, že jeho autor ten jazyk neustále nekompatibilně překopává a nebo ohlašuje, že ho překope.

Takže ve výsledku se vývojem stíhá sotva hloupý interpretr, který nemá ani slušné optimalizace. Pokud nemáte nadbytek času, pak potřebujete nějakou stabilitu jazyka – případně alespoň tušení co se bude měnit v budoucnu a co ne.

To je veškerý důvod, proč Python je tak špatně optimalizovaný. Prostě jakýkoli člověk optimalizátor by musel vést závod s bořitelem jazyka panem Rossumem a spoustu energie by vydal nadarmo a neustále by to překopával.

[dumblob]

Vzhledem k tomu, ze PyPy neni zadny novy projekt a nemaji jeste zcela pokryty Python 2.7 (a ani mit nebudou, protoze sami pisou, ze povazuji 2.7 v danych ohledech "buggy"), lze odvodit, ze s optimalizaci je velky problem zejmena z hlediska porovnani s prinosem JIT u ostatnich jazyku.

[Miloslav Ponkrác]

S optimalizací Pythonu není problém.

Problém je v tom, že je děsně motivující, když optimalizujete něco, co každý den může přestat v jazyce existovat – a nejde o planý strach. Autor Pythonu, Rossum, prostě překopává Python klidně po 17 letech existence nekompatibilně – aniž by to mělo vážný důvod.

Člověk není racionální tvor, člověk je dale více zaávislý na svých pocitech. Doporučuji Vám třeba dělat ve firmě, kde děláte zbytečnou práci, protože jí uděláte, 3/4 zahodí a nechají Vás to předělat. A dělejte v této firmě několik let – uvidíte, že problém nebude technický, ale ve Vaší motivaci.

A tak je to se všemi optimalizacemi. Prostě projekty kolem Pythonu narážejí na to, kdykoli jejich práce může být spláchnuta do WC – a motivace není.

Takže znovu – to, že někdo, jak třeba PyPy nedosáhnul virtuózních výsledků může mít nejen technický problém, ale také motivační.

Abych to demonstroval: Technicky není problém osouložit každou ženu na ulici, ale daleko větší problém budete mít ty ženy namotivovat aby se nechaly. 99 % žen Vám prostě hned nedá (nejste-li výjimečný přitažlivý či bohatý). Přesto z toho nelze činit závěr, že Váš penis má problém trefit se do vagíny, tedy že je zde technický problém.

Stojím si na svém. Python je velmi dobře optimalizovatelný jazyk. Jenom autor Pythonu, Rossum, jakožto velký destroyer tohoto jazyka ho neustále překopává od základů – a to bez vážných důvodů. Takže se na nějaké úsilí kolem optimalizace Pythonu všichni v podstatě vykvákli.

A ti, kteří mají znalosti a zkušenosti a umějí – se realizují v projektech netýkající se low level věcí Pythonu.

Python mění v každé verzi mnoho věcí. Nemá nic stabilního. Jakpak by asi vypadalo JIT u Javy, kdyby jak syntaxe jazyka, tak formát byte-kódu by v každé minor verzi dostával změn. Pak by JVM měla stejně blbou optimalizaci jako u Pythonu.

Dokud autor Pythonu nezastaví svoje debilní překopávání – nikdy nebude Python mít žádný dobře optimalizavaný ani interpretr, ani JIT ani jiný nástroj. Protože se na to každý vybodne. That's all a to je celé jádro pudla.

Mimochodem, to překopávání Pythonu je důvodem. proč jsem se na Python vykvajznul i já.

[frEon]

uz by se rozhodl predelat tu debilni syntax

[Bystroushaak]

Proč?

[frEon]

prijde mi, ze ta syntax ten jazyk hrozne omezuje a svazuje. Napriklad ta omezena parodie na lambdu, jedinej duvod proc do ni nejde zapsat blok kodu je ten, ze v to v ty syntaxy rozumne nejde. Takovejch mist by se naslo vic, jen si vzpomenout...

[pavlix]

Napriklad ta omezena parodie na lambdu, jedinej duvod proc do ni nejde zapsat blok kodu je ten, ze v to v ty syntaxy rozumne nejde.

Tak pokud bys chtěl měnit syntaxi kvůli takovýmto mylným dojmům, tak to mi nepřijde zrovna chytré. Já bych šel přesně opačnou cestou a významové odsazování bych v Pythonu ještě rozšířil.

[frEon]

co je na tom mylnyho?

[pavlix]

Mylný dojem, že významové odsazování brání možnosti navrhnout zápis anonymní funkce.

[Bystroushaak]

Souhlas, jak s prvním bodem, tak s druhým. Osobně mi to přijde jako jedna z největších vychytávek pythonu a je to věc, která mi vadí právě třeba na lue, nebo dalších jazycích s pascal-like syntaxí. Vždy když vidím někde begin či end, tak mi zešedne jeden vous, protože je to zbytečnost, trám který musí všichni překračovat..

[dumblob]

No, zase na druhou stranu v Lua docela casto pouzivam kratke anonymni fce, ktere se casto vejdou na jeden radek, takze tam se ten end hodi. Jinak Lua nema zadnou jinou spojitost s pascal-like syntaxi (nastesti ).

[pavlix]

Lua je v tomhle směru o něco flexibilnější a určitý typ software se vní píše velice hezky. Nelíbily se mi tuším dvě věci. Jedno bylo API pro práci s poli, které byl pro mě až příliš PHPkovsky laxní. Druhé bylo ignorování některých oblastí v knihovnách Lua, především pokud jde o internet a síť.

Ve výsledku mi z toho vyšlo, že je pro mě Lua zajímavý jazyk, leč na většinu věcí, které dělám, zcela nepoužitelný.

[dumblob]

No, Lua totiz pole nema . Vsechno je proste simulovane pres ty univerzalni Lua tables, coz jsou (ac vysoce kvalitni) pouze hash tabulky. Je tam jedna nejasnost, kterou si neumim vysvetlit ani ja (viz. prvni bod v sekci Ugly), takze nevyhody se urcite najdou .

Jinak mas pravdu - zrovna ze sitovani neni v zakladu nic pribaleneho, protoze by to o hodne zvetsilo balicek s Lua (v ramci zachovani multiplatformnosti). Ale externi Lua knihovny jsou samozrejme dostupne, napr. multiplatformni LuaSocket pro TCP/UDP s par nejbeznejsimi aplikacnimi protokoly atd.).

[pavlix]

Lua tables

Vždyť jsem říkal, že je to PHPkovina :).

Ale externi Lua knihovny jsou samozrejme dostupn

Slovo „samozřejmě“ u Lua knihoven zřejmě znamená něco jiného, než si představuju já. Zrovna TCP a UDP jsem ještě nedávno nemohl používat z důvodu omezení na IPv4.

[dumblob]

Zrovna TCP a UDP jsem ještě nedávno nemohl používat z důvodu omezení na IPv4.

Hm, to je zajimave - podival jsem se zrovna na LuaSocket a s IPv6 nema problem (google mi vyplivnul github repo, ale take mi vyplivnul, ze v Debianu to nebylo jeste nedavno z neznameho duvodu zarazeno, takze nevim, zdali jsi nenarazil na omezeni distra).

[pavlix]

Hm, to je zajimave - podival jsem se zrovna na LuaSocket a s IPv6 nema problem (google mi vyplivnul github repo, ale take mi vyplivnul, ze v Debianu to nebylo jeste nedavno z neznameho duvodu zarazeno, takze nevim, zdali jsi nenarazil na omezeni distra).

Vzhledem k tomu, že o tom byla řeč mezi vývojáři Prosody, tak mám za to, že v té době, kdy jsem se o ten jazyk zajímal, tak to bylo absolutní no-go.

[----]

Jen poznámka, Lua pole má, i když jsou integrovaný v tables. Table má tzv. "hash part" a "array part" a "ordered" hodnoty s integrálními indexy se ukládají do té "array" části :) Jediný rozdíl tím pádem je, že jsou asociativní pole a indexovaná pole pod jedním tagem a mohou se libovolně kombinovat.

[Bedňa]

A teraz sa môžeme smiať jazukom čo nepoznajú polia a skutočné premené len sizeof

[pavlix]

a mohou se libovolně kombinovat.

V čemž nespatřuju žádnou výhodu, jen obrovskou dávku prasáctví.

[----]

Má to své použití. Např. ve svém GUI systému mám:

gui.Button {
    signals = {
        clicked = function(btn) print("click") end
    },
    gui.Label {
        text = "Hello world"
    }
}

Při vytváření jednotlivých instancí jsou v hash části "vlastnosti", v array části "děti" toho widgetu, které musí být seřazeny. Toto umožňuje pro tento účel celkem hezkou syntaxi deklarativním způsobem, bez imperativního nastavování vlastností.

[pavlix]

Aha, takže takový jakože javascript, kdy hash table a objekt jedno jsou?

[----]

V Lua jsou objekt, pole a asociativní pole jedna věc. Resp. žádné klasické "objekty" s inheritancí apod nejsou, ani prototypy, nicméně pomocí metatabulek se dají vytvořit objektové systémy různých typů (prototypy, třídy, hybridy, ...), záleží vždy na požadavcích. Celkově pomocí metatabulek se dá udělat spousta věcí.

[pavlix]

V Lua jsou objekt, pole a asociativní pole jedna věc.

Dobře.

Resp. žádné klasické "objekty" s inheritancí apod nejsou, ani prototypy, nicméně pomocí metatabulek se dají vytvořit objektové systémy různých typů (prototypy, třídy, hybridy, ...), záleží vždy na požadavcích.

Zajímavé, už chápu, proč je na to Franta Fuka tak vysazený.

Celkově pomocí metatabulek se dá udělat spousta věcí.

A co to přesně je, to modifikuješ chování těch asociativních polí?

[dumblob]

A co to přesně je, to modifikuješ chování těch asociativních polí?

Chovani asociativnich poli nemenis. Menis pouze obsah a pokud danou hodnotu "zavolas", tak Lua predpoklada, ze se jedna o funkci a pokud ji predavas/kopirujes, tak Lua vidi pouze ciselnou hodnotu (referenci). Je to proste skoro stejne jako JS, ale jeste obecnejsi (zjednodusene receno vsechno muze byt ulozene kdekoliv a spustene odkudkoliv a kymkoliv ).

[pavlix]

Což to může být stejně i v Pythonu, ač má vestavěný objektový model a ten funguje přirozeně (tedy jako třeba v Javě nebo C++, ne jako třeba v C).

[----]

Metatabulka je regulérní tabulka, která se dá přiřadit jakékoliv tabulce (a zpětně později získat). V podstatě definuje chování tabulky při určitých událostech. Ty jsou definovány "metametodami", což jsou vlastně funkce přiřazené určitým klíčům v metatabulce. Např. metamethoda __add definuje, co se stane při součtu tabulky s něčím. Metamethoda __index definuje co se stane, když se pokusím získat z tabulky nějaký prvek. Metametoda __newindex specifikuje, co se stane při prvním vytvoření nějakého prvku tabulky. Většinou jsou to vše funkce, nicméně __index může být i tabulka, v takovém případě určuje tabulku, odkud se budou zjišťovat prvky.

Příklady:

foo = {} -- tabulka
setmetatable(foo, { __add = function(a, b) print("adding a + b", a, b); return "hello world" end }
print(foo + 150) -- zavolá se __add, a bude foo, b bude 150, vrací "hello world"
print(150 + foo) -- pořadí a, b bude přehozeno

getmetatable(foo).__index = function(self, name) return name end
print(foo.bar) -- vypíše "bar"
print(foo.blablah) -- vypíše "blablah"

getmetatable(foo).__index = { xyz = "hello" }
print(foo.xyz) -- vypíše "hello"

getmetatable(foo).__newindex = function(self, name, value) _G[name] = value end -- _G je tabulka globálních proměnných
foo.abc = 150
print(abc) -- vypíše 150, nová globální proměnná

Co se týče _G, to je tabulka, která obsahuje všechny globální hodnoty, a vzhledem k tomu, že je to normální tabulka, může mít také svoji metatabulku a tím se dá ovlivnit, co se vrací a co se přiřazuje při manipulaci s globálními proměnnými. Tím se dá např. implementovat ekvivalent Perlího "strict" módu na pár řádcích (takový modul je i ve výchozí distribuci Lua)

Měl bych říct, že všechny tagy v Lua mohou mít metatabulku - tabulky, čísla, userdata (uživatelské pointery definované z C), stringy, thready (fibers/korutiny) nicméně jen v případě tabulek má každá svoji vlastní metatabulku (resp. může mít), v případě ostatních tagů je jedna globální. To se hodí na další rozšiřování. Např. toto:

getmetatable("").__mod = function(str, args)
    return (str:gsub("%%%(([a-zA-Z_0-9]*)%)([-0-9%.]*[cdeEfgGiouxXsq])",
        function(k, fmt)
            k = tonumber(k) or k
            return (args[k]
                and ("%" .. fmt):format(args[k])
                or "%(" .. k .. ")" .. fmt)
        end))
end

vlastně povolí takové trochu pythonoidní formátování stringů včetně pojmenovaných argumentů a neseřazených argumentů pomocí overloadu modulo operátoru, "args" poslaný metametodě __mod bude v tomto případě ta tabulka { foo = ....... }:

("hello %(foo)s %(2)i %(1)f") % { foo = "world", 3.14, 5 } -- takový string bude "hello world 5 3.14"

Namísto obyčejného

("hello %s %i %f"):format("world", 5, 3.14)

(ta syntax s :format je povolena, protože výchozí __index stringí metatabulky je knihovna "string", tudíž str:format(args) je ekvivalentní s string.format(str, args))

[pavlix]

Metatable v tomhle případě vypadá jako pythoní __dict__, až na to, že Python ještě u instancí automaticky při neúspěchu hledá ve třídě a navíc tam jsou možné nějaké optimalizace.

[----]

Ne, __dict__ je pouze ekvivalent metatablího __index v případě, že je to jiná tabulka. Metatables jsou určeny k rozšiřování sémantiky.

[dumblob]

Jen poznámka, Lua pole má, i když jsou integrovaný v tables...

Ano, ale pro uzivatele se to snazi syntaxe skryt, proto jsem napsal, ze pole nema, protoze Lua jako jazyk je nema . Implementace je samozrejme neco jineho.

[----]

Jo, to je taková love/hate věc .. mě osobně se to tak líbí, protože mít jeden tag pro všechny tyto věci hodně zjednodušuje jazyk samotný a navíc přidává další flexibilitu :)

[pavlix]

Mno flexibilita mi přijde úplně ale 100% stejná jako pokud by tam tato vlastnost nebyla (protože vždy můžu pole vložit explicitně). Jednoduchost, no dejme tomu, že má Lua jednodušší model než třeba Python, to každopádně. Ovšem u programovacích jazyků jednoduchost jazyka samotného zpravidla znamená, že se musíš víc naučit, pokud ho chceš použít (viz jednoduché C versus podstatně složitější Python).

Tady bych viděl asi touhu po zachování maximální flexibility, tedy víceméně srovnatelné s Pythonem (potom, co do něj byla chybějící flexibilita dolepena, ale na to je potřeba znát docela dost), možná o kousek větší (zvlášť pokud jde o syntaxi), za maximální jednoduchosti jazyka samotného.

No musím říct, že ty koncepty na kterých Lua stojí jsou pro mě trochu nezvyk :).

[----]

Tables nejsou nic bez metatables, což je jeden z hlavních konceptů, na kterých ten jazyk stojí; vlastně cílem Lua je co nejmenší jazyk, který definuje set technik, pomocí kterých si můžeš naimplementovat paradigma a použít jak je třeba (např. pro funkcionální techniky Lua poskytuje first class funkce, pro objektově orientované programování metatabulky apod.) a přitom neztratit nic z komfortu a celkové použitelnosti. Kompletní referenční interpret Lua se vleze do 300 kB a běží na jakékoliv platformě, kde je dostupný ANSI C kompilátor a knihovna - nic jiného není potřeba (jazyk umí využít rozšíření jako dlopen, ale to jsou všechno nepovinné části a většinou nepotřebné, pokud se dělá statický build zabudovaný napevno do programu). Kromě toho má perfektní API pomocí kterého se dá přistupovat k jazyku z C velice jednoduše (zabudovatelnost je jedním z cílů jazyka, oproti třeba tomu Pythonu) a pomocí metatables a environments se dá sandboxovat přímo z jazyka.

[pavlix]

Jojo, já jsem viděl ukázky právě těch appletů do hodinek od Franty Fuky, ale při přednášce nezkoumáš paradigmata, žejo :).

[dumblob]

Mne osobne se to take ze stejneho duvodu libi .

[Radek Miček]

Ve skutecnosti je Python totiz tak "dobre" navrzeny, ze jde velice spatne optimalizovat, takze je imho i formalne dokazatelne (vychazejici primo ze specifikace Pythonu - staci si ji poradne procist), ze musi byt zakonite pomalejsi nez ostatni.

A jak by se to formálně dokazovalo?

[Miloslav Ponkrác]

To by mě také zajímalo, hlásím se jako divák na předvedení toho formálního důkazu.

[dumblob]

Protoze se rad ztrapnuji, tak abych nevysel ze cviku, prohlasim, ze na procteni, formalizaci a nakonec vymysleni dukazu pro specifikaci Pythonu a napr. Lua nyni opravdu nemam cas. Ale beru to jako zajimavou challenge do budoucna (pouze v pripade, ze Python nezemre diky autorovi ).

Predstavu mam takovou, ze by stacilo vytvorit specificky assembler spolecny pro oba porovnavane jazyky (Python a napr. Lua) a pote porovnat vsechny high-level operace prevedene do assembleru (kazda instrukce asm by byla ohodnocena "nejak" - zrejme empiricky - a cim mensi soucet techto vah by jednotlive operace mely, tim by byl jazyk rychlejsi).

Problem je, ze takovych high-level operaci je mnoho (musela by se vzit cely semanticky analyzator a z neho to vydolovat a pripadne chybejici high-level operace vzdy do druheho jazyka co nejefektivneji primo v tom jazyku dopsat tak, aby vykazovaly stejne chovani). Napr. takove dedeni je v Pythonu zadratovane, kdezto v Lua bych ho musel nasimulovat atd.

[Miloslav Ponkrác]

Zřejmě nechápete oc je to optimalizace.

Optimalizace není převedení 1:1 všech konstrukcí jazyka do nějakého cílového jazyka.

Optimalizace je mnohostupňový proces pracující na řadě úrovní a v mnoha stupních. Pro představu, v dobrém kompilátoru C/C++ nebo v dobrém JIT virtuálním stroji je klidně 99 % všeho kódu – i více – optimalizace.

Optimalizace v podstatě zahrnuje každý krok zpracování od syntaktického stromu až po finální stroják.

Na optimalizaci nepotřebujete jednotnost nějakého meziassembleru. On se dá Python třeba i zkompilovat do přímo do strojáku, kdyby na to někdo napsal nástroj. Stejně jako Lua. Stejně tak se dá interpretovat nebo interpretovat s JITem.

Kromě toho formální důkaz neznamená, že stlučete na koleně Vy nebo nějaká skupina nějaký interpretr, nebo dva interpretry či virtuální mašiny a podle toho jak to dopadlo, že je důkaz něčeho. Oni ti autoři internetu taky můžou být nešikovní a leví jako šavle nebo jen zasednutí na nějaký jazyk – a výsledek je hned jinak.

Formální důkaz znamená matematický důkaz provedený podle pravidel formá logiky a logiky matematických důkazů. To je to co se nazývá formálním důkazem. Cokoli jiného jsou jenom kecy.

[dumblob]

Zrejme si nerozumime. Mel jsem zrejme ten "assembler" napsat do uvozovek a misto toho uvest atomy, ktere lze "optimalizovat". Bavime se zde tedy o formalnim dukazu operaci nutnych provest pro jistou operaci (tzn. algoritmus). Jelikoz dana ekvivalentni operace zahrnuje u kazdeho jazyka jiny algoritmus (tzn. sled atomu), tak me prave napadla metoda ohodnoceni jednotlivych atomu (instrukci).

Pochopitelne timto mohu formalne dokazat pouze podmnozinu (strelim od boku, ze to je tak 95%) vsech moznych optimalizaci. Zbylych 5% se tyka oblasti jako lazy evaluation a podobnych pokrocilych technik, ktere u Pythonu imho nenajdou prilis velke uplatneni kvuli objektovemu navrhu (ten objekt se musi vytvorit, protoze se vzdy pristupuje alespon k jednomu atributu/metode apod.). Abych mohl provest skutecne uplny dukaz (tzn. obsahujici i zbylych 5%), musel bych zahrnout i operace vyuzivajici vsech existujicich optimalizacnich technik (a to na vsech urovnich - od syntakticke analyzy az po generovani kodu), pouzitelnych pro alespon jeden z porovnavanych jazyku, coz povazuji za casove neproveditelne.

Vyse uvedene znamena, ze formalni dukaz lze provest, avsak bylo by to prilis narocne. Proto bych se spokojil s castecnym "dukazem" tech 95%, jehoz vysledek si troufam predem odhadnout jako jedna:nula pro Lua.

[Miloslav Ponkrác]

Jenže takovýto test neříká fakticky nic o optimalizovatelnosti jazyků.

Pouze se budeme bavit o návrhu vhodných „atomů“, tedy vhodného mezijazyka, pro projekt nějaké VM, který by jednotně byl schopen (po překladu) vykonávat programy pocházející ze dvou jazyků.

A ano, objekty není nutné vždy vytvořit ani v Pythonu. Mnohde je možné optimalizací spoustu akcí, tedy i vytvoření objektu, vyhodit. Záleží na schopnosti optimalizátoru Pythonem -> mezijazyk. Ve své podstatě jsou pythonovské objekty pouze hašovacími tabulkami, které mapují řetězec -> hodnota.

Akce s pythonovskými objekty lze implementovat (protože tak fungují) jako akce nad hašovacími tabulkami (a zapomenout dále na objekty v implementaci). Akce nad hašovacími tabulkami lze dále optimalizovat a redukovat.

V zásadě není důvod, proč by Python měl být lépe optimalizovatelný oproti Lue. Tipnul bych si, že kdyby šlo do tuhého, tak Lua to v optimalizovatelnosti prohraje jako ten horší z dvojice. Pro jistotu dodávám, že jsem spíše kritikem Pythonu, takže se těžko ode mě dá očekávat, že bych chtěl na Luu plivat.

Optimalizovatelnost je v zásadě dána pouze množstvím informací, které programátor vkládá (vědomky/nevědomky/či je dokonce donucen, přímo/nepřímo) do zdrojového kódu. A dále prostorem, nad kterému dovolíte optimalizátoru operovat – optimalizace modulů bude vždy méně efektivní, než optimalizace skupiny modulů a ještě lepší bude optimalizace programu jako celku. Cokoli jiného moc ve schopnosti optimalizovatelnosti nehraje roli.

Právě předchozí odstavec přesně vysvětluje, proč elegantní jazyky, které udělají spoustu práce za programátora se nikdy v praxi nepodařilo optimalizátorem dotáhnout do potřebné rychlosti – protože programátor houpal nohama a nedodal potřebné penzum informací a dobrou optimalizaci (ani dobrou kontrolu chyb) pak nejde provést na maximum.

Právě proto existují ty „ošklivé a hnusné“, „neelegantní“ jazyky, jako je assembler, C, C++ a další – protože když jde do tuhého, jejich optimalizace je excelentní.

Některé jazyky to dělají trochu jako Kalousek a svou neoptimalitu maskují velkým prožíráním zdrojů. Taková Java je schopná se v rychlosti v určitých případech rychlosti C/C++, ale pouze za cenu velké spotřeby paměti, která je mnohonásobkem toho, co sežere stejný program v C/C++, který je stejně navíc skoro vždy ještě o chloupek rychlejší (pomalejší není nikdy, pokud ano, pak programátor neumí).

Jinak řečeno, hledat schopnost optimalizace nějakým hledáním atomů (což můžete vymyslet miliardkrát jinak a pokaždé vyjde jiný výsledek) nevede k ničemu. Optimalizovatelnost je dána pouze a jedině množstvím informací, které má optimalizátor k dispozici (syntaxe jazyka, nějaké atomy, to je vedlejší).

Můj odhad je, že Python by šlo zoptimalizovat o kapičku lépe (ne o mnoho) než Luu. Kdyby se do toho někdo pustil a hodlal dobrý optimalizátor pro Python napsat. A kdyby nějak překousl, že mu to Rossum bude bořit. Možná až umře/zastřelí Rossuma, vznikne vynikající optimalizátor pro Python. Momentálně je to tak, že se o efektivitu běhu Pythonu nikdo nestará a Rossum to maskuje tím, že nazývá Python „glue language“, tedy že vše podstatné se stejně napíše v C a používá se to z Pythonu.

[dumblob]

Dovolil bych si nesouhlasit, ze fce zavislosti miry optimalizace na "semanticke vyrecnosti jazyka" je neklesajici. Jak sam uvadite, C versus Java je toho ukazkou (kdyz pomineme, ze JVM je napsane v C), protoze Lua je prave postavena pouze na hash tables, kdezto Python struktury by se do nich teprve musely prevadet az v ramci optimalizaci.

Lua je jakoby vice "low-level" s tim, ze syntaxe je priblizne stejne usporna, citelna a jasna jako Python. Programator ma tedy moznost stejne jako u analogie C-versus-Java v Lua psat rychlejsi kod (C) nez v Pythonu (Java), avsak se stejnym usilim.

Proto bych tu zavislost videl spise jako Gaussovu krivku - nejprve se z extremniho low-level kodu (napr. assembler) dostaneme pres C, Javu/Python/Lua/atd. az k Haskellu, pricemz kompilator C bude schopen diky lidskym moznostem vygenerovat lepsi kod nez by napsal clovek v ASM (protoze clovek neni schopen udrzet tolik informaci v hlave, aby mohl tak dobre optimalizovat; teoreticky to je ovsem naopak), kdezto u Haskellu je to jiz tak vysoka vrstva, ze ani kompilator to nezvlada a lidske mysleni je jiz zase lepsi v tom "prohledavani stavoveho prostoru" a prekonava ty optimalizace (clovek to "natipuje", ale mnohem lepe nez masina - proste lidsky nedeterminismus/stochasticita tady krasne funguje).

Pokud se budeme pohybovat na formalni urovni, zajima nas pouze samotny algoritmus (tzn. ne moduly apod. - ty budou ve finalni forme v podobe atomu "zapomenute", protoze se bude jednat o obycejnou posloupnost "instrukci") a pak jeho prevod skrze dany jazyk spolu s optimalizacemi do "instrukci" Turingova stroje.

Proto jsem navrhoval atomy, ktere by byly "vyssi" nez "instrukce" pro Turinguv stroj a pritom neomezovaly ani jednu z pouzitych optimalizaci (tzn. jednalo by se zrejme o naprosto zakladni instrukce pro naivni akumulatorovy CPU).

[br]

Tohle moc nesedí. Třeba zrovna Haskell moc výkonnostními problémy netrpí. Je sice pravda, že Lua je hodně jednoduchý jazyk optimalizovaný na rychlý překlad, ale ve studiích o virtuálních strojích se obvykle uvádí, že největší propad výkonu je způsoben load/store operacemi (načítání instrukcí, ukládání výsledků) a branch misprediction (dnešní procesory mají víc než 30 instrukcí pipeline a tohle všechno se musí zahodit, při špatném rozhodnutí). Load/store operace se snaží Lua eliminovat použitím registrového stroje. V případě brach mispredictions je na tom zase zásobníkový VM o něco lépe, takže ve výsledku se teoreticky ty dva jazyky budou lišit pouze v rychlosti samotné kompilace a python bude trochu ztrácet kvůli více dynamickému systému. Nakonec ale stejně všechny VM selžou na tom, že dnešní procesory jsou optimalizované na C a až tak moc nezáleží na tom jestli ten kód vytvořil překladač nebo člověk.

[Miloslav Ponkrác]

Já píši o „optimalizaci“, ne o „výkonnostních problémech“. Rozdíl mezi těmito dvěma termíny je myslím dost cítit.

A ani Haskell se rychlostí nedokáže vyrovnat jazykům typu C/C++.

Haskell je zrovna krásný příklad, jeho zdrojový kód dodává mnohem více informací, než je u jiných funkcionálních jazyků běžné. Například informaci o typech a další – a proto má lepší předpoklady k optimalizaci.

Je úplně u zadnice, jestli máte registrový nebo zásobníkový VM stroj, pokud se budeme bavit o možnosti optimalizací. Pokud si zvolíte „meziassembler“, pak máte do toho vnesenu cestu zdrojový kód -> meziassembler -> cílový kód. Takováto striktní cesta nemusí vést k nejlepší optimalizaci, protože do toho vnášíte umělá omezení daná chytrostí vámi vymešleného meziassembleru.

Je jenom Vaše rozhodnutí, že se rozhodnete optimalizaci rozdělit uměle na 2 části. Tvrdým zvolením byte–kódu a jasným rozdělením procesou kompilace a optimalizace ne dvě části ztrácíte část informací, ergo hůře optimalizujete. Proto nikdy VM s byte-kódem nebude tak dobře optimalizovat jako čistý kompilátor ze zdroje do cíle.

Proto jakékoli napevno zvolené byte-kody nevedou k nejlepší možné optimalizaci. Třeba clang nikdy nebude nejoptimálnějším kompilátorem C/C++ – a podle mého se z tohoto důvodu časem opustí.

Já klidně mohu udělat interpretaci Luy jiným byte-kódem, než je momentálně oficiální binární mezikód, a možná bude i rychlejší.

A existuje tisíce možností, jak zvolit byte-kód, nejenom čistě registrový a čistě zásobníkový.

[br]

Já píši o „optimalizaci“, ne o „výkonnostních problémech“. Rozdíl mezi těmito dvěma termíny je myslím dost cítit.

Ano optimalizace bez toho abych věděl, kde je problém je hádání. Ví se o tom už od 70. let, kdy vznikla slavná věta o předčasné optimalizaci.

Haskell je zrovna krásný příklad, jeho zdrojový kód dodává mnohem více informací, než je u jiných funkcionálních jazyků běžné. Například informaci o typech a další – a proto má lepší předpoklady k optimalizaci.

Tohle je pravda, jenže využití těchto informací při překladu je pořád v plenkách. Třeba funkcionální jazyky by se teoreticky daly paralelizovat na úrovni překladače, jenže na internetu se o tom skoro nic nedá najít a nejspíš se tím ani nikdo moc nezabývá.

Pokud si zvolíte „meziassembler“, pak máte do toho vnesenu cestu zdrojový kód -> meziassembler -> cílový kód. Takováto striktní cesta nemusí vést k nejlepší optimalizaci, protože do toho vnášíte umělá omezení daná chytrostí vámi vymešleného meziassembleru.

Jenom škoda, že tohle dělají snad všechny dnešní překladače snad všech jazyků. Tohle je totiž dost rozumný způsob oddělení jednotlivých částí překladače.

[Miloslav Ponkrác]

„Ano optimalizace bez toho abych věděl, kde je problém je hádání. Ví se o tom už od 70. let, kdy vznikla slavná věta o předčasné optimalizaci.“

Problém je, že neřešíme žádnou konkrétní optimalizaci (na kterou platí ona slavná věta o premature optimization), ale bavíme se pouze v obecné rovině.

---

„Tohle je pravda, jenže využití těchto informací při překladu je pořád v plenkách. Třeba funkcionální jazyky by se teoreticky daly paralelizovat na úrovni překladače, jenže na internetu se o tom skoro nic nedá najít a nejspíš se tím ani nikdo moc nezabývá.“

Problém je, že koncepty programovacích jazyků se řeší stejně blbě jako Kalousek státní rozpočet.

Wáááááuuuuuu, objevili jsme objektové programování – to je všelék a všechno ostatní je špatně! Kod řekne něco jiného, toho upálíme, nebo alespoň znemožníme jako idiota!

Wáááááááááuuuu, objevili jsme funkcionální programování – to je všelék na paralelizaci (zbytek stejný jako konec předchozího odstavce).

Něco vám řeknu, posledních 10–15 let veškeré tendence v programovacích jazycích trpí tím, že se soustředí na jednu věc z mnoha a tu kultivuje, zatímco celý jazyk začne být k ničemu a ne dvě věci.

Před 20 lety jsem se setkával s nádhernými programovacími jazyky pro realtimové programování. Měly vyřešenu paralelizaci na mnoha úrovních, většinou programátor do toho ani nemusel zasahovat, nebo jen mírně.

Dnešní funkcionální jazyky se snaží paralelizaci vyřešit předstíráním, že stačí vykastrovat programátora tak, že mu nebude dána jiná možnost, než psát drsně (storjově snadno) paralelizovatelné věci. Pokud bude chtít psát jinak, tak se mu funkcionální jazyk bude snažit jeho snahu znechutit otrávit.

Vůbec „zdokonalování“ programovacích jazyků probíhá stylem, že programátora je třeba vykastrovat. Kolik nářků jsem slyšel na to, že jazyk A je špatný, protože DOVOLÍ (taková drzost!!!) udělat preogramátorovi něco, co autor kritiky považoval za špatné. Z tohoto důvodu se často vynáčí do nebes Java, protože je ten jazyk dostatečně blbý a okleštěný, aby tyto druhy kritiky nepřitáhl.

Paralelizace tak, jak si představují dnešní funkcionální jazyky je blbost a IMHO se to časem ukáže jako slepá cesta.

Vůbec si myslím, že historie z dneška dostane poučení že toto jsou slepé cesty: 1) oklesťování jazyků, 2) jednoduchá dědičnost, 3) dnešní pojetí funkcionálních jazyků.

---

Raději končím, už jsem silně off topic.

[:::]

Cim vic informaci ma optimalizator k dispozici, tim lip dokaze optimalizaovat. Tohle JE neklesajici funkce.

ASM neni dobry priklad protoze program v asm prave obsahuje velice malo informaci - je tam sice posloupnost elementarnich operaci ale kdyz optimalizator nevi co presne se tema operacema snazis dosahnout, tak nemuze zjistit jestli zmena neporusi nejakou podstatnou vlastnost algoritmu.

[Miloslav Ponkrác]

Asm je velmi dobrý příklad optimalizace. Protože optimalizace je provedena „v lidském mozku“ s použitím 100 % informací, které člověk o daném programů má a o dané cílové architektuře.

Do žádného programovacího jazyka nenapíšete skutečný algoritmus. Pouze to co chcete udělat přepíšete do příkazů daného jazyka – ale tím už se mnoho informací o algoritmu ztrácí.

Příklad: Zkuste třeba ze zdrojáku v C vymyslet SIMD instrukce. Ve zdrojáku není dostatek informací na paralelní algoritmy, protože programátor svůj „myšlený algoritmus“ přepsal do jazyka C, který ho nutí sekvencovat a „ponížit se“ na možnosti C příkazů. Pokud má procesor možnost paralelního provádění instrukcí, informace o skutečném algoritmu v C zdrojáku není, a kompilátor to prostě skoro nikdy nevymyslí. Ačkoli třeba byl zapsán dokonale paralelizovatlený algoritmus do C.

[:::]

Asm je velmi dobrý příklad optimalizace. Protože optimalizace je provedena „v lidském mozku“ s použitím 100 % informací, které člověk o daném programů má a o dané cílové architektuře.

z toho vlakna jsem mel pocit ze se nebavime o puvodnim autorovi, ktery samozrejme ma vsechny informace at uz pise v asm nebo ne, ale o automatu ktery dostane program a ma za ukol ho zrychlit... (bez komentaru protoze tam by se pouzival nejaky dalsi jazyk)

a v samotnym asm kodu proste ty informace o umyslech autora nejsou.

A i kdyby tam misto automatu byl hodne inteligentni clovek, tak kdyz dostane jenom asm kod tak muze jenom ***hadat*** jestli nejakou zmenou nezrusi nejakou pozadovanou vlastnost...

[Miloslav Ponkrác]

Mám spíše pocit, že celý vývoj programovacích jazyků postupuje stylem, že někde na začátku je stroják – a veškerá snaha je přesunout co nejvíce optimalizací v lidském mozku do kompilátoru/interpretu nebo jiného zpracovatele programovacího jazyka, kde stejně na konci je ten stroják.

Asm je první krok evoluce, který většinu nechává na člověku, ale některé věci už dělá místo něho.

Programovací jazyky se liší jen tím, kolik % optimalizuje člověk a kolik % jazyk.

Ve skutečnosti je to celé hloupé, protože nikomu se ještě nepovedlo – a je otázka, zda se o to také někdo kdy pokoušel – vytvořit jazyk, který by dostával od člověka postatně více informací a také ho podstatně méně zatěžoval.

Dnešní programovací jazyky josu jen evolucí stroják -> assembler -> fortran -> postupně všechny programovací jazyky.

Ve všech progrmaovacích jazycích je vidět snaha efektivně vykonávat soubor příkazů, nikoli snaha zapsat o co člověku jde a poradit s tím aspoň z pár % sám.

Jako největší skok v evoluci vidím koncept statických datových typů, což byl velmi geniální nápad. Přesto ho řada jazyků nenávidí – Lua i Python rovněž, ale beru to jako krok zpět, pokud na této úrovni jazyk nedokáže proacovat.

[dumblob]

Ve všech progrmaovacích jazycích je vidět snaha efektivně vykonávat soubor příkazů,

Tohle se snad snazi resit deklarativni jazyky jako Vortex, Prolog, Eiffel, Haskell atd.

nikoli snaha zapsat o co člověku jde a poradit s tím aspoň z pár % sám.

Tim bychom vytvorili nedeterministicky jazyk, coz je obecne povazovano za nepouzitelny zpusob tvorby a zapisu algoritmu.

[:::]

Ve všech progrmaovacích jazycích je vidět snaha efektivně vykonávat soubor příkazů, nikoli snaha zapsat o co člověku jde

jo, to je pravda, ale obavam se ze reseni tohodle problemu bude vyzadovat strong AI

[Miloslav Ponkrác]

„Jak sam uvadite, C versus Java je toho ukazkou (kdyz pomineme, ze JVM je napsane v C), protoze Lua je prave postavena pouze na hash tables, kdezto Python struktury by se do nich teprve musely prevadet az v ramci optimalizaci.“

Celý Python je postaven na hašovacích tabulkách. V jeho základních datových typech je i hašovací tabulka. Veškeré proměnné i podprogramy hledá pomocí názvů v hašovacích tabulkách rovněž.

Naopak Lua má při optimalizaci nevýhodu mála informací, které optimalizátoru dává.

---

„Lua je jakoby vice "low-level" s tim, ze syntaxe je priblizne stejne usporna, citelna a jasna jako Python.“

Lua je jazyk, jehož hlavní snahou je udělat malý interpretr, který nacpete i do embedded procesorů.

V optimalizaci nejde o syntaxi jazyka, pouze o množství informací, které optimalizátor dostane. Všechno ostatní je buřt.

---

„Proto jsem navrhoval atomy, ktere by byly "vyssi" nez "instrukce" pro Turinguv stroj a pritom neomezovaly ani jednu z pouzitych optimalizaci (tzn. jednalo by se zrejme o naprosto zakladni instrukce pro naivni akumulatorovy CPU).“

Jenže máte problém. Problém pochopíte z toho, když ve skupině lidí budete hrát tichou poštu.

Už „úmysl programátora“ nejde do počítače zapsat. Neexistuje žádný jazyk, který by nezničil většinu informací o úmyslu programátora, existují pouze jazyka, do kterých programátor může přepsat postup jeho příkazy. Programovací jazyk už teď netuší o úmyslech programátora skoro nic, jen otrocky zná seznam příkazů, které na konci vygenerují to co programátor chtěl. Jazyk ani zdrojový kód netuší proč, ani zda je to dobrý či efektivní postup.

Pokud nezvolíte skutečně efektivní „atomy“, které musí být plnou nadmnožinou „základních jednotek programovacího jazyka“, tak i „cílového strojáku“ (vidíte! optimalita atomů závisí na obou stranách – i na cílovém stroji!) – tak znovu v mezikódu atomů ztrácíte informace, ergo ničíte možnosti optimalizace a je to horší.

Jinak řečeno, informace pro optimalizátor musí zahrnovat jak znalost zdrojového kódu, tak znalost cílového strojáku. Když to někde přehradíte, třeba mezikódem s vašimi atomy, pak ztrácíte informace, a tedy nedobře optimalizujete.

Taková Lua, nebo clang si toto dělá, protože ztráta optimalizace je daní za jednodušší implementace – ale skutečně jazyk už nebude tak rychlý, jak by mohl být.

[dumblob]

V optimalizaci nejde o syntaxi jazyka, pouze o množství informací, které optimalizátor dostane. Všechno ostatní je buřt.

Syntaxe reflektuje moznosti jazyka a tudiz i ;moznosti optimalizace, proto jsem ji uvadel.

Jinak řečeno, informace pro optimalizátor musí zahrnovat jak znalost zdrojového kódu, tak znalost cílového strojáku. Když to někde přehradíte, třeba mezikódem s vašimi atomy, pak ztrácíte informace, a tedy nedobře optimalizujete.

Ano, mate pravdu - samozrejme jsem temi atomy mel na mysli uzly grafu, kde kazdy uzel by byl spolecny pro vsechny grafy, pricemz kazdy graf by nesl jinou semantickou informaci - to vse pro ruzne typy optimalizaci. Trirozmerny prostor pro kazdy graf by na tohle mel bohate stacit. Tzn. nakonec by stacilo porovnat vysledne grafy z obou kompilatoru porovnavanych jazyku (coz je prave ten formalni dukaz, ktery by byl netrivialni). Vychazel bych ale z predstavy prave napr. toho jednoducheho procesoru, kde veskere vyssi informace by byly zachycene prave v tech "semantickych" grafech. Proto se vami zminene "prehrazeni" nekona.

To, ze by se dala postavit HW architektura (a urcite takove existuji i pripade Python-versus-Lua), na ktere pobezi rychleji jazyk, ktery by formalne byl pomalejsi nehraje roli (na lispovskem CPU take nebudeme spoustet JVM).

Jinak obecne informace, kterych Python dostane je vice (netroufnu si tipnout o kolik, a tak to nechme stranou), avsak s vice informacemi roste komplexnost optimalizaci a diky prekryvani ruznych oblasti optimalizaci musi kompilator optimalizacim davat prioritu v zavislosti na kontextu - a jelikoz jak jste napsal, zna dobre kontext pouze samotny programator, nemuze nikdy strojovy optimalizator tak dobre optimalizovat jako clovek.

Proto bych si netroufnul rict, ze cim vice informaci kompilator ma, tim to je lepsi - to je pouze teorie, ale ve skutecnosti diky prekryvani se musi vybrat pouze podmnozina vzajemne kompatibilnich optimalizaci pro dany kus kodu (resp. souvisejici cast z tech "semantickych" grafu), coz v ASM a "jednodussich" jazycich jako Lua trochu odpada (oproti Pythonu). Proto jsem navrhoval Gaussovu krivku s velkou sigmou, kde ta komplexnost/semanticka_vyrazovost jazyka je ve vysledku kontraproduktivni ve srovnani s  necim jednodussim (ale ne prilis jednoduchym). Python by byl jiz vetsi nez stredni hodnota, kdezto Lua mensi - prave tohle by se muselo dokazat.