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.
Jsi si jistý?Pokud je ale ta úloha z definice sekvenčníTa úloha není z definice sekvenční, [...] dva panáci nesmí současně pracovat s jedním pomerančem.
Nikdo netvrdí, že by to nešlo, samozřejmně že to jde. Ale je to neefektivní, imperativní přístup s mutable objetky dává lepší výsledky.Citation needed.
Však jo, já neříkám nic jiného, takhle to v FP funguje a má fungovat. A FP se taky zaklíná tím, že mávnutím kouzelného proutku řeší problémy s paralelizací a synchronizací, které mají imperativní jazyky. Řeší, ale nikoliv obecně, funguje to jen pro určité úlohy. Ve chvíli, kdy se jedná o nějaký složitejší problém (paralelním výpočtem vznikne více různých scén), tak nemám žádnou metodu, jak je dát deterministicky dohromadyAle samozřejmě že máš, vždyť jsem ti napsal několik metod. Pokud je ale ta úloha z definice sekvenční, tak ji prostě FP žádným magickým proutkem samo neparalelizuje, to dá rozum. Pokud budeš počítat sha(md5(x)), tak na to prostě nemůžeš jít stylem y=md5(x) z=sha(x) a divit se, že neumíš y a z "dát deterministicky dohromady". Protože to prostě takhle nejde.
byla to reakce hlavne na gamera.Aha, tak to jsme si nerozuměli, já to chápal přesně opačně
Ten rozdil je v implementaci, ale ne semanticky. Hodnota je hodnota - presne jako ve vasem kodu, "zmena" hodnoty proste vytvori novou hodnotu, hotovo.Já bych to asi polopaticky řekl takhle: celý to nepochopení je způsobený tím, že v imperativních jazycích se pracuje s pamětí - s chlívečky, které jsou nějak pojmenované a postupně do nic něco strkám. Tímpádem i dvě vlákna můžou vidět tentýž chlíveček a něco tam strčit.
Řekl bych, že to zmatení s immutable a víc vlákny je z tohoto pohledu:Ano, já si taky myslím, že tak nějak ta gamerova představa je. Jenže tohle se prostě ve FP neděje, to je představa přenesená z imperativních jazyků. Ve FP se nepracuje s žádnými referencemi v tomhle smyslu. Pokud mám dvě funkce f1 a f2, jedna přičítá jedničku a druhá dvojku, a předhodím jím tentýž stav (5), tak mi prostě jedna vrátí 6 a druhá 7, to je správně a má to tak být. Jak jsem říkal, není to nic jiného než starý dobrý https://en.wikipedia.org/wiki/MISD Pokud chci ty funkce na stav aplikovat postupně, tak to opravdu musím udělat postupně - f1 mi vrátí 6 a potom aplikuju f2, která mi vrátí 8. V jazycích, které mají speciální vlastnosti (Haskell) si pak taky můžu hrát třeba s tím, že na pořadí aplikace nezáleží, můžu f1 a f2 snadno sloučit do jedné operace atd. atd. Mám tam úplně jiné možnosti a proto bych jich měl využívat a ne psát kód imperativním stylem a divit se, že mi to nefunguje podle představ...
Mám immutable data, řekněme číslo 5 někde, a mám dvě vlákna, které mají referenci na tu 5 (obě vlákna drží ukazatel na stejnou adresu), pokud obě provedou příčtení čísla 2 , tak dojde k copy on write, obě vlákna ukazují na číslo 7, ale na dvou místech (a pokud původní 5 už nikdo nedrží, likviduje ji GC). Gamer se ptá, jak udělat, aby když ty dvě vlákna to přičtení udělají, aby viděly výsledek 9....
Opět: je ale potřeba to umět využít a využívat...Je tahle "1" neco jineho, nez tahle "1"? Jak je odlisim? Hodnota je hodnota a je uplne jedno, jestli ji kopiruju nebo na ni nejak odkazuju.Neni to jedno, protoze odkaz je prakticky zadarmo, kopirovani muze byt hodne drahy. A jestli nekdo tvrdi, ze problem je v kopirovani, tak to je proste kravina, protoze se nic nekopiruje, jenom odkazuje.
Pokud postava bere pomeranc a oboji ma byt immutable, pak je vysledkem nova postava. Pokud jsou dve ruzne a jsou obe to soucasti jedne immutable sceny, tak je vysledkem jina immutable scena. Je to stejne, jako 1+1+1. Kdybych to mel paralelizovat, tak musim na konci resit synchronizaci, protoze vysledkem je jedna nova zmenena scena, odlisna od puvodni, jina hodnota. Ta synchronizace se postara, ze "vyhraje" jedna z postav, ale nemelo by dojit ke kolizi, protoze nema jak, pokud je to cele immutable.Sorry, ale já vůbec nechápu, co řešíte. Jaký "Pokud jsou dve ruzne a jsou obe to soucasti jedne immutable sceny"? Mám prostě
def init_state do
...
end
def aktualizuj_postavu(postava) do
...
end
def aktualizuj_stav(stary_stav) do
{stara_postava,nejaky_zatracene_velky_data,jiny_zatracene_velky_data} = stary_stav
nova_postava = aktualizuj_postavu(stara_postava)
{nova_postava,nejaky_zatracene_velky_data,jiny_zatracene_velky_data}
end
def loop(stav) do
stav2 = aktualizuj_stav(stav)
loop(stav2)
end
def main do
stav1 = init_state
loop(stav1)
end
Já ale neřeším interní implementaci, ta je mi ukradená a může být úplně jiná v každém jazyce. Máš immutable objekt, který nejde změnit. Ty s ním chceš něco udělat, takže musíš vytvořit nový objekt. To je u mě kopie. Říkej si tomu třeba kopírování pointerů, interně to tak klidně může fungovat, ale nesnaž se tvrdit, že jsou to ty stejné objekty. Nejsou. Interně můžou být, ale taky nemusí. Logicky je to jiný objekt.Tak já nevím, možná mluvím Čínsky, ale vůbec nerozumím, proč tohle píšeš, protože to vůbec nesouvisí s tím, co jsem napsal. No, nechme to být, zavání to spíš zbytečným flejmem než zajímavou diskusí...
Telefonní ústředna je z hlediska logiky funkce jednoduché zařízení, prakticky jen spojuje hovory, dá se to implementovat třeba relativně jednoduchým stavovým automatem, žádné složitosti v tom nehledej.Ugh. Viděl jsi někdy konfiguraci Asterisku? A viděl jsi někdy specifikaci Jabber protokolu a k tomu alespoň pár rozšíření?
Nevím kolik máš zkušeností s vývojem herTo je jednoduchý - žádný. Taky jsem o vývoji her nic netvrdil, mluvím jenom o FP a vyvracím tvoje tvrzení o něm.
Samozřejmě že jde napsat Wolfenstein 3D v Haskellu. Stejně jako jde napsat webserver v bashi. Fungovat to bude, ale je to spíš jen takové myšlenkové cvičení, prakticky se funkcionální jazyky ve vývoji her neprosazují.Tak to se neprosazují v ničem, to není specialita her
A důvody k tomu můžou být různé - třeba to, že každý programátor začíná imperativně nebo objektově. Kdyby každý začínal funkcionálně, kdoví, jestli by se OOP "prosadilo"
Tohle je jen slovíčkaření. Když se něco mění, tak se to nově vytvoří. To je u mě kopie. Ty tomu kopie neříkáš, protože se to staré zničí.Kopie znamená, že mám někde v paměti nějaká data a PŘEKOPÍRUJU je někam do nějaké jiné oblasti paměti - mám dvě KOPIE, které jsou stejné. A k tomuhle právě nikdy nedochází. Pokud jsou někde stejná data, tak se případně kopíruje jenom pointer na ně, protože vím, že je nikdo nikdy nezmění, takže můžu s klidem ten pointer předat komu chci.
Ano, teoreticky to funguje hezky a prakticky to taky funguje hezky, ale jen na úlohy, které pracují s daty, která jsou na sobě málo závislá a vlákna si je navzájem nemění. Taková telefonní ústředna nebo jabber server jsou ideální aplikace pro Erlang, každé vlákno si obsluhuje to svoje a vlákna si navzájem data nemění prakticky vůbec. S Erlangem ale narazíš, když se budeš pokoušet řešit úlohu opačného typu: velké množství vzájemně provázaných a interagujících objektů, žijících v jednom velkém společném světě.To jsou takové mlhavé statementy, založené kdovínačem. Telefonní ústředna snad není "provázaná"? Každý může komunikovat s každým a když komunikuje A s B, tak ani s jedním nemůže komunikovat nikdo jiný. Jestli tohle není provázanost, tak už fakt nevím
Zkusím to jednoduše. Mám pomeranč ve scéně. Chci ho přesunout z bodu A do bodu B. Pokud je immutable, musím vytvořit kopii. Buď pomeranče, nebo celé scény.Neděláš kopii ani jednoho. V "immutable jazycích" to funguje tak, že když se nic nemění, tak se na to nesahá. Když se něco mění, tak se to staré zničí a nové vytvoří. Takže to, co asi chceš říct, není KOPÍROVÁNÍ, ale náklady spojené se zničení a vytvořením nového.
tak to je klasická SIMD situace a používá se na to map+reduce.Sorry, překlep, mělo být "MISD".
Ta kopie vznikne. Ve chvíli, kdy to paralelizuješ, můžou z jednoho pomeranče vzniknout dva, což nechceš, tohle se v reálném světě neděje.Nic takového se právě neděje. Smysl immutable dat je v tom, že jsou tím, čím jsou a právěže je NEMUSÍM kopírovat a nikdy nekopíruju - předávám je všude tak, jak jsou, protože vím, že je nikdo nemůže změnit, čili si s tím nelámu hlavu.
Tusim autor hry Iconclad :Steam Legions (psano v Clojure) se v blogu tvaril, jak se mu s immutable stavem hry strasne dobre pracovalo.Pokud někoho immutables ve hrách zajímá, mohlo by ho zajímat i tohle: https://www.youtube.com/watch?v=yIlDBPiMb0o (webová hra, jednoduchá, ale na videu celá vysvětlená)
Immutable objekty fungují hezky v teorii, ale prakticky narazíš na to, že stejně musíš řešit synchronizaci. Dělám třeba hru, kde panáci sbírají pomeranče. Panák přijde k pomerančí ležícímu na zemi a strčí si ho do kapsy. Pomeranč je immutable. Takže co panák udělá, vytvoři novou kopii pomeranče, která je v jeho kapse. Starý pomeranč zruší. Doteď všechno v pohodě.No jo, jenže to asi mluvíš o nějakém jazyku, který má immutabilitu jenom na okrasu, nebo nevím. Protože vůbec nevím, proč by se něco někam mělo kopírovat, minimálně pokud scéna i panáček běží v jednom procesu.
A teď si řeknu, no jo, když mám všechno immutable a mám spoustu jader CPU, tak pustím všechny panáky paralelně a všechno bude mnohem rychlejší. Jenomže pak přijdou k jednomu pomeranči paralelně dva různí panáci. Oba ve stejný čas vytvoří kopii pomeranče ležícího na zemi a strčí si ho do kapsy. Starý pomeranč zruší. Všechno krásně funguje, akorát místo jednoho pomeranče mám dva. To není úplně přesně to, co bych chtěl.Opět - to mluvíš asi o nějakém jazyku, který obsahuje sdílená data. Tímpádem potřebuješ synchoronizaci. Tímpádem můžeš úplně s klidem zůstat u klasického OOP, seš tam, kdes byl.
S celou immutable scénou si to už vůbec nedovedu představit. Mám scénu na které je 50 panáků. Každý panák něco udělá a vytvoří si kopii scény. Mám 50 různých scén, každá je jiná. Co s tím budu dělat, jak dám 50 různých scén nějak deterministicky dohromady do jedné?
Zkušenosti mám, například když spustíš dvě vlákna a každému předáš immutable kopii tvých dat, tak po skončení vláken musíš psát extra algoritmus na sloučení výsledků. U klasické synchronizované mutable struktury tohle neřešíš.Tohle je stejnej případ, jako jsem teď psal kolegovi - tohle se v jazycích, které OPRAVDU immutable používají (tj. nemají ho jenom na okrasu) prostě neděje. Pokud máš jedna data a nad nimi chceš spustit deset různých operací, tak to je klasická SIMD situace a používá se na to map+reduce.
Samozřejmě má immutable přístup svoje výhody, ale není to univerzální všelék, jsou případy kdy je to kontraproduktivní.
s immutable objektyPardon, tady jsem myslel spíš "data" než "objekty" ve smyslu OOP.
Většinu objektů píšu hlavně proto že potřebuji mutable data a udržet data při změnách konzistentní, nepřekvapivě. [...] a měnění pointerů na novou kopii a to přináší zase jiné problémy.Tohle mi přijde jakože s immutable objekty nemáš moc praktických zkušeností - z jazyků, kde se používají hodně. Protože právě immutable data nemůžou být nekonzistentní z principu, tímhle vůbec není potřeba se zabývat, tenhle problém vůbec neexistuje.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.