PRL Půlsemka opravena
ne vsichni
Zobrazit všechny odpovědi (2)
prisli ti uz body, nebo stale cekas?
porad tam nic nevidim, jeste to vypada, ze 61 lidi neopravili
PRL Dejte někdo z 1. běhu otázky na fitušku
tak to tam nahod, ja se tam v chromu nedostanu ani pres badidea.... nejsem si jistej, jestli to bylo A nebo B, ale mel jsem popsat princip PRAM + obrazek a popsat algoritmus mrizkoveho nasobeni matic + obrazek
PRL
https://docs.google.com/document/d/1J_OnojfTBRs00tPBxZVS7PNNPFBirmC8xv_bpyKw6Mw/edit?usp=sharing
Co kdyz tam narvat jeste teorii z 1 prednasky o Ne-von Neumannovych a von Neumannovych architekturach?
Zobrazit všechny odpovědi (2)
na to uz ti bude muset stacit prednaska, nechtelo se mi to vypisovat :D
Dřív bylo asi 3x zadané (až ve fulltextech od 2014) popsat jednu z ne-von neumann architektur (data flow, redukční), tak na to mrknout ;) Vypisky pekne, gj (y)
PRL kdo nezaznamenal, pulsemka je rozdelena na dva behy první polovina (po xmutna00 včetně) v 16:00, druhá polovina (od xnavra50 včetně) v 17:15 (začátek 17:30).
Len pre istotu. Na polsemestralke bude ucivo z prednasok 1 - 9 (vratane) ?
Zobrazit všechny odpovědi (4)
Nekde tady niz je "upřesnění: po: 9. Algoritmy nad seznamy, stromy a grafy včetně"
Já doufám, že budou vycházet z předchozích let - tedy po PRAM
Nemyslim si ze daji stromy a seznamy, spis bych cekal 1 az 8
Ja fakt nevim :) jen predavam
PRL (Proj 2) To mi vysvětlete, jaké si představují experimenty na ověření časové složitosti u paralelních systémů, když to, na čem to máme testovat, má 12 logických procesorů...?
predpokladam, ze u seba overit narocnost a na merlinovi iba skontrolovat, ci to ide skomplikovat a spustit
Zobrazit všechny odpovědi (2)
No, můj komp má osm logických procesorů...
Daniel Danol Čejchan Kdybys měl zapsaný ARC, můžeš si to ověřit lépe na Salomonu :-) Ale to samozřejmě není nutný, oni s tím počítají, že ta časová složitost nebude úplně vycházet jednak kvůli málo jádrům na merlinovi a druhak kvůli tomu, že na merlinovi ty jádra nemáš pro sebe, ale využívají je i jiní studenti/učitelé (takže se ty různé běhy algoritmu budou časově pravděpodobně docela lišit)...Důležité je nezkreslovat výsledky a popsat v dokumentaci, proč to úplně nevychází ta časová složitost...Předpokládám, že něco v tomto smyslu říkal i na demo cvičení k projektu (alespoň minulý rok to říkal).
Jeste by me zajimalo co si mam predstavit pod "Komunikační protokol, jak si "procesy" zasílají zprávy" .... Procesory si navzajem posilaji zpravy jak je to popsane v algoritmu. Zpravou je vektor cisel. O jaky komunikacni protokol se jedna?
Zobrazit všechny odpovědi (1)
No, asi takto, ty cituješ jen první větu v rámci dané odrážky (na wiki stránkách projektu), přičemž odpověď o jaký protokol se jedná, máš hned ve druhé větě: >>>Komunikační protokol, jak si "procesy" zasílají zprávy. Pro vizualizaci použijte sekvenční diagram (http://en.wikipedia.org/wiki/Sequence_diagram). Nezapomeňte, že protokol musí být obecný, tedy pro n procesů.<<< Tedy pomocí sekvenčního diagramu máš ukázat/vizualizovat (obecně pro n procesů) jak si v čase dané procesy zasílají zprávy. Tímto tedy popisuješ protokol komunikace.
PRL Po jakou prednasku se treba ucit na pulsemku?
po 9. včetně
Zobrazit všechny odpovědi (1)
upřesnění: po: 9. Algoritmy nad seznamy, stromy a grafy včetně
MSZ PRL Zjistil jsem, ze dost lidi nezna souhrn od Veselyho. Je to daleko lepsi na uceni, nez slidy... ale pozor, neni tam uplne vsechno ;).
thank you thank you thank you
PRL Zacinaji nahazovat 1. opravnej
to už začínají od rána
o reklamacích asi žádný info hádám co? -_-
Zobrazit všechny odpovědi (3)
Reklamace budu přijímat ve středu v době svých konzultačních hodin (A306, 10:00 - 11:30). F. Zbořil ml.
Zdenko Brandejs Což se celých nádherných 50 minut kryje s FLP. :D
myslim, že kdo má podobný problém, tak mu Zbořil vyjde vstříc i s jiným časem :)
PRL Rbcast Nevíte někdo prosím, proč je tady volaný deliver(R,m) znovu? Vždyť ta první podmínka `if p has not previously executed deliver(R, m) then` se při rekurzivním volání nesplní - deliver skončí bez efektu.
Imho, jako všechno v PRL, je to pseudokód a chtějí tím naznačit, že v tom místě se konečně ten "deliver" provede.
Podle me se o zadnou rekurzi nejedna. Ty vyznamy jednotlivych radku jsou podle me asi tyto (jen pro deliver): 0. deliver(R,m): -- jen nazev procedury. provadi se vnitrek, neni to volano 1. pokud prijimam zpravu (jako v MPI) tak: 2. mrknu se, jestli jsem tuto zpravu uz nekdy neukladal (abych zachoval jen jedno ulozeni zpravy.) pokud ne: 3. pokud nejsem odesilatelem zpravy m, odeslu ji vsem sousedum 4. tady teprve je samotne ulozeni zpravy m volanim deliver() 5. 6.
Zobrazit všechny odpovědi (6)
Takže první výskyt "deliver(R, m)" značí definici funkce jménem deliver a druhý výskyt "deliver(R, m)" značí uložení zprávy m jako úspěšně přijaté? o.O
Ja bych to formuloval asi tak, ze prvni vyskyt oznacuje blok kodu, kde se metoda deliver pouzije, neni to soucast programu. A druhy vyskyt je teda jeji volani. Tak to chapu ja :D
Podle slide s CBCAST soudím, že `bcast` a `deliver` jsou funkce, protože bcast(C,m) používá bcast(F, m) a ten zase používá bcast(R, m).
*b'cast :D
Pak uz muzu poradit jedine tento matros: https://www.fit.vutbr.cz/study/courses/PDA/private/reliable.pdf Ktery je z private stranek PRL. Ten to snad objasni. (Aspon tu tezce pochopitelnou syntaxi slidu)
PRL Ako sa pls určujú tie PRAM časové zložitosti? EREW etc. ?
Dost dobrá otázka ...
Ja to beru proste jako sportku :D
https://fituska.eu/download/file.php?id=11686
Když máš common CRCW, tak je povolen zápis více procesorů současně, pokud zapisují stejnou hodnotu. Takže věci jako AND, OR, vyhledání čísla, apod. se vyřeší v konstantním čase - každý procesor se podívá, jestli právě on má hledané číslo, a pokud ano, hned ho zapíše. U stejných úloh se ale procesory v PRAM EREW a CREW musí nějak domluvit, kdo a co teda bude psát na výstup - a to má logaritmickou časovou složitost (předávají si to nějak stromem). Takhle mi to aspoň vysvětloval Zbořil na reklamacích (a ještě zdůrazňoval, že XOR nezvládne ani CRCW v konstantním čase).
Zobrazit všechny odpovědi (5)
XOR a sčítanie apod.
aha, cool dík :)
A nevíte prosím jestli se to u toho XORu a sčítání zase nějak zvětšuje ta složitost u CREW a EREW? Nebo už je pak všude logaritmická?
XOR a sčítání mají u všech třech logaritmickou. Stejně jako cokoli dalšího co jde udělat pomocí stromu.
Díky. :-)
PRL Jak se prosím řeší toto: Najít eulerovu cestu dle zadaného stromu
Algoritmy nad stromami, euler tour traversal.
DIKY
hej este je tvoja otazka aktualna? :) treba si urobit orientovany graf, potom tie "linked listy" hran pre jednotlive vrcholy, a potom podla algoritmu ktory je v slajdoch (ak ma naslednika tak ten ak ne tak reverzna hrana) vytvoris ku kazdej hrane akoby pokracovanie v eulerovej ceste. a vytvori sa ti postupnost. mozem to skusit aj podrobnejsie keby nieco pis
Zobrazit všechny odpovědi (2)
Zuzko, díky za osvětlení. :) Ale mohla bys prosím ještě upřesnit ten konec? Chápu po ten algoritmus, ale na slajdu 26 se ztrácím... 1) Nerozumím tomu zápisu "next(e1R=e3) <> nil next(e3)". Co se to snaží říct? Ta čísla éček mi nějak nesedí s tím adjacency listem... 2) Nejsem si jistá, co máme napsat a podtrhnout jako výsledek...?
1) Takto, pod hranu ktora konci v dvojici a ukazuje/retazi sa na dalsiu dvojicu napises prvu hranu z tej dvojice na ktoru sa retazi. Zo slajdu 24 mozes vidiet ze to je pre e1->e4 a pre e2->e5. To je ten pripad na, ktory sa pytas. V podstate next nieje nil. A pre vsetky ostatne kedy next je nil vezmes prvu hranu z dvojice-reverznu. 2) Vysledok je v podstate takto vytvorena tabulka podla mna, pripadne root, ak je zvoleny tu dvojicu spravis aby bola ukazujuca na neho. To je ta tej 28 ta e3->e3. Prosim opravte ma ak nieco nevravim spravne.
PRL Nemáte někdo řešenej ten ABCAST z řádného?
https://fituska.eu/viewtopic.php?f=2026&t=25601
Daniel Dušek: něco tě urazilo? :D
Aleš Procházka: Nope, zapínal jsem si notifikace k tomuhle postu a nějak to ulítlo. :D
Moje řešení
Zobrazit všechny odpovědi (25)
Moc pěkné osvětlení. Tahle fotka na mě působí úplně takovým uklidňujícím dojmem. Do momentu než se do toho začtu a uvědomím si, že jdu na opravnej. :D
Supr..mám to stejně :D
FYI - v tom grafu je špatně délka mezi 3 a 5.. v tabulce potom je to správně (délka 6) pro zprávy od 5, ale pro zprávy od 3 je tam uvažována ta špatná délka 3 ... na zbytek řešení to ale nemá vliv, vyjde to stejně
Byl by někdo ochoten přispět pár slov k tomu jak vymyslím ty čísla v tabulce a následně to pořadí zpráv u procesů?
Modrý čísla jsou časy, kdy dorazí daná zpráva k procesu, která byla vyslána v nějakém čase (třetí parametr zprávy). Po vyplnění všech modrých čísel, si vezmeš jednotlivé řádky, což ti reprezentuje časy, kdy k danému procesu chodily zprávy. Proces zprávám přiřadí priority (černý čísla) podle toho, kdy k němu došli. První zpráva má prioritu 1, druhá prioritu 2, atd. Následně si vezmeš jednotlivé sloupce a vybereš tu nejvyšší prioritu (černý číslo v kroužku), která byla přiřazena. Potom zprávy seřadíš od nejmenší priority po největší. S tím že když je kolize priorit, tak rozhoduješ podle čísla odesílajícího procesu(první parametr), případně podle části zprávy(druhý parametr).
Filip Pokorný při určování pořadí, jak dorazili k procesům už nezáleží na čase? To mi právě není jasné - to označení zpráv pro každý proces mám stejně ale když se nakonec rozhoduje pořadí tak jsou 3 zprávy označeny číslem 5: (1,3,3), (5,1,2) a (3,1,4) tak bych řekl, že první v pořadí bude (1,3,3) proto, že dorazila nejpozději v čas 7 (a ne proto, že má nejnižší ID odesílatele). Když nějaká zpráva všem přijde v čas 100 tak nebude první v pořadí jenom proto, že má nižší ID, ale stejný rank jako zpráva která přišla nejpozději v čas 7.
Na čase nezáleží. Při Atomic broadcast všem procesům dorazí zprávy úplně ve stejným pořadí.
Doporučuji kouknout na tu prezentaci, co byla uploadnutá do datového skladu po písemce. Z ní jsem vycházel.
aha tu prezentaci jsem neviděl, díky
Np, neříkám, že to mám dobře, proto jsem to sem hodil, abychom o tom diskutovali.
A jak je v tomto zohledněno to, že každý příjemce informuje odesílatele o prioritě, kterou přiřadil přijaté zprávě?
To označování zpráv jednotlivýma procesorama mi vychází stejně. Jen mám otázku k tomu " Pro zadané zprávy určete v jakém pořadí budou doručeny v systému ABCAST procesem 3 a 5": Ten ABCAST by měl zaručovat, že to všem bude doručeno ve stejným pořadí, žejo? Takže to pořadí bude pro oba procesory stejné, takové, na kterým se domluvili všechny zbylý procesy tím, jak navrhovali to označení - vybralo se vždycky to největší. (Takže mi to taky vychází stejně, jen chci poukázat na to, že je to takovej chyták, jestli to dobře chápu)
Nemělo by se tam někde objevit ještě D, když příjmence má označit zprávu D poté co aktualiyoval prioritu zprávy?
Já bych je hlavně s těmahle zkratkama a označeníma poslal už někam do píče, z čeho to vůbec pochází a odkud to vůbec vzali? Kvalita jejich materiálů mě prostě nepřestane ohromovat.
nemeli by v te vysledne posloupnosti byt vynechane ty zpravy ktere dorucuju sam sobe? napr pro proces 3 vyhodit (3,1,4) a (3,2,6) a obdobne pro proces 5?
Jordán Jarolím Řekl bych, že z hlediska Validity (vlastnost broadcastu), je správné je nevynechat.
v tej tabulke -> riadok 5, sprava (3,1,4) - nema byť namiesto 7 čislo 10 ? čas z 3 do 5 je 6
Martin DiDi Pristas O 14 komentářů nad Tebou je to zmíněno. :-)
Martin DiDi Pristas, Daniel Dušek Zpráva z 3 do 5 ale přece bude trvat 2 (přes 4), ne? Podle definice Rcastu (https://www.fit.vutbr.cz/study/courses/PDA/private/reliable.pdf) přeposílá každý uzel zprávu dál. Šíření zprávy by tedy mělo být rychlejší 3->4->5 než 3->5.
Martin Vondráček V té topologii jsou všichni spojení se všemi, tudíž bych očekával, že podle toho Theoremu 4.15 (přilinkováno jako příloha) to půjde po tom přímém, i když dražším drátu.
Chápu to tak, že uzel 3 pošle v čase 4 zprávu po všech dostupných drátech. Jenže uzel 4 to obdrží v čase 5 a taky pošle všemi dráty. Tím uzel 5 obdrží zprávu v čase 6. Pak mu přijde znovu v čase 10, ale to už ji ignoruje ("if message m has not been r-delivered yet then"taky podle přílohy).
Po důkladnějším prostudování materiálu Lamport (https://www.fit.vutbr.cz/study/courses/PDA/private/reliable.pdf) to dává smysl, protože u všech typů broadcastů je u deliver zakomponovaný r-deliver (reliable deliver).
Anna Popková tak aky je zaver? :D
Martin DiDi Pristas Myslím si, že má pan Vondráček pravdu. :D Takže dle toho by doražení zpráv pro procesor 3 a 5 bylo v pořadí: msg(1,1,1), msg(5,1,2), msg(3,1,4), msg(5,2,3), msg(1,3,3), msg(3,2,6) Souhlasíte?
Pokud budeme brát tento fakt jako pravdivý, tak mi to vyšlo stejně.
Může to prosím někdo vysvětlit jak postupovat? Nechápu to ani z přednášek ani z toho pptx v souborech. Díky
Zobrazit všechny odpovědi (8)
Autorský komentář k té fotce jsi četl? Já jsem to z toho nakonec pochopil. https://www.facebook.com/groups/1064936046887651/permalink/1340050379376215/?comment_id=1341012589279994&reply_comment_id=1342167479164505&comment_tracking=%7B%22tn%22%3A%22R%22%7D
Daniel Dušek Stále to nechápu :D můj postup je takový (pls o doplnění zbytku): 1. udělám si tabulku, kdy došla jaká zpráva procesoru 2. očísluju zprávy podle čas, jak chodily na daný procesor (tzn mám tu tabulku vpravo včetně těch žlutých čísel) 3. seřadím pořadí zpráv podle priorit na každém procesoru (vlastně jen přepíšu znovu tu tabulku) 4. co teď?
"Následně si vezmeš jednotlivé sloupce a vybereš tu nejvyšší prioritu (černý číslo v kroužku), která byla přiřazena. Potom zprávy seřadíš od nejmenší priority po největší. S tím že když je kolize priorit, tak rozhoduješ podle čísla odesílajícího procesu(první parametr), případně podle části zprávy(druhý parametr)." Chápu to tak, že seřazená maxima udávají "globální" pořadí zpráv tak, aby to splňovalo Total order (viz slidy).
Martin Vondráček Ten konec nějak nechápu, vypadnou mě z toho ty priority v kolečku (3, 5, 5, 6, 5, 6) a tzn tohle seřadím?
Z obrázku vyplývá, že tohle seřadíš s přihlédnutím k číslu procesoru a části zprávy. Netvrdím, že je to 100% správně. Připadá mi to správně.
Jinak teda to řešení, že v 3. a 5. procesoru to bude stejně seřazené je správně?
To je princip atomic broadcastu
Ok díky, snad to chápu :-) udělám tabulku, kdy bude kde jaká zpráva, pridelim priority podle času, vyberu největší z každého sloupce a znovu seradim
Hej tam by sa celkovo na tu lavu tabulku prechodov dal pouzit nejaky algoritmus (100 bodov kto si spomenie aky) ktory vytvori akoby najkratsie cesty....teda napr z cesty 5->3 za cenu 6 urobi 5->4->3 za cenu 2...ci budete to rucne hladat nejako? nebolo to nieco v MATe na konci? sa mi cosi mari
Dijkstruv algoritmus?
Zobrazit všechny odpovědi (4)
jasne preboha dakujem :) to moc komplikujem...som si pamatala na nejaky ten s maticami ale zbytocne bol zlozity aby sa dali pouzit zaporne cisla a cykli ci co
No podle me to je stejně zbytecne :-D prostě si uděláš tu tabulku kdy co přijde a hotovo
Ale zmení ti výsledok ak si najskôr prepises tabuľku na najkratšie cesty a robíš to podľa nej :) tie správy prídu v iných časoch
No v zadani moc takového nebylo :-D
PRL Chápete prosím někdo, jak se lze dojít pomocí postupu k zvýrazněnému poli I-up? Spíše než scan na reverzované pole bitů mi to připadá jako scan, kterej nezačíná od nuly, ale od od poslední hodnoty z řádku I-down a nic se nereverzuje.. Není to třeba nějaký známý překlep?
Jsou tam udelane dva kroky v jednom. Prvni se provede reverzovany scan a pak kazdy procesor provede nasledujici vypocet: Delka pole - Vysledek scanu. Takze to vypada uplne stejne jak kdyby se zacalo od konce s hodnotou velikosti delky a od ni se odecitalo. Avsak minus neni asociativni, takze nelze udelat scan s minus.
Aha, myslela jsem si, že reverzovaný scan je scan na reverzovaným poli a ne scan udělanej reverzně na poli. :D Díky za vysvětlení. :-)
PRL je niekde výpisany termín reklamácií?
Před chvílí šel mail, zítra budou. Řádný termín zkoušky z PRL je opraven o body jsou v systému. Reklamace budu přijímat zítra, tj. ve středu 17. května 2017, 9:00 - 11:00, 12:00 - 15:00, místnost A306. F. Zbořil ml.
Zobrazit všechny odpovědi (1)
Ďakujem na mail som sa ešte nepozrela.
PRL prisli body :)
A byl štědrý :)
A že jak !
nerekl bych
To jsou vždycky kecy :D "to docela čarovali", "docela hledali", "A byl štědrý"
Zobrazit všechny odpovědi (2)
Tak mám jednou radost no :D
nech Karla si to užít, po TINu si to zaslouží :D #13bNeverForget
PRL Vrtá mi hlavou ten pipeline mergesort. Koukala jsem na to po písemce do slajdů a pořád tomu nerozumím. Mate mě třeba krok pět (h003, slajd 22), kde si P2 vybere číslo 4, i když je menší než 7. Můžete mi to prosím někdo vysvětlit?
Já to chápu takhle: 1. procesor ti dává na střídačku prvek nahoru a dolů 2. procesor porovnává prvky v rámci jednotlivé dvojice (každý prvek může být jen v 1 dvojici) a výsledek procesoru P2 jsou seřazené dvojice které dává opět na střídačku (1 uspořádaná dvojice jde nahoru, další uspořádaná dvojice dolů) 3. procesor porovnává prvky v rámci čtveřice (tzn P3 má na výstupu seřazené čtveřice) atd... v tom příkladu je u P2 první porovnávaná dvojice 6 a 4, tzn porovná je, větší (6) dá první a hned za to se dává ta 4 nezávisle na tom, co je na vstupu P2, tzn takhle pak P2 seřadí dvojici 7,8 ...2,3 atd
Zobrazit všechny odpovědi (1)
Už to v tom vidím, díky moc. :)
Pokud jsem dobře pochopil myšlenku tvůrce zadání, měli jsme nakreslit stav v 10. kroku. To znamená ve stavu, kdy všechny prvky byly už seřazeny kromě jednoho, který byl tím pádem před posledním procesorem. Mám pravdu?
PRL Máte někdo, jen tak mimochodem, nějakou bližší představu KDE se to dneska píše?
dobra otazka :-D
http://www.fit.vutbr.cz/study/course-l.php?id=11609
Zobrazit všechny odpovědi (1)
Sekce Rozvrh:
Huh, jasně, mělo mě to napadnout, že to bude na těhle stránkách předmětu. Díky. :-)
to už je dneska?
Zobrazit všechny odpovědi (7)
az 9.5.2017 o 13:00
ok ještě je čas se to naučit :-D
jj este 0.000228159105 roku cas sa to naucit :-D
Kdy je opravný? :-D
25 tusim :-D
Tak to bude slušná Kizomba!
To už je moc pozdě, to už mám prázdniny, to budu muset dát :-D
Jsou tam uvedene 2 mistnosti, tak predpokladam, ze se do nich mame paralelne rozdelit v logaritmicke casove slozitosti. Treba za to budou taky body.
Navrhuji na nadvori sestavit strom a zacit se radit z nej.
Zobrazit všechny odpovědi (3)
jehličnatý nebo listnatý?
Ty algoritmy v prl pracuji s listy, takze listnaty je jasna volba
a kto bude koren?
PRL Nemá niekto ilustráciu pre ten Dijkstrov Token Termination Detection ?
http://people.cs.aau.dk/~adavid/teaching/MVP-10/17-Termination-lect14.pdf
PRL Dokazal by mi nekdo prosim vysvetlit FIFO a CASUAL Broadcasty? Nejak se mi to nedari pochopit. Diky
Fifo - deliver od jednej entity zoraduje, tzn. prv musi prijat spravu od A v 1 az potom 2 Casual - prijme vsetky spravy od vsetkych ale musi ich v tomto poradi aj poslat
pozri h011.pdf je to tam pekne pomocou code
PRL Mohl by me nekdo poskytnout nejake materialy, odkud se ucit Eulerovu cestu a ty algoritmy? Z prednasky to absolutne nemuzu pochopit.
Ono se něco dá rozumně pochopit z přednášek, kde jsou slidy 150 let staré a s chybami na každé 5. stránce? :D
Na pulsemku jsem chapal skoro vsechno, ale toto se fakt neda :D Nejakej typ?
No taky by mě zajímalo :) Snažím se to pochopit ze slidů a pak google/youtube.
možno pomôže toto
PRL Nějaké tipy na noční rychlokurz Occamu a Lindy, pls? :D
u kazdeho si zkus dva priklady za pomoci slajdu a pokud to pujde, tak to umis ;-)
PRL Potvrdil by mi nekdo, jestli tahle tabulka plati jen pro FIFO broadcast? Protoze kdyby to byl kauzalni, tak podle prednasek: "Causal Order: If b’cast of m causally precedes b’cast of n, then no correct process delivers n unless it has previously delivered m", by U5 musel nejprve prijmout b'cast B1.1 nez prijme B3.1, ne? ;)
souhlasim ze to s tim co je v prednaskach nesedi, U5 by mel s D3.1 cekat a provest az po D1.2 edit: neni tomu tak, vysvetleni nize
Zobrazit všechny odpovědi (2)
super, diky! :)
ono taky asi zalezi na tom, co je mysleno tim, ze je to kauzalni vysilani, protoze nikde neni definovane ze zprava 1 -> zprava 3, ale predpokladam, ze to z toho tak nejak vyplyva :D
edit: obrazek je spravne takze U4 by asi melo mit t3 ( D1.1 / B1.1 ) t4 ( D1.2 D3.1 D3.2 / B1.2 B3.1 B3.2) a U5 t3 ( nic) t4 (D1.1 / B1.1) t5 ( D1.2 D3.1 D3.2 / B1.2 B3.1 B3.2 ) aspon myslim, za spravnost nerucim :D
No s tím bych byl opatrný, z jakého důvodu si myslíte, že B1.1 kauzálně předchází B3.1? Podle přednášek jsou 3 možnosti - 1) byly vyslány za sebou stejným procesem - v tomto případě ne 2) jedna z nich je B a druhá D stejné zprávy - ne 3) existuje jiná zpráva, x, taková, že B1.1->x->B3.1 - která by to měla být? S reálným časem "t", kdy byly vyslány, to nemá co dělat.
Zobrazit všechny odpovědi (1)
ja si prave rikal jaky je rozdil mezi timto a total ordering, uz vim
Zprávy 1.1 a 3.1 jsou kauzálně nezávislé, protože jsou zaslány jinými procesory/servery. To o čem tu mluvíte vy, je total ordering (že všechno musí být přijato ve stejném pořadí na všech procesorech/serverech). Řešení tohoto příkladu je správné.
Nemohla by, prosím, nějaká dobrá duše na wiki či sem slovně popsat, jak se k těm výsledkům dá dopracovat? Nějak se mi stále nedaří tomu příkladu porozumět.
Moze proces v jednom casovom okamihu spravit viackrat bcast/deliver? Slidy: "Processor i has logical clock Ci Incremented before every event at i" a potom dalej: "Execution of b’cast or deliver is event"
PRL zacinam mat pochybnosti :D
https://en.wikipedia.org/wiki/Linda_(coordination_language)#Name
PRL Nemá někdo nějaké poznámky k cenám PRAM (CRCW, CREW, ERCW) operací? Případně nějaký systém jak to vymyslet? Něco jako je zde: https://fituska.eu/download/file.php?id=11686 Jen mám pocit, že jsou tam chyby, třeba pro XOR pole jsou tam 2 různé odpovědi...
https://fituska.eu/download/file.php?id=11686
bump, napadá někoho, jak se to intuitivně určuje?
Co jsem zatim pochopila, tak se to určije zejména podle toho, jeslti se o concurrent versi nebo exclusive. například OR u ERCW a CRCW je konstantní, protože každej z těch procesorů okamžitě ví, jeslti má hodnotu true nebo false a ti, co maji true pak můžou zapsat všichni najendou. Pokud je to EREW nebo CREW, tak je složitost logarimucká, protože se musí udělat suma prefixů a musí to teda projít stromem až ke kořeni. Jde ale celkově o úkol, co to má dělat. :/ Jestli se mýlim, tak mě prosim někdo opravte.
Zobrazit všechny odpovědi (3)
je to tak jak říkáš
>například OR u ERCW a CRCW je konstantní, protože každej z těch procesorů okamžitě ví, jeslti má hodnotu true nebo false a ti, co maji true pak můžou zapsat všichni najendou Platí to prosím i u toho ERCW? Když je i exclusive read, nemusí si ty procesory nejprve postupně přečíst tu hodnotu (lineární složitost?)?
To jsem brala jako příklad, kdy už každej z těch procesorů má hodnotu načtenou. Jinak by tam byla u ER ještě myslim logaritmická (když si to předávaj procesory stromově, snad se nepletu) složitost na načtení. Jeslti je to načtený nebo ne by mělo bejt napsaný v zadání.
Hlavně kde se to probíralo? Na přednáškách jsem to nenašla. Máme se to teda naučit z té [Reif] učebnice https://www.fit.vutbr.cz/study/courses/PDA/private/Reif21_PRAMsurvey.pdf ? Tam se to zřejmě probírá na 59 stranách anglického textu no...
Zobrazit všechny odpovědi (1)
on tyhle věci zmiňoval na přednáškách, že je to taková jeho vzpomínka na staré časy, ale že se k tomu není potřeba toho příliš mnoho učit. Jen aplikovat tu teorii
pozastavoval som sa nad tými viacerými rozličnými odpoveďami a došiel som jedine k záveru že sú to testovky, teda nevadí že sú v rôznych prípadoch inak ty musíš vybrať len tie správne. Sedí?
pochopil jsem, že je to každoroční PRAM tipovačka :D Ale některéí věci se dají odvodit podle toho, jak to psala Karolína Hajná
PRL Bude v utorok prednáška?
Nebude. Minulý týden byla poslední.
Zobrazit všechny odpovědi (3)
Fakt? Tak dobre vedieť :) ja som ju bohužiaľ nestihla. Boli nejaké postrehy čo čakať na skúške?
Z první půlky asi jen nějaký algoritmus a pak většinou to, co vyučoval v druhé půli semestru. Myslím, že staré semestrální zkoušky napoví víc.
Byly probrány všechny slidy, co jsou na private stránce, nevíte?