TODO - hned

 - pred commitem frameworku (at to mas na ocich)
  - otestuj vsechny pridane vetve
  - prekontroluj ze pridavane new([]) maji delete([]) a delete ustoji exception
  - nemas tam zadne TODO
  - mas naupdatovanou template
  - mas dodelane doxy komentare

 - zlepsit dokumentaci
  - znovu projit dokumentaci
   - kontrolovat resulty
   - nedokumentovane tridy zdokumentovat
  - ke vsem metodam co hazi vyjimky to taky napsat...
   - a napsat k nim throw (jaka except) pokud to pujde
   
 - zmensit overhead PAPIwrapperu (nejake optimalizace by tam sli)
  - hlavne metody start/stopSampling a readEventset

 - pro AMD udelat revizi eventu zda jsou nastavovane vsechny flagy jako u Intelu

 - tests

  - resutls vyhodit ven do results.txt

  - popis
   - 010-sharedcache-thrash
   - 011-cachemapping
   - 013-prodcons

---

 - NUMA - pozdrz
  - asi se s ni setkame
  - meli by jsme zmerit jak dlouho trva prisoupit na pamet kdyz je "blizko"
    a kdyz je "daleko"
  - taky zmerit zda saturace jednoho bussu ovlivnuje ten druhy
   - novy numa test -> pouzijes pingpong tak ze udelas read do shared memory
     ze dvou cpu -> jeden to musi mit dal nez ten druhy

 - SPEC_CPU - pozdrz
  - !!! jeste rozmyslet
   - neslo by se pomoci papi hooknout primo na ten proces
   - tim by nam zbyl jen problem se startovanim
    - tedy presne s jakymi param ho spustit (a taky koho vseho)
    - jinak vse ok
  - uprava benches
   - upravit makefile ktery nevygeneruje binarku ale jen balik ocek ktere
     prilinkujem k ripu
   - script ktery projede vsechny spec benche a main prejmenuje na
     mainJmenoBench a prida tam macro ktere zaregistruje benchmark pro beh
   - chtelo by to i script ktery udela fake na vsechny benche a pak je posbira
    - neumi toto uz ty spec tooly?
   - musi se nejak vyextrahovat ty run parametry z logu a vypsat asi do file
     specialniho file ktery bude pro rip
  - spousteni benches (spec benchmark v RIPu)
   - spousti se metody zaregistrovane makrem
   - pred spustenim benchmarku se udela cd do dir kde bude mit pripravena data
   - tam kde jsou data bude take specialni file ktery popisuje jak (s jakymi)
     param spustit test
    - to se bude muset nejak rozparsovat a predat novemu main
   - udelat spec vypisovani vysledku at vime jaky benchmark s jakymi param bezel

--- na rozmyslenou

 - ping-pong
  - asi vubec nezkouset vuci nejake normalni aplikaci a zustat jen v teto
    testovaci rovine
  - divne vysledky u starsich mereni zatim nechat byt
   - uvidime zda se objevi znovu

 - memspeed
  - ruzna intenzita pristupu? - tady asi ne - to uz mas multi pointerem
  - zkusit i beh po nezarovnane pameti?
   - potom ale nemuzem zkouset zapis takze asi ne
  - pokud budes chtit zkouset proti normalni aplikaci tak to delej tak
    aby to co nejmene thrashovalo
   - ale to nevim jak udelas protoze L2 je indexovana fyzicky a to nemuzes
     moc ovlivnit
   - takze ti to bude spis thrashovat -> takze asi ne na to mas thrasher

 - filespeed
  - zkouset vubec nesouvisle soubory?
   - uz byli testovane v ramci RIBu
   - a kdyz ctes vice souboru na jednou tak to mas cteni z vice mist
    - ma cenu to jeste komplikovat nesouvislosti?
   - pokud ano tak budem muset nejake vytvorit umele
   - pokud by jsem brali soubory z write-dual tak budou soubory pokazde jine
  - zkusit O_DIRECT?
   - je to uz hodne neprirozeny zapis - asi ani nezkouset
   
 - je cache virtualni? - test
  - !!! neni treba testovat na intelech protoze ty jsou 32KB a 8 cest takze
        tam se nic aliasovat (evictovat) nebude -> to se stihne v jednom setu
        a na AMD to meril RIB
  - pokud je tak musi pri missu checkovat ze nejaka dalsi virtualni adresa neni
    namapovana na nasi fyzickou protoze pokud by ji tam dal znovu tak zapis
    do cache na jine mista bude znamenat zapis do fyzicke na stejne a to je
    divne -> jak by pak evictoval
  - takze musi evictovat hned pri missu
   - bude o jeden zapis do pameti pod (L2) navic (pokud je samozrejme dirty)
  - to by se snad dalo otestovat :) - counter na to
   - pokud se nam povede namapovat 2 virt na 1 fyzickou
  - staci jen jednojadrovy test (alespon pro L1)
    - pokud L2 sdilena neni tak by se mohl zkusit zvetsit prostor za rozsah L1
      tak do poloviny L2
     - L1 bude eviktovat vzdy a L2 by nemela pokud neni virtualni
    - pokud je L2 sdilena tak je blbost aby byla indexovana virtualne

TODO - ne nutne hned

 - level logovani
  - udelat
  - moznost zadat z prikaz radky

Poznamky k impl

 - pridani sloupce do vysledku
  - udelat podobne jako bylo drive papi
  - budou se zase muset upravit *RDTSC makra aby umela vice veci
  - spis bych volil moznost nize...

 - pridani nesloupcovych hodnot do vysledku
  - stejne jako je ted papi

 - resume
  - pokud chces spolehlivost tak si udelej chcecksum rip.ini
  - uloz ho do rip.resume a pokud je pri resume jiny tak odmitni resume

 - delka jmena soboru
  - hodne param v benchmarku - zacni resit az to bude aktualni