Názory k článku Interpretry, překladače, JIT překladače a transpřekladače programovacího jazyka Lua

Uvital bych jeste porovnani v testech a moznostech s Terra (http://terralang.org/ , https://github.com/zdevito/terra), protoze se mi jevi jako aktualne nejlepsi kombinace pro psani vysoceurovnoveho embedded kodu (v Lua) spolu s krasne citelnym a trivialne napojenym vykonnostnim kodem (v Terra, tedy C kod vypadajici jako Lua), ale s cistou rychlosti C (vyuzivajici zejmena moznosti kompilatoru C, tedy predevsim obrovske a perfektni optimalizace).

Ahoj,

zatim s Terra nepracuji v realnych aplikacich, ale v beta pouzitelnem stavu byl Terra jiz pred rokem, takze osobne bych se nebal Terra pouzit jiz i na vetsi aplikace.

Sam pouzivam take LuaJIT - hlavne proto, ze Terra neresi (ani nemuze) Cckove programatorske "chyby", takze se hodi spise pro zkusene programatory, kterych mam okolo sebe po malu :(

Tesim se na nejake porovnani (ocekavam, ze Terra vyhraje v testech na plne care, ale i tak me to zajima).

Luu neznám, ale pokud je kód vzniklí transpřekladem Lua -> C tak pomalí, smrdí to špatným transpřekladačem ...

Nebo kvalitnim interpretrem vedle nehoz ten transprekladac stoji za houby :-)

Neco podobneho jsem zazil s FORTHem kdysi davno = to proste nema smysl prekladat, samotny interpretovany kod (no spis threaded nebo jak se tomu presne rika) je mega rychly

A hezky detailní článek, moc se mi líbil :)

Pro porovnani jsem si zkusil priklad z Mandlebrotem prelozit 1:1 do Common Lispu, a ve vysledku zabiralo polovinu casu tisteni (princ). Tak jsem zkusil v Cckove verzi odstranit printf (s trochou snahy, aby to neodoptimalizovalo cely cyklus), a cas byl kratsi o tretinu.

Ze zvedavosti (Lua nepouzivam) jsem nainstaloval LuaJIT a spustil program s tiskem a bez (a doufam, ze se cyklus neodstranil), a cas je mene nez tretinovy (a plne srovnatelny s Cckovym)

Z cehoz usuzuju ze
a) uloha po trose optimalizace mozna neni az tak narocna na vypocet, a
b) LuaJIT je v optimalizaci vypoctu jeste lepsi nez vychazi v clanku; tisk ma mezery (nebo mozna dela vic nez Cckovy ekvivalent co do ruznych prekladu a podobne).

Z dalsich zajimavosti: vystup Cckoveho a Lua programu se drobne lisi (rika diff), a ani jeden nema bily vnitrek mnoziny v zobrazovacich ktere pouzivam (hodnota 256, ne 255) jako na obrazku v clanku.

Pokud co pisu vypada jako kritika, tak upresnuji ze clanek se mi libil.

Jo, to je jasny ze floaty jsou nepresne - koneckoncu z Lua kodu ani nevidim jake floaty uziva (v CL to ale bylo se single i double zhruba stejne rychle, pouziti complex pro z se nevyplatilo). A ty drobne rozdily v poctu iteraci meritelny vliv na cas mit nebudou.

SBCL by bufferovat melo, ale zkusim zapisovat do stringu a ten pak dat na disk. Predpokladam (v clanku to nevidim) ze casy jsou pri zapisu do souboru (nebo do /dev/null?) - pri vypisu na obrazovku muze byt bottleneck zase nekde jinde.

Spis mi slo o ilustraci toho, ze od nejake chvile benchmarky obcas meri neco jineho (rychlost tisku) nez si myslime ze meri (rychlost operaci s floaty).

K bilemu stredu: taky se da snizit o jednu maxiter. Dokonce to pak asi bude (nemeritelne) rychlejsi.

Imo úplně nejvíc nejlepší věc na luaJIT.

Jen me zarazila jedna vec. Proc LUA muze pouzit na preklad "+" jak "add či fadd" intrukce, kdyz pokud vim nema celociselny typ?
(to me na LUA hodne vadi, stejne jako nesikovne/pomale resene bitove operace pres knihovnu)

Nebo jak tu zminky mam chapat? Ano rozumim tomu ze je mozne pretezovat (metametody) operator a tim definovat "+" treba pro matice a to dost komplikuje preklad do jineho jazyka.

Lua 5.3 uz celociselny typ konecne ma.

A ty bitovy operace uz 5.3 taky ma primo. Takze neni potreba dalsi knihovna...

Muze, LuaJIT to tak dela, kdyz mu je jasne, ze je to treba ridici promenna smycky, ktera jen indexuje pole nebo neco podobneho. Plus jak pise predrecnik, v Lua 5.3 uz inty jsou.

Diky za odpovedi. Konecne je LUA od verze 5.3 pouzitelnejsi. "bitove" operace jsou moc uzitecna vec.