Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Králík

Stran: 1 2 3 [4] 5
46
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 12. 2022, 10:06:35 »
Aha. Tak nám v tom transpilovaném kódu ukaž, kde jsou ty tvoje runtimy, GC a vtables, o kterýchs tvrdil, že tam určitě musí být.
Runtime v tom C kódu pochopitelně je velmi silně. GC tam je, byť v primitivní formě - refcounting všeho. V JS a Java výstupu pochopitelně implicitně jsou GC i silný runtime. Vtables tam (v C) nejsou a ani dispatch na základě typových tagů - tohle jsem předpokládal na základě tvého nepravdivého výroku, že typové parametry jsou vymazány a vůbec ve výsledném kódu nefigurují - pokud tam typový parametr může zůstat, není pro tyto mechanismy důvod (alespoň v tomto příkladu - neznám všechny zákoutí toho jazyka). Takhle stačí?

ale myslím, že už ses z této diskuse dost naučil (díky, BoneFlute) a klidně můžeme ještě nějakou dobu pokračovat ;)
Od BoneFlute by ses měl učit především ty.

47
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 12. 2022, 09:19:42 »
Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.
Jak zněl ten výrok?
->
kontrola toho typového parametru pro délku se provádí při překladu a pak se provede type erasure, v době běhu programu tam ten typový parametr vůbec není. Například Idris nebo Lean umí transpilaci do C, kde není runtime pro typy ani GC, veškerou kontrolu oddře překladač a když usoudí, že je kód typově správně, vyplivne výstup bez typových parametrů, ty právě slouží pouze ke statické kontrole.

JS kód vygenerovaný Idrisem:

Kód: [Vybrat]
function Main_getCol($0, $1, $2) {
 const $3 = Data_Nat_isLTE($0, 1000n);
 switch($3.h) {
  case 0: /* Yes */ return Main_getCol1($1, $2);
  default: return Main_getCol2($1, $2);
 }
}

$0 je velikost matice.

V Céčku je kód cca to samý, akorát mnohem výřečnější, protože úplně všechny hodnoty (i funkce) jsou boxovány do typu Value, které pak ten rozhodně-ne-interpretr, no, jaksi interpretuje :D

---

Že Králík neví, co je interpretr ::) Ale aspoň už zjistil, co jsou v Idrisu implicitní parametry.
::)

Především jsem zjistil, že si strašně vymýšlíš. Také jsem zjistil, že Idris je jen jakési experimentální skriptovadlo - měl jsem dříve představu, že to je kompilovaný jazyk jako Haskell.

Btw. v této přednášce Simon Peyton Jones mluví o možnostech linearity v Haskellu a také trochu o Rustu, borrowing/ownership označuje jako "Linearity on the Kinds". Asi by to chtělo mu dát vědět, že to má špatně, že uživatel Idris prohlásil, že borrowing/ownership nemá s typovým systémem vůbec nic společného...

48
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 06. 12. 2022, 00:47:59 »
Jestli už máš Idris 2, tak můžeš zkusit tohle:
Kód: [Vybrat]
...
Zkusil jsem. Ten generovaný C kód je naivní interpreter, optimalizace veškeré žádné, každá hodnota by default alokována a reference counted ... nevidím nic o cyklech nebo weak referencích, cykly buď není možné vytvořit, nebo leakují... Reference couting není atomický... I třeba sečtení dvou čísel je alokace nové hodnoty, vždy... Ten typový parametr rozměru se tam prostě zpropaguje jak v C tak i v JS kódu, žádný type-erasure, neměl jsem na ten výrok o type-erasure v první řadě vůbec skočit.

Ááááchjo.

49
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 18:32:02 »
1) Ignorujeme skutečnost, že Java bude brutálně optimalizovat, a JITovat, takže ve skutečnosti ten kód bude všelijakej.
Ano, samozřejmě, ale když píšeš tu generickou funkci, tak v Javě tohle nevíš, nevíš, jak se zrovna VM vyspí a za jakých podmínek usoudí, že dané volání pro nějaký typ inlinuje, jak dlouho bude trvat, než si všimne, že to je potřeba a kolik tě bude stát tato činnost VM. V C++ nebo Rustu tohle víš dopředu o dost lépe (byť samozřejmě taky ne dokonale), protože ta abstrakce je prostě výkonově transparentnější, je to predikovatelnější.

(Samozřejmě to řešení v Rustu/C++ má i svoje nevýhody - neříkám, že ne.)

50
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 18:27:01 »
Ty tvrdíš, že nejenom, že to tam (v runtime) obecně musí být, ale navíc to v některých jazicích být musí (Haskel, Idris) a v některých (Rust) ne.

Mě by zajímalo proč.
To je možná nedorozumění. To co tvrdím v kostce je, že jazyky jako Rust nebo C++ nemůžou jen tak přejímat různé "sofistikované" abstrakce, protože musí dodržovat výkonovou transparenci svých abstrakcí (populárně "zero-cost abstractions"). Ano, ve spoustě případů může kompilátor v jazycích jako Haskell nebo Idris výsledný kód zoptimalizovat, takže výsledná cena není hrozná, to ale zkrátka není v jazyce jako Rust dostatečné, abstrakce v těchtoo jazycích musí být transparentnější, musí méně záviset na tom, jestli se zrovna v daném případě podařilo nebo nepodařilo kompilátoru kód zoptimalizovat, jestli bude GC dost rychlý a nebude moc brzdit atd.

51
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 18:15:08 »
Já vím přesně co je vtable, ať už v originále, nebo v tvém použití.

Co mě mate je type-erased metoda. Měl jsem za to, že type erased je chování, kdy za určitých okolností ztrácíme informaci o typu (respektive je nám zabráněno se k ní dostat). Wiki tvrdí toto: In programming languages, type erasure is the load-time process by which explicit type annotations are removed from a program, before it is executed at run-time.
Dobře, tak nějaký konkrétní příklad, třeba Javu, ať je to jednoduchý - dejme tomu, že definuješ generickou funkci static <T> void writeAsString(T object) {} která vezme object, zavolá toString() a výsledek někam zapíše. Při kompilaci z toho java ty typy odstraní a vytvoří něco jako (ne doslova) void writeAsString(Object object) ... kód tý metody tedy při volání neví, jakej typ má argument, takže metodu toString() musí volat přes vtable, nemůže ji volat přímo.

52
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:52:10 »
Nejseš žádná metoda. Nic takové není.

Ve funkci načítání matice ze souboru je podmínka, která zjistí velikost dat. Pokud je to větší jak požadovaná podmínka (IF, SWITCH), tak provede větev, kde funkci col_optimalized předá získané data (surový pole bytů), pokud je menší, předá data funkci col_unoptimalized. Nikde žádné typy, nikde žádné tagy, nikde žádné vtable.
To je ale specielní případ, kdy jsi funkci `col` inlinoval do volající funkce. Tím ses vyhnul mé otázce, ale tohle není obecné řešení, nemůžeš všude všechno inlinovat. Představ si, že funkce `col` je třeba v už zkompilované knihovně nebo z nějakého jiného důvodu nelze inlinovat.

53
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:48:22 »
Na co by mi v run-time byly typy, když je nepoužívám - proč mít vtable, když jsem typy odrbal = type erasure.
Type-erased metoda neví, jaký typ ji přichází jako argument - proto se tomu říká type erasure. Tím pádem neví, jak konkrétně danou operaci nad tim argumentem provést. Buďto si může ten typ přečíst z nějakého tagu a udělat tu vidličku, anebo si přečte z vtable adresu konkrétní imeplementace a tu zavolá.

Přijde mi, že tě koncept vtable mate - vtable není typ.

54
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:42:15 »
Tagují se součtové typy, to s typovými parametry vůbec nesouvisí.
Ano, přesně tak, v případě nepoužití vtable je ten typ efektivně konvertován na součtový, tj. v tom příkladu s maticí s prahem velikosti pro jinou reprezentaci to efektivně bude součtový typ obsahující dvě varianty - malá a velká matice.

55
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:37:21 »
Načtu matici ze souboru.
Zjistím velikost matice, podle toho vyberu buď reprezentaci (nikoliv typ) A, nebo reprezentaci B.
Pokud je to A pošlu to "uličkou" A. Pokud je to B pošlu to uličkou B.
Konkretizuj to prosím. Představ si, že seš metoda `col`. Na základě čeho uděláš to rozhodnutí, kterou uličkou poslat maticová data?

56
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:30:55 »
Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.
Jazyky jako Idris a Lean (a pár dalších) dělají type erasure a vtables v generovaném kódu taky nepoužívají.

No ano, protože ty hodnoty tagují, jak jsem viděl (v kódu všude velké switche na tagy).

Idris2 se mi instaluje, jak si z něj vygeneruju C kód pomocí 'refc' backendu?

57
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:18:24 »
Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Já té formulaci asi nerozumím.
Tak tak. Ta formulace je blábol, nedává to vůbec smysl.
A byl by nějaký argument? Na co by mi proboha prosím byl vtable, pokud nedělám type erasure? Přesně z toho důvodu, že jazyky jako C++ nebo Rust nedělají type erasure generik (místo toho monomofrigzují) nepotřebují vtables, narozdíl třeba od Javy.

58
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 17:00:25 »
Aby tohle fungovalo, musí být ta hodnota boxovaná (na-alokovaná na heapu a schovaná za, efektivně, pointer) a operace na ní se provádí přes dynamic dispatch (bude tam nějaký ekvivalent v-table), jinak by nebylo možné provést type erasure.
Teda, já jsem to vždycky chápal tak, že type erasure je způsob, jak typy odrbat. Kde by tam jako měla být schovaná vtable? A proč? Ve skutečnosti tam tu vtable potřebuješ v případě, kdy nechceš dělat type erasure...

Dobře, tak mějme ten příklad s maticí. Dejme tomu, že od nějaké velikosti Thr (jako threshold) používá implementace matice nějakou vymakanou reprezentaci v paměti kvůli ušetření místa pro velké matice. Ok? Teď dejme tomu, že máme operaci `col` na matici, která vrátí daný sloupec jako vektor. Tahle operace bude muset fungovat různě v závislosti na Thr, z úsporné reprezentace se čte sloupec jinak než z jednoduché.

Tak, a teď, ty napíšeš program, který načte matici ze souboru a bude chtít číst sloupce. Pokud by ta typová informace - v tomto případě velikost matice - byla komplet odstraněna, metoda `col` by neměla jak poznat, jak je konkrétní matice v paměti reprezentována, a tedy jak extrahovat sloupec. Proto bude muset ta matice si s sebou tu informaci vzít a držet si ji během runtime, buďto to může být nějaký tag, podle kterého udělá ta metoda `col` vidličku, anebo si s sebout vezme vtable, která bude u různých konkrétních hodnoty ukazovat na různé implementace `col`. Řešení s vtable je obecnější - těch typových parametrů může být více, chování se může v závislosti na nich více lišit.

V jazyce jako Rust nebo C++ tohle není potřeba, protože kompilátor zná dopředu všechny instanciace a provede monomofrizaci, ie. v podstatě z toho udělá různé typy s různými metodami, ale cena za to je, že není možné vytvořit tu hodnotu at runtime.

Není podstatné, že Lua je dynamický jazyk. Chtěl jsem tím uvést, že když jsem se kouknul do toho zdrojáku, tak tam žádné typové informace, které tvrdíš, že tam musí zůstat aby něco, nebyly.
Jak jsi poznal, že tam nebyly typové informace? V jazyce jako Lua má každá hodnota runtime typovou informaci, tak fungují dynamicky typované jazyky, tzn. ty typy tam nemohly nebýt :)

---

Jinak podíval jsem se na C výstup Idris kompilátoru a je to prostě VM (verze idris je u mě 1.3.4). Toto je funkce alokující hodnotu, okopírováno z Idris runtime:

Kód: [Vybrat]
static inline Con * allocConF(VM * vm, uint32_t tag, uint16_t arity, int outer) { ... }

Hádejte, co je `tag` :D

59
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 16:08:01 »
Ano, ta typová kontrola probíhá při překladu, to já nijak nerozporuju, ale ten vygenerovaný kód, který je produktem toho kompilátoru, musí pak nutně záviset na runtime vlastnostech. ... ale jakmile bude to bude složitější, nepůjde to.
Nějakou dobu jsem si hrál s Amulet ML, který kompiloval statickej kód do Luy. Díky tomu j sem si mohl vcelku rozumě prohlédnout, co to vymejšlelo. Na základě této zkušenosti ti nemohu dát za pravdu.
Já mam na mysli tu situaci, kdy zkonstruuješ parametrizovaný typ jako např. ten vektor nebo matici dynamicky ze vstupních dat. Lua úplně není dobrej příklad, protože to je dynamicky typovaný jazyk, tj. pochopitelně obsahuje runtime typové informace. Spíš by bylo lepší se podívat na ten C výstup.

60
Vývoj / Re:Je Rust jazyk budoucnosti?
« kdy: 05. 12. 2022, 15:16:38 »
(Kdyžtak pls ukázku, jak tohle specifikuju bez typového systému.)

Stran: 1 2 3 [4] 5