Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Coati 21. 12. 2022, 18:24:31
-
Může někdo vysvětlit, jak autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem u tohoto jazyka? Intuitivně bych u dynamického jazyka čekal určitou režii (za dynamické typování a vysokoúrovňové abstrakce).
-
zrovna scheme není zrovna nějak složitý a nebo velmi vysokourovnovy jazyk :D Podívej se na revised 6 /7 scheme report.
-
zrovna scheme není zrovna nějak složitý a nebo velmi vysokourovnovy jazyk
Proč je teda rychlý jen Chez (a svého času Stalin)? Tam zjevně směřovala otázka, že je Scheme poměrně jednoduchý se obecně ví.
-
Chez Scheme kompiluje do nativního kódu, ale just-in-time a díky typové inferenci se té dynamicity může zbavit. A někdy tato strategie vyústi v rychlejší program než C nebo Rust protože je k dispozici více kontextu, ale to se nestává příliš často.
-
Chez Scheme kompiluje do nativního kódu, ale just-in-time a díky typové inferenci se té dynamicity může zbavit. A někdy tato strategie vyústi v rychlejší program než C nebo Rust protože je k dispozici více kontextu, ale to se nestává příliš často.
Ano, tohle je správná odpověď. Navíc pokud se například generuje kód ve Scheme z nějakého typovaného jazyka a ví se tedy, že typy jsou na 100% správně, jde typová kontrola za běhu explicitně vypnout.
-
Zkusím trochu střelby od pasu.
Otázka je, co přesně znamená „dosahují rychlosti srovnatelné s Céčkem/Rustem“. Věřím, že bude existovat nějaký benchmark, který tak dopadl. Třeba u nějaké funkce, která má na vstupu i výstupu číslo (z hlediska dynamicky typovaného jazyka tam ale může přijít cokoliv), se může vyplatit udělat specializovanou variantu, která bude číslo předpokládat, a v některých případech ji použít – například dynamicky zkontrolovat předpoklad, že je na vstupu číslo, a podle toho se rozhodnout mezi obecnou a specializovanou variantou. Tady věřím, že se může podařit prakticky odstranit režii dynamicky typovaného jazyka, zvlášť pokud výpočet v té funkci bude náročnější, a tedy režie s kontrolou na začátku funkce bude zanedbatelná.
Podobné věci bych čekal spíše u JIT, který může využít informace z běhu (funkce f dostane vždy int, funkce g int nebo float, funkce h dostane v 99 % případů int), nicméně i AOT (ahead of time) to může udělat, jen k tomu má méně informací.
Pokud bychom ale měli funkci, která bude intenzivně pracovat s košatou strukturou, může být s podobnou optimalizací problém. Ono už u obyčejného pole může být náročné dtnamicky zjistit typ všech jeho prvků – jednak by to typicky znamenalo projít všechny prvky a jednak bychom mohli mít problém v případě úpravy pole třeba z jiného vlákna. Navíc je těžké podobná pole efektivně reprezentovat – v obecném případě je přímočaré udělat pole pointerů na hodnoty prvků, protože nepředpokládám konkrétní typy. Pro pole integerů se nabízí udělat přímo pole integerů (a nemít žádné pointery), ale pokud nemohu zajistit, že se tam nedostane prvek jiného typu, potřebuju řešení pro případ, že se tam nějak dostane. Což může být u velkého pole časově náročné. Ano, lze mít typy jako Int32Array, které nic jiného nepřijmou, ale tím v podstatě dodávám trochu typové informace ručně.
A teď si představte, že nemáte homogenní pole různé strukturované heterogenní hashmapy, které s odkazují na další hashmapy, atd. S dynamickým typováním to bude celkem běžné, třeba v JS objektový literál {key: value, …} je v podstatě taková heterogenní hashmapa.
-
Zkusím trochu střelby od pasu.
Otázka je, co přesně znamená „dosahují rychlosti srovnatelné s Céčkem/Rustem“. Věřím, že bude existovat nějaký benchmark, který tak dopadl. Třeba u nějaké funkce, která má na vstupu i výstupu číslo (z hlediska dynamicky typovaného jazyka tam ale může přijít cokoliv), se může vyplatit udělat specializovanou variantu, která bude číslo předpokládat, a v některých případech ji použít – například dynamicky zkontrolovat předpoklad, že je na vstupu číslo, a podle toho se rozhodnout mezi obecnou a specializovanou variantou. Tady věřím, že se může podařit prakticky odstranit režii dynamicky typovaného jazyka, zvlášť pokud výpočet v té funkci bude náročnější, a tedy režie s kontrolou na začátku funkce bude zanedbatelná.
Podobné věci bych čekal spíše u JIT, který může využít informace z běhu (funkce f dostane vždy int, funkce g int nebo float, funkce h dostane v 99 % případů int), nicméně i AOT (ahead of time) to může udělat, jen k tomu má méně informací.
Pokud bychom ale měli funkci, která bude intenzivně pracovat s košatou strukturou, může být s podobnou optimalizací problém. Ono už u obyčejného pole může být náročné dtnamicky zjistit typ všech jeho prvků – jednak by to typicky znamenalo projít všechny prvky a jednak bychom mohli mít problém v případě úpravy pole třeba z jiného vlákna. Navíc je těžké podobná pole efektivně reprezentovat – v obecném případě je přímočaré udělat pole pointerů na hodnoty prvků, protože nepředpokládám konkrétní typy. Pro pole integerů se nabízí udělat přímo pole integerů (a nemít žádné pointery), ale pokud nemohu zajistit, že se tam nedostane prvek jiného typu, potřebuju řešení pro případ, že se tam nějak dostane. Což může být u velkého pole časově náročné. Ano, lze mít typy jako Int32Array, které nic jiného nepřijmou, ale tím v podstatě dodávám trochu typové informace ručně.
A teď si představte, že nemáte homogenní pole různé strukturované heterogenní hashmapy, které s odkazují na další hashmapy, atd. S dynamickým typováním to bude celkem běžné, třeba v JS objektový literál {key: value, …} je v podstatě taková heterogenní hashmapa.
V Chezu se dá kontrola typů za běhu explicitně vypnout.
-
To ale řeší rychlost jen částečně. Ano, máte-li funkci přijímající parametr jediného typu, můžete zde něco ušetřit za cenu problémů, když předpoklad není naplněn.
IIRC ve Scheme třeba funkce + může pracovat s celými, desetinnými nebo komplexními čísly*. Každé z nich má jinou binární reprezentaci. Můžeme tedy mít funkci, která bude brát více typů. Kompilátor může pro některé typy udělat rychlejší specializovaný kód, a pak se podle typu rozhodnout (třeba i za běhu), který kód použije. Ale tuto kontrolu odstraníte stěží, pokud chcete zachovat optimalizaci…
*) Výčet nemusí být kompletní.
-
To ale řeší rychlost jen částečně. Ano, máte-li funkci přijímající parametr jediného typu, můžete zde něco ušetřit za cenu problémů, když předpoklad není naplněn.
To se dělá v případě nějaké externí typové kontroly, takže předpoklad je naplněn vždy.
-
autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem
Nově ověřeno na novém projektu :) Klobouk dolů :D
-
autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem
Nově ověřeno na novém projektu :) Klobouk dolů :D
Mohla by být nějaká ukázka pls? Jde mi o to, jaký "level" abstrakce ten kód má, jestli to třeba jen nění "prekabátěné céčko" (nic ve zlém, ale třeba na https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html je vidět, jak lidi ohýbají řešení až do extrému jen proto, aby z nějakého jazyka dostali další % speedupu). Fakt mě to zajímá, zrovna u Scheme.
-
autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem
Nově ověřeno na novém projektu :) Klobouk dolů :D
Mohla by být nějaká ukázka pls? Jde mi o to, jaký "level" abstrakce ten kód má, jestli to třeba jen nění "prekabátěné céčko" (nic ve zlém, ale třeba na https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html je vidět, jak lidi ohýbají řešení až do extrému jen proto, aby z nějakého jazyka dostali další % speedupu). Fakt mě to zajímá, zrovna u Scheme.
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
-
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
Muzes dat nejakej priklad problemu v syntaxi Lispu?
Ja se netajim tim, ze mi to vyhovuje a furt nedokazu pochopit co na tom komu muze vadit....
OK oteviraci zavorku pisu na trochu jiny misto nez v jinych jazycich, ale na to se prece snadno da zvyknout.
A vyhody ktery to prinasi jsou obrovske... homoikonicita, structured editing, nemusim resit priority operatoru ...
-
autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem
Nově ověřeno na novém projektu :) Klobouk dolů :D
Mohla by být nějaká ukázka pls? Jde mi o to, jaký "level" abstrakce ten kód má, jestli to třeba jen nění "prekabátěné céčko" (nic ve zlém, ale třeba na https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html je vidět, jak lidi ohýbají řešení až do extrému jen proto, aby z nějakého jazyka dostali další % speedupu). Fakt mě to zajímá, zrovna u Scheme.
Scheme je jen cíl transpilace, ten kód je dost nečitelný a plný lambd, podobný guláš jako výsledek překladu TS nebo Javy (GWT) do JS. Výchozí kód je čistě funkcionální (à la Haskell), do C má hodně daleko :)
-
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
Muzes dat nejakej priklad problemu v syntaxi Lispu?
Ja se netajim tim, ze mi to vyhovuje a furt nedokazu pochopit co na tom komu muze vadit....
OK oteviraci zavorku pisu na trochu jiny misto nez v jinych jazycich, ale na to se prece snadno da zvyknout.
A vyhody ktery to prinasi jsou obrovske... homoikonicita, structured editing, nemusim resit priority operatoru ...
Samozřejmě tam žádný problém není, jen praktické výhody. Subjektivní preference jsou jiná věc.
Když už by se mělo kritizovat, tak spíše sémantiku, například typová dynamičnost, ale i na to jsou řešení (přinejmenším dvě).
-
autoři Chez Scheme dosahují rychlosti srovnatelné s Céčkem/Rustem
Nově ověřeno na novém projektu :) Klobouk dolů :D
Mohla by být nějaká ukázka pls? Jde mi o to, jaký "level" abstrakce ten kód má, jestli to třeba jen nění "prekabátěné céčko" (nic ve zlém, ale třeba na https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html je vidět, jak lidi ohýbají řešení až do extrému jen proto, aby z nějakého jazyka dostali další % speedupu). Fakt mě to zajímá, zrovna u Scheme.
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
Lisp má i alternativní syntax: M-expression https://wiki.c2.com/?EmExpressions
-
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
Muzes dat nejakej priklad problemu v syntaxi Lispu?
Ja se netajim tim, ze mi to vyhovuje a furt nedokazu pochopit co na tom komu muze vadit....
OK oteviraci zavorku pisu na trochu jiny misto nez v jinych jazycich, ale na to se prece snadno da zvyknout.
A vyhody ktery to prinasi jsou obrovske... homoikonicita, structured editing, nemusim resit priority operatoru ...
Především tam těch závorek je moc. Homoikonicita je problém a ne řešení, protože většině programátorů prostě ta čitelnost přijde horší a obezličky typu rainbow parentheses to řeší jenom zčásti.
Vždycky když je nějaký flame o programovacích jazycích, někdo poznamená něco o znovuobjevení Lispu. A mně přijde, že když už, tak se znovuobjevuje ML. Když vynechám Clojure, tak si nevzpomínám na žádný jazyk v poslední době, který by se vydal cestou Lisp-like syntaxe.
-
U těchto jazyků je hlavní problém v syntaxi - Lisp je slepá ulička, kterou (skoro) nikdo fakt chodit nechce. Tu abstrakci si tam představit dovedu, ale za jakou cenu...
Muzes dat nejakej priklad problemu v syntaxi Lispu?
Ja se netajim tim, ze mi to vyhovuje a furt nedokazu pochopit co na tom komu muze vadit....
OK oteviraci zavorku pisu na trochu jiny misto nez v jinych jazycich, ale na to se prece snadno da zvyknout.
A vyhody ktery to prinasi jsou obrovske... homoikonicita, structured editing, nemusim resit priority operatoru ...
Především tam těch závorek je moc. Homoikonicita je problém a ne řešení, protože většině programátorů prostě ta čitelnost přijde horší a obezličky typu rainbow parentheses to řeší jenom zčásti.
Když vynechám Clojure, tak si nevzpomínám na žádný jazyk v poslední době, který by se vydal cestou Lisp-like syntaxe.
Je jich docela dost.
-
Ja se netajim tim, ze mi to vyhovuje a furt nedokazu pochopit co na tom komu muze vadit....
OK oteviraci zavorku pisu na trochu jiny misto nez v jinych jazycich, ale na to se prece snadno da zvyknout.
A vyhody ktery to prinasi jsou obrovske... homoikonicita, structured editing, nemusim resit priority operatoru ...
Jo a třeba ta priorita operátorů je z mého pohledu další záměna problému za výhodu. Když si nejsem jistý, můžu závorkovat snad v každém běžném jazyce, vtip je v tom, že obecně nemusím. Beru teoretickou výhodu výrazů typu (* x y z), ale nikdy v životě a to ani v době, kdy jsem se snažil si Lisp zamilovat, jsem si neřekl "tohle je bomba, jinde mi to zásadně chybí".
-
Když vynechám Clojure, tak si nevzpomínám na žádný jazyk v poslední době, který by se vydal cestou Lisp-like syntaxe.
Je jich docela dost.
Obecně věřím, ale kde jsou v TIOBE nebo jiném srovnání? Obskurní jazyky pro autora a pár fandů vůbec nevylučuju.
-
Když vynechám Clojure, tak si nevzpomínám na žádný jazyk v poslední době, který by se vydal cestou Lisp-like syntaxe.
Je jich docela dost.
Obecně věřím, ale kde jsou v TIOBE nebo jiném srovnání? Obskurní jazyky pro autora a pár fandů vůbec nevylučuju.
Znáš Julii? Zkus do konzole zapsat `julia --lisp` :D
Jinak K/Q, Wolfram, Lisp Flavored Erlang (LFE), prostě je jich celá řada...
-
Když vynechám Clojure, tak si nevzpomínám na žádný jazyk v poslední době, který by se vydal cestou Lisp-like syntaxe.
Je jich docela dost.
Obecně věřím, ale kde jsou v TIOBE nebo jiném srovnání? Obskurní jazyky pro autora a pár fandů vůbec nevylučuju.
A co s tím má společného zase TIOBE? Nemainstream neznamená nutně "Obskurní jazyk pro autora a pár fandů " ale třeba specializovaný. Já sem rád že se lidi snaží prošlapávat cestu i do stran.
-
V TIOBE sice není, ale známá hra Last od Us ho používá: https://www.youtube.com/watch?v=Ox2H3kUQByo&t=37m40s
-
když už, tak se znovuobjevuje ML
ML je ostatně podstatně zajímavější než Lisp. Nejnověji inspirovalo například Lean.
-
když už, tak se znovuobjevuje ML
ML je ostatně podstatně zajímavější než Lisp. Nejnověji inspirovalo například Lean.
Hlavne F#, to uz je rekl bych docela mainstream.
-
když už, tak se znovuobjevuje ML
ML je ostatně podstatně zajímavější než Lisp. Nejnověji inspirovalo například Lean.
Hlavne F#, to uz je rekl bych docela mainstream.
Víc mainstream, ale ne až tak zajímavé.
-
Především tam těch závorek je moc.
Neni... jen vseho ostatniho je tam min. ;-)
Homoikonicita je problém a ne řešení....
Nema resit citelnost, ale rozsiritelnost jazyka. a to resi celkem pekne...
A jako side effect prinasi tooling support.. viz structured editing..
a obezličky typu rainbow parentheses to řeší jenom zčásti.
rainbow parentheses neznam/nepouzivam...
pouzivam paredit a nepamatuju si, ze bych mel nekdy problem s balancovanim zavorek.
protože většině programátorů prostě ta čitelnost přijde horší
Mas nejaky data potvrzujici tohle tvrzeni?
-
Homoikonicita je problém a ne řešení
Krásná ukázka neznalosti a nepochopení.
-
protože většině programátorů prostě ta čitelnost přijde horší
Mas nejaky data potvrzujici tohle tvrzeni?
Zdroj: Just trust me dude.
-
Homoikonicita je problém a ne řešení
Krásná ukázka neznalosti a nepochopení.
Ale jdi.
-
> Neni... jen vseho ostatniho je tam min. ;-)
No a to je škoda - chápu, že to je věc názoru.
> Nema resit citelnost, ale rozsiritelnost jazyka. a to resi celkem pekne...
> A jako side effect prinasi tooling support.. viz structured editing..
Jenže čitelnost jazyka je základ. Netvrdím, že ta jednoduchost Lispu nemá svoje výhody a eleganci, ale v běžné praxi rozhoduje něco jiného.
> Mas nejaky data potvrzujici tohle tvrzeni?
TIOBE a spol.
-
protože většině programátorů prostě ta čitelnost přijde horší
Mas nejaky data potvrzujici tohle tvrzeni?
Zdroj: Just trust me dude.
Vtipe, vylez!
-
Obecně věřím, ale kde jsou v TIOBE nebo jiném srovnání? Obskurní jazyky pro autora a pár fandů vůbec nevylučuju.
A co s tím má společného zase TIOBE? Nemainstream neznamená nutně "Obskurní jazyk pro autora a pár fandů " ale třeba specializovaný. Já sem rád že se lidi snaží prošlapávat cestu i do stran.
Ale tady nejsme ve sporu. Já přece netvrdím, že to není cesta pro nikoho. Moje původní tvrzení bylo, že ten mainstream jde opakovaně jinou cestou a asi má k tomu svoje důvody.
-
Homoikonicita je problém a ne řešení
Krásná ukázka neznalosti a nepochopení.
Ale jdi.
Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.
-
Jenže čitelnost jazyka je základ.
Kdyby to bylo jediné kritérium, Rust by byl v řiti a Smalltalk králem.
-
Jenže čitelnost jazyka je základ.
Kdyby to bylo jediné kritérium, Rust by byl v řiti a Smalltalk králem.
No jasně. Proto všichni neprogramátoři používají Smalltalk a ne třeba ... Python.
-
Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.
Kontext, Idrisi, kontext.
-
Jenže čitelnost jazyka je základ.
Kdyby to bylo jediné kritérium, Rust by byl v řiti a Smalltalk králem.
No jasně. Proto všichni neprogramátoři používají Smalltalk a ne třeba ... Python.
Python je poměrně čitelný, takže to překvapivé není.
-
Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.
Kontext, Idrisi, kontext.
Jo, ten ti uniká. Homoikonicita nijak nesouvisí s čitelností. Ostatně Julia ji má taky a čitelná je značně.
-
Když někdo napíše, že “homoikonicita je problém”, má někde hodně velké znalostní mezery.
Kontext, Idrisi, kontext.
Jo, ten ti uniká. Homoikonicita nijak nesouvisí s čitelností. Ostatně Julia ji má taky a čitelná je značně.
No zrovna dnes jsem četl, jak kdysi v raných dobách vývoje Julie někdo z autorů napsal, že Julia je homoikonická a jaký se strhnul poprask od lidí, které to až urazilo. A o tom, co je homoikonicita, se vedou obecně spory:
https://stackoverflow.com/questions/31733766/in-what-sense-are-languages-like-elixir-and-julia-homoiconic/31734725#31734725
https://www.expressionsofchange.org/homoiconicity-revisited/
Ale hlavně - bavíme se o Lispu a tam je přece jasné, že to souvisí s jeho syntaxí a čitelností.
-
Jenže čitelnost jazyka je základ.
Kdyby to bylo jediné kritérium, Rust by byl v řiti a Smalltalk králem.
No jasně. Proto všichni neprogramátoři používají Smalltalk a ne třeba ... Python.
Štěstí na straně Pythonu, nic více. Problém Smalltalku byl, že se prosazoval v enterprise prostředí ale nakonec ho pohřbil sám Sun pomocí Java. Z pohledu čitelnosti a jednoduchosti syntaxe je na tom rozhodně lépe než Python. Jeho "nevýhoda" byla, že byl založen na binárních obrazech namísto textových souborů a komerční Smalltalk(y) byly drahé.
Náhoda a štěstí, víc v tom nehledejte. Nestěžuji si, Python mě živí, ale ještě si pamatuji s jakým odporem jsem se ho učil. Všude psali jak je elegantní a mně se tak nelíbil. Ale pragmatičnost zvítězila. Šok však nastává, když po deseti letech přichází nová generace, která na něm odrostla. V tom vidím docela problém. Nedivil bych se kdyby v tomto článku místo Java bylo jednou napsáno Python: https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/
-
bavíme se o Lispu
Dotaz byl o Scheme.
-
Štěstí na straně Pythonu, nic více. Problém Smalltalku byl, že se prosazoval v enterprise prostředí
Objective-C bylo parádním následovníkem, než ho Apple pohřbil.
-
> Nema resit citelnost, ale rozsiritelnost jazyka. a to resi celkem pekne...
> A jako side effect prinasi tooling support.. viz structured editing..
Jenže čitelnost jazyka je základ. Netvrdím, že ta jednoduchost Lispu nemá svoje výhody a eleganci, ale v běžné praxi rozhoduje něco jiného.
> Mas nejaky data potvrzujici tohle tvrzeni?
TIOBE a spol.
Podle me to umisteni zavorek nema na citelnost vliv. a kdyz muzu neco ziskat tim, ze bude zavorka na zacatku tak ji tam proste budu psat a je to zadarmo...
TIOBE hodnoti spis popularitu nez citelnost ne?
V top 10 vidim C++, ASM, PHP...
-
Já nemůžu odolat :-)
Co říkáte na tuto odpověď?
Chez Scheme je implementace jazyka Scheme, který je dynamický, vysokoúrovňový jazyk s podporou funkcionálního programování. Autoři Chez Scheme dosahují vysoké rychlosti pomocí několika technik:
Jit-kompilace: Chez Scheme používá just-in-time (JIT) kompilaci k překladu Scheme kódu do strojového kódu. Toto umožňuje, aby kód byl spuštěn rychleji, protože strojový kód může být vykonán přímo procesorem, namísto interpretace vysokoúrovňového kódu.
Typová analýza: Chez Scheme používá statickou typovou analýzu k detekci kódu, který může být efektivněji kompilován. Toto umožňuje, aby kód byl kompilován s využitím specifických optimalizací pro různé typy dat.
Předkompilace: Chez Scheme umožňuje předkompilovat často používaný kód, což umožňuje rychlejší spouštění programu.
Optimalizace: Chez Scheme používá různé techniky optimalizace, jako např. common subexpression elimination, constant folding a inlining, které zlepšují výkon kódu.
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
-
K původnímu tématu, překladač Chezu dělá v podstatě tohle: https://arxiv.org/pdf/2109.01950.pdf
Když se zdroják generuje (transpiluje) z typovaného jazyka, je kód zaručeně typově stabilní, a tedy rychlý. Pořád tam jsou rezervy, pokud se používají například jen induktivní typy, nemůže vzniknout referenční cyklus, a pak je tracing GC k ničemu, ale to je na jinou diskusi.
-
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Je to tak, ale už se nějak točíme v kruhu.
-
bavíme se o Lispu
Dotaz byl o Scheme.
Scheme je dialekt Lispu, ale OK. Pojďme zpět k tématu - beru, že když se Chez používá v situaci s jasnými typy a vstup je nízkoúrovňový, je to rychlé. Otázka zní: Bylo by možno ve Scheme psát rozsáhlý, bezpečný, čitelný a výkonný kód?
-
Bylo by možno ve Scheme psát rozsáhlý, bezpečný, čitelný a výkonný kód?
Možné to jistě je, ale já beru Scheme jako cíl transpilace (podobně jako JS), psát přímo v něm bych moc nechtěl (není to peklo jako JS, ale ani žádná sláva). V nějakém příčetnějším dialektu si to dovedu představit (Racket), ale ten zas není tak rychlý.
-
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Je to tak, ale už se nějak točíme v kruhu.
Děkuji a uvítám další názory na relevanci toho příspěvku.
-
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Je to tak, ale už se nějak točíme v kruhu.
Děkuji a uvítám další názory na relevanci toho příspěvku.
Jen k tomu JIT bych ještě dodal, že je v tomto případě irelevantní (překlad probíhá AOT).
-
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Je to tak, ale už se nějak točíme v kruhu.
Děkuji a uvítám další názory na relevanci toho příspěvku.
Jen k tomu JIT bych ještě dodal, že je v tomto případě irelevantní (překlad probíhá AOT).
Díky, někdo další ?
-
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Díky, někdo další ?
Nevím, nakolik to považuješ za relevantní, ale C není Rust a v praxi má každý z těchto dvou jazyků, co se týče výkonu, trochu jinou pozici:
https://kornel.ski/rust-c-speed
Obecně vzato, řekl bych, že hodně záleží i na té horní vrstvě, jaké umožňuje abstrakce a jak se ty její konstrukce dají optimalizovat ve výsledném kódu.
-
Já nemůžu odolat :-)
Co říkáte na tuto odpověď?
Chez Scheme je implementace jazyka Scheme, který je dynamický, vysokoúrovňový jazyk s podporou funkcionálního programování. Autoři Chez Scheme dosahují vysoké rychlosti pomocí několika technik:
Jit-kompilace: Chez Scheme používá just-in-time (JIT) kompilaci k překladu Scheme kódu do strojového kódu. Toto umožňuje, aby kód byl spuštěn rychleji, protože strojový kód může být vykonán přímo procesorem, namísto interpretace vysokoúrovňového kódu.
Typová analýza: Chez Scheme používá statickou typovou analýzu k detekci kódu, který může být efektivněji kompilován. Toto umožňuje, aby kód byl kompilován s využitím specifických optimalizací pro různé typy dat.
Předkompilace: Chez Scheme umožňuje předkompilovat často používaný kód, což umožňuje rychlejší spouštění programu.
Optimalizace: Chez Scheme používá různé techniky optimalizace, jako např. common subexpression elimination, constant folding a inlining, které zlepšují výkon kódu.
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Že z toho smrdí ChatGPT na sto honů.
-
Já nemůžu odolat :-)
Co říkáte na tuto odpověď?
Chez Scheme je implementace jazyka Scheme, který je dynamický, vysokoúrovňový jazyk s podporou funkcionálního programování. Autoři Chez Scheme dosahují vysoké rychlosti pomocí několika technik:
Jit-kompilace: Chez Scheme používá just-in-time (JIT) kompilaci k překladu Scheme kódu do strojového kódu. Toto umožňuje, aby kód byl spuštěn rychleji, protože strojový kód může být vykonán přímo procesorem, namísto interpretace vysokoúrovňového kódu.
Typová analýza: Chez Scheme používá statickou typovou analýzu k detekci kódu, který může být efektivněji kompilován. Toto umožňuje, aby kód byl kompilován s využitím specifických optimalizací pro různé typy dat.
Předkompilace: Chez Scheme umožňuje předkompilovat často používaný kód, což umožňuje rychlejší spouštění programu.
Optimalizace: Chez Scheme používá různé techniky optimalizace, jako např. common subexpression elimination, constant folding a inlining, které zlepšují výkon kódu.
V kombinaci tyto techniky umožňují Chez Scheme dosahovat srovnatelné rychlosti s jazyky jako C nebo Rust, i když je Scheme dynamickým jazykem s vysokoúrovňovými abstrakcemi.
Že z toho smrdí ChatGPT na sto honů.
Ano, výborně! Chtěl jsem a) zjistit jestli to jde poznat a za b) dostat z vás odborníků, jestli nekecá, což se mi zatím nepodařilo. Nevím o tom totiž vůbec nic. Díky za účast.
-
Ano, výborně! Chtěl jsem a) zjistit jestli to jde poznat a za b) dostat z vás odborníků, jestli nekecá, což se mi zatím nepodařilo. Nevím o tom totiž vůbec nic. Díky za účast.
ChatGPT se nedá věřit, umí jenom papouškovat, je schválně natrénovaný, aby měl levicové "názory" a esej s opačným názorem dokonce odmítne vytvořit. A lže: Napřed mi tvrdil, že Modlitbu pro Martu napsal Nohavica, když jsem se ohradil, řekl, že mám pravdu a napsal ji Kryl a když jsem mu napsal, kdo byli skuteční autoři, tak mi to odkýval a tvářil se, že jsme v pohodě. No, nejsme.
-
Nevím, nakolik to považuješ za relevantní, ale C není Rust a v praxi má každý z těchto dvou jazyků, co se týče výkonu, trochu jinou pozici:
https://kornel.ski/rust-c-speed
Obecně vzato, řekl bych, že hodně záleží i na té horní vrstvě, jaké umožňuje abstrakce a jak se ty její konstrukce dají optimalizovat ve výsledném kódu.
To se týká každého “vyššího” jazyka, Rust je ještě poměrně nízko, vem si Lean nebo Prolog, dělají věci úplně jinak než “normální” procedurální jazyky, ale kód také generují rychlý (protože high-level optimalizace).
-
Nevím, nakolik to považuješ za relevantní, ale C není Rust a v praxi má každý z těchto dvou jazyků, co se týče výkonu, trochu jinou pozici:
https://kornel.ski/rust-c-speed
Obecně vzato, řekl bych, že hodně záleží i na té horní vrstvě, jaké umožňuje abstrakce a jak se ty její konstrukce dají optimalizovat ve výsledném kódu.
To se týká každého “vyššího” jazyka, Rust je ještě poměrně nízko, vem si Lean nebo Prolog, dělají věci úplně jinak než “normální” procedurální jazyky, ale kód také generují rychlý (protože high-level optimalizace).
Nejsem si jistý, zda každého, ale určitě to není věc výlučně Rustu. Co se týče Leanu, tak kvůli němu vznikla celá tahle debata, nebo to byl jiný jazyk kompilovaný skrze Chez?
-
Co se týče Leanu, tak kvůli němu vznikla celá tahle debata, nebo to byl jiný jazyk kompilovaný skrze Chez?
Ne, Lean se překládá přímo a jeho sémantika překlad do Scheme ani neumožňuje.
-
Ano, výborně! Chtěl jsem a) zjistit jestli to jde poznat a za b) dostat z vás odborníků, jestli nekecá, což se mi zatím nepodařilo. Nevím o tom totiž vůbec nic. Díky za účast.
ChatGPT se nedá věřit, umí jenom papouškovat, je schválně natrénovaný, aby měl levicové "názory" a esej s opačným názorem dokonce odmítne vytvořit. A lže: Napřed mi tvrdil, že Modlitbu pro Martu napsal Nohavica, když jsem se ohradil, řekl, že mám pravdu a napsal ji Kryl a když jsem mu napsal, kdo byli skuteční autoři, tak mi to odkýval a tvářil se, že jsme v pohodě. No, nejsme.
JJ, na Grétu jsem se ho ptát neměl, to teda byla přednáška :-)