Unsolved - cpuchange - pro 16K read je ten cas se sdilenou a nesdilenou l2 stejny - odpoved asi v dalsim odstavci - co to dela s tou L2 cache kdyz prepnem na L2 sdilene cpu? - exclusive pristup? - idea: kdyz se dela preplanovani tak ma cpu celkem dost casu a asi nesaha do pameti takze l2 cache si usmysli ze kdyz neni vytizeny bus tak by mohla ty lines ktere jsou dirty hodit do pameti protoze je tam stejne tak jak tak bude muset dat - evikce kdyz nemisujem? - je to videt jen po preplanovani na jine jadro - idea: co takhle ta idea co je vyse plati jen kdyz se s tou pameti uz nepracuje ten kdo ji vlastnil (uz neni na cpu) - v podstate kdyz jsme stale na jednom jadru tak se ta evikce nedeje ale kdyz zmenime jadro tak si CPU rekne ze z L1 cache to zmizelo tak to muzu hodit do pameti protoze uz to asi nikdo potrebovat nebude - tady ta idea ma ale trhlinu ze nemodifikovanych line se vyhazuje ohodne vice nez modifikovanych - pingpong - na 64 bit neni rozdil mezi zarovnanym a nezarovnanym - na toto asi zatim kasli - kdyztak zkus rozchodit PAPI na 64 - nezarovnany (shared) jede na kazdem core jinak - tohle bych svedl na implementaci MOESI :) - binarka s PAPI dava jine vysledky na zacatku a konci cache line - mas spec cykl pro PAPI a spec pro RDTSC aby se to ovlivnovalo co nejmene a stejne... - uz jsi zkousel naalokovat 4K pamet a posunout pristup o 1K dale - nic - zkusil jsi vymazat ostatni benche at se to trochu jinak slinkuje - nic - koukal jsi se na asm a nic zvlastniho si nenasel - ten kod pro cteni je kratoucky - pokud zjednodusime cyklus a dame rdtsc i PAPI dohromady tak pak ma PAPI hodne velky vliv na RDTSC a binarka s PAPI dava uplne jine vysledky nez ta bez PAPI - !!! na intelech toto jede v poho Solved - ted se meri nejdrive RDTSC a potom PAPI - takze kdyz PAPI napr. thrashuje L1 a pak rika ze je tam hodne L1 missu tak to vubec nemusi platit pro RDTSC - prodcons - druhe cpu ktere data potrebuje si je asi cte na sbernici ? - to by odpovidalo -> kdyz tam je write tak to je rychlejsi (data se musi zapsat) - tohle ale plati jen pro stejny procesor - proc? - to by mohlo byt tim ze ruzne CPU nesdili BUS tudiz tam nema co videt - kdyz to cte z pameti tak tam jsou stejne rozdily - ale to bude pro to ze neco jeste v cache stejne je tak to zhodi ten prumer - kdyz to cte z pameti tak tam jsou stejne rozdily - ale to bude pro to ze neco jeste v cache stejne je tak to zhodi ten prumer - pingpong-lock - hypoteza je ze cpu si kazda neco dela a na vecech jako lock se musi dohodnout, coz nejakou dobu trva - memspeed - pri >= 128MB se nam zacne zvetsovat cas pristupu do pameti - je to hodne videt pro memspeedrg - ze by TLB? - nejdrive to jeste pobere z cache ale pak uz ani ta nestaci - ale jak to zmerit kruci? - jinak TLB ma asi 1024 zaznamu coz by nas zlobilo nekde u 4MB - toto je tim ze nam uz strankovaci tabulky prelezou i cache takze i pro strankovaci tabulky musis do pameti - pingpong - na intelech neni poznat rozdil kdyz jede read x write do sdilene a do nesdilene - nejspise se zapis nepropaguje - memory ordering - malo pristupu do L1 caches pri PAGE WALK - spec page table struct caches u intelu - scthrash - proc v memspeed1-thrasher1:nopCount-001-P-L2_M_LINES_OUT.ANY.png leze ven tolik modifikovanych line - no to je protoze u thrasheru warmup neprojede celou cache - a ty data jsou od initu modified takze pokud se nevyhodi z cache tak se stale povazuji za M i kdyz je pak v testu jen ctem - trapi nas, proc na grafu memspeed1-trasher1:nopCount-011-P-L2_LINES_IN.SELF je jen 70% misses ! nemelo by missovat vsechno ? * nemelo protoze tam je prefetching ktery nam fetchne i druhou cache line - proc je rozdil mezi trasher1.nopCount-003-P-L2_M_LINES_OUT.ANY a L2_LINES_OUT_ANY (bez M) ? Muze to byt prefetching ? * muze - sice maly protoze do pameti se chodi malo ale je tam - cpuchange (producer x consumer) - neni warmup - to znamena ze pokud mame nejak cache nainicializovanou tak to je vse co dostanem - problem je napr. kdyz se inicializuje jen co se vejde do L1 tak ty data v L1 budou dirty - M state request do L2 - to bude asi pro to ze po inicializaci jsou tam ty data M - co to dela s tou L2 cache kdyz prepnem na L2 sdilene cpu - pristup na shared? - to by mohlo byt PAPI a sdilene framework data atd. - sharedcache-slow - proc v memspeed1-thrasher1:nopCount-001-P-L2_M_LINES_OUT.ANY.png leze ven tolik modifikovanych line - no to je protoze u thrasheru warmup neprojede celou cache - a ty data jsou od initu modified takze pokud se nevyhodi z cache tak se stale povazuji za M i kdyz je pak v testu jen ctem