PRL Co znamená přesně suffix seznamu? Když mám seznam (1,2,3,4), tak je suffix 1 seznam (2,3,4) nebo (1,2,3,4)?
Suffix se pocita odzadu prece. Ze skript TINu: u retezce w = abbc je 1)prefixem: epsilon, a, ab, abb, abbc; 2)suffixem: epsilon, c, bc, bbc, abbc.
Zobrazit všechny odpovědi (2)
Já mám na mysli přesně parallel suffix sum algoritmus, kde je suffix definovaný jako: "Suffix – podseznam mezi prvkem a koncem seznamu" A já nevím jestli tam patří ten samotný prvek nebo se to bere až za ním.
Jaj, promin :D Nepochopila jsem :D
Jsou tam vsechny prvky, je to uplne to same co list ranking, jen mas u hran definovane hodnoty.
Zobrazit všechny odpovědi (2)
díky
+ u list rankingu mas vzdycky scitani u sumy muzes mit samozrejme libovolny asociativni operator.
PRL nemá prosím někdo zpracovanou otázku: Distribuovaný broadcast, synchronizace v distribuovaných systémech?
je i na wikifitusce tusim
ajono, dík, já to tam nějak přehlídl...
PRL Nekdo nejak po lopate jak se tvori ten Adjustency list u eulerovske cesty? Z tech slajdu to moc nejde vycist.
Nie je to moje, ale celkom dobre som to odtiaľ pochopil. https://uloz.to/!BgNfHevBcOhI/eulerova-cesta-pdf
Kouknu na to diky.
PRL Prosím, mohl by mi někdo blíže okomentovat tyto dva obrázky? A trochu lidštěji vysvětlit kauzalitu? Úplně tomu nerozumím a nebylo to za málo bodů.
Nikdo nic nepíše, tak zkusím já. Na obrázku "Kauzální?" máš červeně zvýrazněný dvě delivery, který porušujou kauzalitu. Je porušena proto, že první zpráva (od procesu p1) byla odeslána v časovým okamžiku, dejme tomu, t = 1 a druhá zpráva od procesu p3 byla odeslána v t = 2. Tudíž by podle kauzality měly přijít ke všem procesům v tomto pořadí (tedy první zpráva od p1 a pak až zpráva od p3). Ale jak vidíš, tak procesu p4 to přišlo opačně - první zpráva přišla ta, která byla odeslaná až později. A to je to porušení kauzality. Kdyžtak mě PROSÍM opravte.
Zobrazit všechny odpovědi (13)
a jaktože jen ten 4. obrázek vpravo dole "správně" (teda předpokládám, že ty dole jsou opravy chyb z horních), když na procesu p3 přišla zpráva m2 dřív než zpráva m1?
Aneta Kvapilová Myslím si, že už to není relevantní, protože zpráva z m2 na m3 příjde až po broadcastu informací z m3 a tudíž m2 není broadcastována v rámci broadcastu m3. Kdyby tam byl ještě jeden broadcast z m3, tak si myslím, že by to bylo relevantní, ale takto už to je jedno, jestli je šipka před nebo za. Je v tom příkladu krásně vyznačené to zelené pole, kdy toto pole udává, co si máme hlídat.
Ondřej Prda nejsem si jistá, jestli chápu, co tím myslíš.. respektive - to co mi nesedí je ten červený obdélníček.. mluvíme o tom samém?
Aneta Kvapilová Omlouvám se, nebavili O:-). Ja myslel ty odpovědi. Nicméně pro ten obdelník - tyto dvě zprávy nejsou na sobě závislé a odpovědi na ně rozesílá m3 ve správném pořadí. Tudíž si myslím, že by to neměl být problém. Rozdíl by byl v případě, že by šipka z m1 na m4 byla ještě před broadcastem m4.
aháá, takže to neporušuje kauzalitu proto, že ty zprávy na sobě nezávisí.. ale FIFO to stále nesplňuje, žene?
ne, říkám blbost.. ani FIFO to nijak neporušuje, protože nejsou ze stejného procesoru odeslané...?
To je věc, kterou ještě úplně nechápu... jak může nastat, že něco porušuje FIFO a zárověň neporušuje Kauzalitu, když Kauzalita dle toho slidu 44 (pokud jej správně chápu) vychází z FIFO orderu.
Ondřej Co znamená, že na sobě nejsou "závislé"? Nebo podle čeho soudíš, že je to v tom obdelníku správně?
proto, že je poslaly dva různé procesory aniž by je předtím spojil nějaký broadcast? Nevím jistě, myslím..
jj, to mě taky napadlo, ale chtěl bych vidět nějaký zdůvodnění - třeba ze slajdů. Nikde jsem totiž nic takovýho nečetl :D
hmm a tohle "tedy není uspořádání mezi deliver (!!)" ?
Mrkněte sem... přišlo mi to trochu srozumitelnější. https://pdfs.semanticscholar.org/presentation/e1e1/bf6785eec1d9a9b4449be229b0bfa7dbb5ca.pdf
Jaroslav Vystavěl "Nejsou závislé" jsem myslel tak, že to mohou být 2 různé zprávy. Není to tak, že by m1 poslal broadcast na všechny a m4 to posílal jako odpověď na m3. m4 posílá jiný broadcast. Ale tak mohu se mýlit :-)
Co se týče druhýho obrázku, tak červeně označený máš delivery, který porušují FIFO. A porušují ho proto, že se vlastně prohodí pořadí zpráv, který byly odeslány jedním procesem. Např. p4 odeslal zprávu M4.1 v čase t = 1, a další zprávu M4.2 odeslal v čase t = 2. Ale proces p1 je obdržel v opačným pořadí, než v jakým je p4 poslal.
Zobrazit všechny odpovědi (13)
oukej, tomu asi rozumím.. a proč není červeně vyznačené i u procesu p2 (aka druhý řádek) i obrácené pořadí 3. a 4. šipky? Netušíš?
Tam jde o porušení kauzality, že? Což je v rozporu s tím, co je napsáno nad tím grafem. Nevím, možná chtěl jen demonstrovat FIFO, anebo je to prostě chyba.
ano, právě o to mi jde.. jestli je prostě jen vyznačené to FIFO, a zbytek nás 'nezajímá', nebo jestli to opravdu je kauzální a něco mi tam uniká :-/
... protože stejný případ je i v tom prvním obrázku, poslední graf - také jsou ty zprávy doručené naopak
Máš pravdu no. Možná teda chtěl jenom opravit to, co si předtím "zakroužkoval"...ale pak to nemá smysl, když je tam chyba ještě někde jinde.
ale teď si tak vzpomínám - a oprav mě pokud špatně - tak na semestrálce tento příklad komentoval a říkal něco jako že těch chyb tam může být víc a pokud ano, tak si máme vybrat co bude jednodušší na opravu.. nebo tak nějak, ne? Pak by asi odpovídalo to, že jsou v těch obrázcích opravené fakt jen ty zakroužkované věci..
Neříkal jen, že si máme vybrat jednu vlastnost, kterou ten graf nesplňuje, a opravit ji? To bych teda chápal tak, že máme opravit všechny výskyty, který jsou v rozporu...Anebo jsem prostě neposlouchal :D
hmm, je to možné.. :-/ každopádně jak to je s těmito obrázky by mě stále zajímalo! :D
To i mě :D
Tam není porušená kauzalita, podle mě je to stejný případ, jako na prvním obrázku. P4 ještě neví, že před ním byl P1. P4 proto může M4.2 doručit. Kauzalita by byla porušena, pokud by P4 přijmul M1.2 před broadcastem M4.2.
Martin Zemek Možná tě jen nechápu, ale řešili jsme tenhle červenej rámeček. I tenhle případ neodporuje kauzalitě?
Jaroslav Vystavěl přesně to jsem popisoval.
aby to nebylo kauzální tak by to muselo vypadat takto(na prvním obrázku je to zvýrazněné zeleně):
PRL reklamace Nevite prosim nekdo neco o reklamacich?
Zatím taky čekám na email, nebo nejako zpravu, ale vypada to ze se k nicemu neschyluje :D
... a body jsou v systému. Reklamace budu přijímat ve středu od 10:00 do 11:30. F. Zbořil ml.
Teď rozeslal
PRL První várka bodů ze zkoušky. (nikdo nedostal Ačko zatím :D) EDIT: 2 áčka
už tam jedno je!!
Někoho seriózně zajímají Áčka?🤣
Zobrazit všechny odpovědi (4)
To asi ani ne, spíš je zajímavé, když není žádné :D třeba v BMS minulý semestr nebylo po třech termínech ani jedno
Jan Pawlus aha a to je tím, že je BMS fakt těžký? Mám to zapsáno na příští semestr tak se raději ptám
Martin Urbanczyk asi bych to shrnul tak, že je to klasická "hanáčkovina". Přednášky docela zajímavé, výklad super, projekty nic extra lehkého ani složitého, ale jakmile se máš učit, tak slajdy bez výkladu jsou úplně k ničemu a jiné materiály klasicky nejsou. Plus na zkoušce se vždycky snaží dát aspoň jeden příklad, co byl zastrceny v nějakých bočních slajdech. Žádné áčko a dvě béčka, to mluví samo za sebe. :D ale když ti nejde o známku, tak to není taková hrůza. Hlavně je to informacemi podle mě hodně zajímavý předmět, ale to je subjektivní samozřejmě
Jan Pawlus supr, díky za info
PRL Body
jen pulka
Kdyby půlka :D
Zobrazit všechny odpovědi (1)
Tak pokud dojde ještě druhá půlka, jsem v klidu :D ta polovina co mám, mi ale nestačí...
PRL Nepadly na poslední přednášce nějaké tipy co se s největší pravděpodobností objeví na 1. termínu?
PRL
https://docs.google.com/document/d/1-LPnTVt7ETOhRTbHM90ELF4YRQ_ST96L8zzU_s9kOqM/edit
PRL Zdravím, může mi někdo napsat posloupnost slajdů co se probíhaly na přednáškách po půlsemce? Vím, že první bylo MPI co je ve wisu, ale v tom dalším mám nějaký zmatek.
Též bych to potřebovala upřesnit. Na 7. přednášce bylo MPI, na 8. přednášce se asi bralo vzájemné vyloučení, určitě se braly semafory a monitory, na 9. přednášce bylo předávání zpráv. Brala se i synchronizace v distribuovaných systémech, paralelní a distribuované algoritmy a tuším i přednáška 5: vyhledávací algoritmy...
PRL proj3 Zostavujete nejak ten orientovaný graf paralelne alebo to robíte všetko v jednom procese?
Vůbec ho nesestavuju, jen ho naposílám s odpovídajícími tagy do procesu 0, který to vypíše, jak mu to přijde.
Myslím pred tým, než začneš robiť preorder. T.j. či zostavuješ EL (Edge List) v procesore 0 alebo paralelne.
Aha, paralelně
Mohol by si ma, prosím ťa, naviesť, ako na to?
Prostě jsem si ty hrany správně očísloval a pak se pro každou spočítá pozice a orientace z čísla hrany
Díky moc, to mi unikalo. A nájdenie následníka danej hrany si predpokladám tiež zistil z indexu, že?
Zobrazit všechny odpovědi (1)
Jj, následníka taky podle indexu. Stejně jako přilehlé uzly a předchůdce kvůli posílání zpráv druhým směrem
paralelne lze udelat sestrojeni eulerovy cesty (kazda hrana zjisti sveho naslednika), a suffix sum (i list ranging - pokud ho potrebujes, i preorder ranking). algoritmy na tohle jsou v prednaskach, akorat si je musis upravit aby davali smysl pri posilani zprav,namisto sdilene pameti. Sestrojeni adjacency listu asi paralelne nejde, vypis vysledku nejde paralelne urcite
Prosím vás, vedeli by ste mi ešte poradiť, ako riešiť suffix sum? Zasekol som sa na tom, že neviem zistiť, kto sú moji predchodci, aby som im mohol zaslať svoje hodnoty.
Stejně, jako zjistíš následníky. Alternativně je možné v recv specifikovat, že přijímáš od kohokoliv, ale pak musíš pořešit ty, co předchůdce nemají
Tam som sa presne zasekol, že neviem ako zistiť, že nemá čakať.
Poslat mu -1 z posledního?
ja jsem to udelal tak ze si kazdy procesor pomatuje sveho naslednika i predchudce, a oboje se preposila (naslednik predchudci, predchudce naslednikovi), -1 znaci ze uz nema predchuce/naslednika, takze nebude posilat/cekat
Díky moc za rady. Ak by sme sa niekedy stretli, tak si odo mňa pýtajte pivo. ;)
PRL proj3 Dokázal by někdo říct, když pole Etour je (podle mě) správně udělané, proč ten zbytek nevychází?
Musíš prerušit v kořeni, etour pro e3 bude e3.
Tak ale to mi v tomto případě nic neovlivní, suma suffixů bude pořád stejná
Tu sumu suffixů počítáš špatně (podle mě). Nevím, jak si k tomu došel, ale mělo by to vyjít: 41103322 (indexování stejné jako máš ty). Korekce pak vymaskuje ty hrany, které nejsou dopředné (kde není ve weight 1). Tudíž tam zůstane: 40103020 a taky otočí pořadí: 00301020 Nebo pokud chceš indexovat od 1: 10402030 V podstatě ti suma suffixů říká (v tomto případě) kolik má hrana před sebou dopředných hran (včetně té dané hrany, pro kterou to počítáš) při průchodu eulertour :).
Zobrazit všechny odpovědi (3)
Díky, už to vidím že to tam mám blbě vyřešené :)
nema byt suma nahodou: 41103221 jak ti to mohlo vyjst inak Honzík?
Filip Bajaník Měla, bral jsem to jako překllik
Počítáte suffix sum podle toho, co říkal v přednášce u přiřazení pre-order (slide 32), nebo podle toho suffix sumu na začátku přednášky (slide 7)? To jsou dve různé věci a nevím, co z toho teda mám použít.
PRL proj3 ahoj, jak řešíte experimenty u tohoto projektu?
Asi to budu řešit stejně jako u 2. projektu :)
Zobrazit všechny odpovědi (2)
no tam prave byla moznost srovnavat cas na 1 CPU = sekvencni neparalelni razeni vs zbytek = paralelni, kdezto tady neni, hodlas si teda jeste udelat klasickej preorder = srovnat namereny casy v projektu s casama nepralelniho preorderu?
Takhle jsem nad tím nepřemýšlel, ještě to budu muset promyslet.
Mam popsanou teoretickou slozitost podle prednasek. Pak mam popsanou implementaci a casovou slozitost implementovaneho programu. Pak poslu X vstupu, podivam se jak dlouho trvali a reknu: "Namereny cas odpovida ocekavanemu casu, popsanemu v kapitole 'implementace' ale neodpovida teoretickemu, popsanemu v 'analyza algoritmu' protoze ..."
"Vzhledem k tomu, že byl paralelní algoritmus testován na stroji s osmi logickými procesory (což je velmi málo), měla by mít skutečná časová závislost spíše charakter ceny, tedy kvadratický. Nicméně v krocích algoritmu sumy prefixů postupně ubývá počet aktivních procesorů. S přihlédnutím na tyto okolnosti je zřejmé, že naměřená data nemají žádnou vypovídající hodnotu."
Zobrazit všechny odpovědi (4)
Můžu se jen zeptat, proč je cena kvadratická?
Protože složitost algoritmu je vzhledem k tomu, že se na konci posílají všechna data do jednoho procesoru, lineární. A běží to na lineárním počtu procesorů. Tedy, když zpracováváš lineární počet procesorů v lineárním čase na počítačí s jedním procesorem (8 je skoro jako jeden), máš kvadratický čas.
A když pomineme reálnou složitost, teoretická je n*log(n)?
Teoretická je log(n) pro tu část s preorder, ale potom to musíš vytisknout v lineárním čase
PRL proj2 Nepsal jste někdo e-mail ohledně reklamací? Nebo nemá někdo nějaký info?
PRL projekt 3 Čaute, někdo kdo už má projekt 3 rozdělaný/hotový a měl by trpělivost odpovědět mi na pár otázek?
Klidně napiš pm
PRL body z projektu
byvaju aj nejake reklamacky?
jaj, způsobil jsi mi mini infarkt když jsem viděla, že se mi nezměnily body... Jenom část lidí je opravena
Zobrazit všechny odpovědi (1)
jo, taky nemám zatim nic
Trochu mě mrzí, že nejsou schopní napsat aspoň jednou větou, proč něco strhnul. Neřekne to moc, ale přece něco.
PRL jelikož privátní stránky se rozhodly vypovědět službu tak sem nahrávám slajdy potřebné pro projekt
PRL Ahoj, nemá niekto stiahnuté slajdy k prednáške Algoritmy nad seznamy a grafy? Nefungujú privátné stránky.
mas pm
Zobrazit všechny odpovědi (1)
můžeš mi je taky prosím poslat ?
PRL Vytvoření Euler touru mi na slidech přijde naprosto nesrozumitelné. Můžete mi doporučit něco, z čeho by se to dalo pochopit?
Ty materiály jsou fakt k pláči :D . Tady jsem sesmolil postup, jak tomu rozumím já. Není z toho vidět, kde a co se tam má řešit paralelně, ale to je zrovna věc, která už se pak ze slajdů vykoukat dá. http://www.uschovna.cz/zasilka/XWNGBU7JDRE5RFGS-CID/K8IC6ZPVFF
Zobrazit všechny odpovědi (4)
mohol by si to nahrať ešte raz, prosím?
Ondřej Fabiánek taky prosím o reup
Ajo, jsem si neuvědomil, že tam je omezený počet stažení. Až přijdu z práce, tak to reuploadnu jinam.
https://uloz.to/!BgNfHevBcOhI/eulerova-cesta-pdf
https://www.fit.vutbr.cz/study/courses/PDA/private/Reif02_SaraBaase.pdf na konci je euler tour tiez nic moc ale lepsie ako slidy
PRL Ví někdo, jak v projektu implementovat v MPI suffix sum? Všechny způsoby, které jsem zatím vymyslel naráží na to, že daný procesor neví, jestli má čekat, popřípadě kolik zpráv má obdržet a podobné problémy
Zpráva
Zobrazit všechny odpovědi (12)
Můžu taky poprosit o popis fungování algoritmu suffix sum? Z přednášek a z materiálů nejsem schopný vymyslet, co to má vlastně dělat. Díky.
Jestli nerozumíš tomu algoritmu jako takovému, zkus se mrknout na záznam (mám u sebe nějaké studentské záznamy, můžu uploadnout)
To by bylo super.
Až to někam nahodíš, pošli mi pls link do zprávy :)
Hosi, take budu vdecen, kdyz mi nekdo posle odkaz, dikec
Taky bych poprosil o nějaké materiály/nakopnutí, z přednášek si to nepamatuju a z těch slajdů to nemůžu vyčíst jak to funguje.
tiež by som sa potešila linku :)
Prosím, škemrám, mně taky :)
Taky prosím
Co tak to hodit sem :)?
Aj ja poprosim link :)
https://mega.nz/#!COJXWYKI!huI6rkWi15njQpXFCWlxmipd73_pUpUnB6ncHi9snN8
Můžu se zeptat, jak jste to vyřešili? :) Princip algoritmu chápu, mám zatím implementováno tak, že si před začátkem cyklu v suffix sums získám v každém procesoru všechny weights a pole succ. V každém cyklu přičtu novou hodnotu z následníka a nastavím si dalšího následníka. Pak nové hodnoty rozdistribuuju všem procesorům. Problém ale vidím v tom, že samotná distribuce hodnot má složitost (pokud se nepletu) log n, počet cyklů je log n, tudíž výsledná složitost bude log^2 n, což potom není optimální. Pokud bych si od každého procesoru vždy získal novou hodnotu a jeho následníka, tak nevím jak určím kolik daný procesor dostane zpráv. Budu rád za každý nápad :). //EDIT: vyřešeno.
Zobrazit všechny odpovědi (4)
Ako sa ti to podarilo vyriesit? Moj sufix sum ma stale casovu zlozitost n*log n nech vymyslam jak vymyslam, inak to cez MPI_Send alebo MPI_Recv neviem.
A myslíš tím teoretickou nebo reálnou složitost? :) Co přesně děláš v tom cyklu v suffix sums? :)
Honzík Stratil Kazdy procesor posiela kazdemu svoju hodnotu a svojho nasledovnika
Martin Kocour Lze to upravit, že se budeš pouze ptát na hodnotu a následníka tvého aktuálního následníka (snad je to pochopitelné). Potom si aktualizuješ následníka a zase se budeš ptát v dalším cyklu jeho. Není potřeba si udržovat všechny informace všech procesorů.
Mozna je to blby dotaz, ale radsi se zeptam. V tomto stromu kazdy uzel je reprezentovan vlastnim procesorem, ze? Takze kdyz na vstup dam ABCDE, tak musim pustit ten ptorgam s prepinacem -np 5, ze?
Zobrazit všechny odpovědi (1)
procesor se mapuje na hranu, takže 2n-2 procesorů
Mate to implementovane tak, ze kazdy procesor ma namapovanu hranu podla jeho id? Ak sa to naimplementuje tak, ze kazdy procesor v poradi ma namapovanu hranu podla ETour tak v tom pripade sa da vypisat preorder aj bez implementacie SuffixSum. Moze niekto vysvetlit preco sa to musi implementovat takto "slozito"? :D
Zobrazit všechny odpovědi (2)
Asi abychom si vyzkoušeli tu těžší část, suffixSum :D
Ja som ten suffix sum spravil tak ako vysvetloval na prednaske a pri vypise preorderu ho mozem pouzit ale aj nemusim a aj tak mi to da spravny vysledok :D
PRL Zdravím, dle fóra musí procesory umět zpracovat čísla i když nejdou dělitelné počtem procesorů. Jak to řešíte?
Doplňuji MAXimy do dělitelného počtu, a po seřazení jenom vypisuji původní počet prvků v posloupnosti.
Doplním nulama, aby byl počet dělitelný. Na konci stejný počet odeberu a je to :)
zajímavá řešení, děkuji
neviem, či je to ešte aktuálne, ale vždy si pred spracovaním prepošlem počet prvkov a až potom samotné pole. nakoniec pošlem späť rovnaký počet.
Co najviac symetricky rozdelim medzi kazde CPU, a priradim mu pocet prvkov, ktory ma jeho sused, potom uz kazdy vie kolko ma ocakavat.
prvky/procesory = pocet prvku na procesor prvky%procesory = pocet procesoru, ve kterych bude o 1 prvek vic.... vytvori se prislusne velky vektory a vzdycky predtim, nez se kamkoliv poslou, se prvne odesle jejich velikost
Pomoci round na cela cisla ziskam pocet pro kazdy z n procesoru a zbytek zustane pro posledni procesor. Takze pro 15/4 mam 4 4 4 3. Musi se to ale zohlednit i behem zpracovani, takze musim posilat vzdy novy pocet a reist alokaci. Pokud by totiz bylo treba xxx 5 1, tak po rozdeleni dostanu 3 3.
Posledni procesory maji jiny pocet prvku. Pri rozesilani si ukladam do sdileneho vektoru na index procesoru pocet jeho prvku. EDIT: better wording
Zobrazit všechny odpovědi (4)
co když je méně hodnot než procesorů?
Dle fóra máme očekávat, že tento případ nenastane
a co třeba stav 6 procesů, 8 hodnot?
v takovem pripade budou mit posledni procesory vic prvku. (1-1-1-1-2-2)
Ako zistujete priestorovu zlozitost? asi Valgrind? V dokumentácii to chcú.
Zobrazit všechny odpovědi (1)
v dokumentaci mam popsanou jen teoretickou slozitost... realny data mam jen pro casovou slozitost
PRL Proj 2: Jak děláte ty experimenty na potvrzení teoretické složitosti? měříte to nějak? Jak? doba běhu mi nepřijde jako úplně přesný měření.
chrono::time_point na dvou místech a rozdíl
MPI_Wtime
std::random()
Zobrazit všechny odpovědi (2)
až tak, jo? fakt vám to taky háže takový kokotiny? :D
No od té doby, co jsem přešel na random, tak se to dost zlepšilo...
Došli jste k nějakému řešení nakonec? Pokud ne, tak mi Danielovo řešení vážně přijde nejlepší :D
PRL proj1 Ahoj, zkoušel jste někdo řadit více hodnot jak 2^16 (S jedním procesorem, v případě více procesorů, je potřeba překročit hodnotu p*2^16) ? Pokud ano, jde vám to normálně seřadit? :) Řazení mi normálně funguje do max. počtu hodnot 2^16, jakmile ale tu hodnotu převrším, program se zasekne na prvním MPI_Send s posíláním pole o této velikosti. Je na tom někdo stejně? Případně vyřešil někdo tento problém (už jsem nějakou chvíli googlil, ale bez úspěchu). Díky
použi aspoň jedno volanie ako neblokujúce (Isend alebo Irecv)
Zobrazit všechny odpovědi (1)
Díky moc! :)
Docela sranda, měřil jsem sekvenčně složitost std::sortu a připadala mi docela lienární :D
jakoze vazne myslite, ze budou generovat az takovyhle bomby jako 2^16 hodnot/procesor? ... :D
Zobrazit všechny odpovědi (1)
Určitě ne. Podle Wiki budou ke spouštění našeho programu používat připravený skript. Ten (opět podle Wiki) připraví soubor numbers, například čtením ze /dev/random. Přečíst 4000 bytů z tohoto souboru mi na merlinovi zabralo asi 10 minut, takže osobně očekávám testy, kde počet čísel bude v řádu desítek.
2^20 bylo baseline a pak jsem pokračoval až do dvacetinásobku. Nebyl problém.
PRL Půlsemka opravena
ne vsichni
Zobrazit všechny odpovědi (3)
prisli ti uz body, nebo stale cekas?
porad tam nic nevidim, jeste to vypada, ze 61 lidi neopravili
ani ja este nemam...
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