Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Takže se jen oficiálně potvrzuje to, co už jsme věděli, nebo ne? Btw. ten 3-kanálový řadič je teda podivnost. Ty násobky 3 se mi vůbec nelíbí :) IMHO to ale bude fungovat i ve dvoukanálovém zapojení.
Spominam si, ako jeden Intelak hovoril nieco v style "AMD si od nas zoberie [cosi] a my od AMD zasa pamatovy radic v CPU"...
Prestoze chovam sympatie k jednomu z vyrobcu CPU, integrací pametoveho radice vyhraje uzivatel! Nejlepsi by bylo, kdyby na trhu byl jeste treti silny hrac zprznene architektury x86. Takto pouze dotvari podil na trhu procesoru firmy Sun, ibm, sgi, ti, sony apod.
Jinou moznosti konkurence je presvedcit vyrobce operacni(ho|ch) systemu, aby je delali multiplatformni. Pak moji mamince bude jedno, jestli ji windows behaji na sparcidlech nebo jinych krevetach.
zaujmalo by ma ako funguje inclusive L3 cache... pokial sa tam bude mirrorovat L2... neviem si dobre predstavit ako to bude fungovat, L2 je (by mala byt) rychlejsia ako L3 a tak sa tam teoreticky nebude stihat mirrorovat. Alebo sa to da pochopit tak, ze rychlost L2 bude umelo znizena, alebo? viete niekto ako ten mirroring funguje?
DIK.
2 sedgar: Tipuju, že je to z důvodu, kdy jedno jádro potřebuje šáhnout do L2 jiného jádra - nebude muset žádat o data z L2 toho druhého jádra, ale načte si je přímo z L3. Ale jen tipuju.
to goro: jj je to tak... len mi nejde dohlavy ako zladia rozne rychlosti L2 a L3... teda ak su rozne... minimalne by mali mat inu latenciu, frekvencne budu mozno rovnake...
ono to neni tak, ze by se naplnila L2 a z ni se delala kopie do L3, ale naopak, takze zadny problem, imho
Dalibor_ : joo, pekny sen :-) a ted supky do reality. Pokud by chtel nekdo treni delat x86 CPU, tak je uz predem mrtvy jenom z licencnich poplatku. AMD a Intel maji dohodu, legalne ma pak instrukcni sadu jeste VIA, ale ta se zameruje krapet jinam. Co se tyka uplne odlisne platformy to je nerealne kvuli cene. Nejde o CPU, to je celkem legrace, ale o cely zbytek komponentove infrastruktury, ktery je u jinych platforem nasobne drazsi (proc asi jabka presly na x86, ze). Jedina alternativa v tomhle smeru jsou snad herni konzole.
to xyz: hmmm ja to vidim takto:
1. cpu pocita... vyuziva L1
2. ked ju naplni zacne pouzivat L2, L2 mirroruje do L3
3. ak nejake ine jadro potrebuje sahnut na data, ma ich v L3 a presunie si ich do svojej L2...
bod 3 je jasny, lenze to by bol mirroring L3 do L2... mna zaujma ako je vyrieseny bod 2.
Len pre uplnost predpokladam ze po naplneni L2 jadro vyuzie aj nemirrorovanu cast L3 a az potom ide do ram...
inac neviete ci je mirrorovanych (rezervovanych) vzdy 256kb odhliadnuc od mnozstva dat ulozenych v L2, alebo iba obsadena cast L2?
ad L3 mirroring: podla mna to nie je take jednoduche... predstavte si ze dve vlakna zacnu naraz modifikovat tu istu memory page... samozrejme korektny program by mal pouzivat synchronizaciu ktora zabezpeci flush L2 cache, ale nie vzdy sa synchronizacia pouziva... kto pozna slovicko VOLATILE? :) chcel by som vediet ako bude fungovat pri takto usporiadanej cache... memory model je svina :-)
Som rad ze komunita CDR.cz pomaha vyrobcom CPU s vyladenim pamatoveho radicu. :-)))
2Torx: Je to zaujimava tema :) btw: nebavime sa tu o pamatovom radici ale o synchronizacii L2/L3 cache pri paralelnom programovani ;)
mna osobne tato tema zaujima, lebo casto programujem multivlaknove zdrojaky v jazyku Java, ten definuje memory model s istymi garanciami ako volatile, final fields, synchronized bloky a pod... viac pre zaujemcov (Java uchylakov ako ja) najdete tu:
http://today.java.net/pub/a/today/2004/04/13/JSR133.html
http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html
2 sedgar a dalsi: Trosku bych ozrejmil, jak je to s tou L3 cache. Inclusive je ta jednodussi varianta, v praxi to znamena ze L2 cache pristupuje k RAM jen vyhradne skrze L3 cache, vsechna data posilana do/z RAM se tedy zaroven ukladaji do L3 (neni to tedy zadny mirroring, ze be v L3 byla vzdy presna kopie L2). Cele to ma tu vyhodu, ze design L2 cache je jednodussi, nez kdyby mela samostatny pristup k RAM a tudiz je obvykle i rychlejsi, nevyhoda je pak v rel. nizssi efektivni velikosti L3. Synchronizace mezi L1, L2, L3 a RAM pri SMP je pak uz uplne jina pisnicka, ovsem to neni nic noveho, to existuje jiz v dnesnich (i drivejsich) XEONech, ostatne podpora pro synchonizaci cache je prave to, co dela z procesoru procesor "multi-cpu capable", ktery se pak prodava klidne i za desetinasobek ceny srovnatelneho CPU bez teto podpory (ovsem to ciste z komercnich duvodu, technicky duvod pro to zpravidla neni).
2 Sedgar:
Nekde si precti, jak funguje cache. Zejmena tohle: "2. ked ju naplni zacne pouzivat L2, L2 mirroruje do L3" je pekna ptakovina. CPU si nemuze zapisovat do cache, jak se mu zlibi. Pozice dat v cache je dana pametovou adresou. Co se tyce te hierarchie, tak data se paralelne zapisuje do vsech urovni. Zadny celkovy mirroring se neprovadi.
to xR: dik za ozrejmenie... stale vsak neviem akym sposobom sa data paralelne zapisuju do vsetkych urovni ked su ich rychlosti rozne.
pls zverejnil by si link s problematikou cache? dik.
Ruznou rychlosti :). Nejpomalejsi je RAM, takze jak se z ni postupne nacitaji, tak se ukladaji do vsech cache.
Jinak, vice o cache zde: http://en.wikipedia.org/wiki/CPU_cache
K AVX, třetí položka - Three operand non destructive syntax. To je opravdu převratná novinka. Kromě Intelu už ji mají úplně všichni. PowerPC Altivex od samýho začatku, AMD od K10.
RaStr: I u exkluzivní cache se přistupuje do RAM přes L3. Rozdíl je hlavně v okamžiku, kdy se data z L2 cache mažou. U exkluzivní architektury se musí překopírovat do L3, protože tam nejsou. Další rozdíl je v okamžiku, kdy jedno jádra nemá v L2 nějaká data, chce je po L3 a tam také nejsou. U inkluzivního uspořádání je v tu chvíli jasné, že CPU data nemá a může číst z RAM. Naproti tomu u exkluzivního uspořádání musí řadič L3 zjistit, zda některé jádro nemá data ve své L2 nebo L1. Až když zjistí že ne, tak může číst z RAM.
Flexo: Volatile ti zajistí akorát to, že
se daná proměnná čte vždy z RAM a její kopie se neudržuje v registru. Stačí mít dva procesory bez jakékoliv cache a bez volatile se ti daná proměnná snadno začne lišit.
Milda> to, co pises asi napresnejsie
ja mam info o K10 - exclusive cache
tam to funguje takto, Radic RAM cita z RAM spekulativne dopredu a uklada si data v svojom Bufferi. Ak potrebuje CPU data z RAM pozrie s ado prislusnej casti L1 cache, ak tam nie su poziorie sa do L2 cache, ak tam nie su pozrie sa do L3 cache, ak nie je ani tam tak do L1 nacita data cez Radic RAm(ci uz z buffera alebo z RAM)
ak su ale data v L2 cache tak sa tieto data skopiruju do radica L2 cache, na miesto dat v L2 cache sa presnu data z tej iste sekcie v RAM, ktore su v L1 cache, a data z radic L2 cache sa presunu do CPU a do L1 cache.
este zaujimavjsie, je ak su data v L3 cache
v radicoch cache sa drzia data z L1, L2 aj L3 lebo data z L3 idu do L1 , z L2 idu do L3 a z L1 do L2.
pri citami z RAM vsak nastava este vacsie halo..
predtym ako sa data z RAM nacitaju do L1
treba spravit
1. zisit v TLB zaznamoch radica L3 cache, kam sa maju data z L3 dat do RAM
2. zistit v TLB zaznamoch(TLB bug je porusenie tohto zaznamu za nejakych podmienok) L3 ci su data v L3 cache rovnake ako v RAM - ak su rovanke ide sa na bod 4
3. ak su data v L3 ine ako v RAM, prepista data v RAM datami z L3
4. Ulozit data z L1 a L2 do radica,
5. dat data z L2 do L3
6. dat data z L1 do L2
7. presunuit data z RAM do L1 a CPU.
>U exkluzivní architektury se musí překopírovat do L3, protože tam
>nejsou
U inclusivnej cache je to tak, ze ak sa data nenajdu v L1 ani L2 ani L3 tak sa prepise L1 aj L2 aj L3.
Intel ma semi inclusive a architekturu. t.j prepisuje sa len L3 a ak sa data najdu v L2 alebo L3 vymenia sa data v L1 s datami L2 alebo L3... Teda maninupuluje sa najkviac s dvoma cache nie s max. troma ako je to u AMD K10 Exclusive cache..
2 MildaIV:
Male upresneni - 3 operandove instrukce (SSE5) bude mit AMD az u K11, nikoliv K10.
xR: Samozřejmě K11, děkuji za opravu.
2MildaIV: co sa tyka volatile tak je to rozne v CPP a JAVA. V CPP mas garancie ze kompilator nebude ukladat premennu do registrov ale bude ju citat z pamatovej adresy (tym padom v procesorovej cache), to je vsetko. Java ovsem ide dalej, ak si pozres linky ktore som tam pridal najdes tam:
The third of these rules, the one governing volatile fields, is a stronger guarantee than that made by the original memory model. This is useful because now volatile variables can be used as "guard" variables -- you can now use a volatile field to indicate across threads that some set of actions has been performed, and be confident that those actions will be visible to all other threads.
Bolo by zaujimave vediet ako procesor handluje stav ked dve vlakna modifikuju to istu memmory page. Napriklad nejaky flag ktory jedno vlakno nastavi na true a druhe vlakno ho v cykle overuje:
while (isInterrupted) {
...
}
Vela programov na toto spolieha a myslim ze tvorcovia procesora na to museli mysliet.
k clanku: na Anandtechu su aj obrazky z Task Manageru a tam sa tvari stvorjadrovy ako osem jadier :)
re Arachim: ostatně to není žádné překvapení - je to napsáno i tady, že každé jádro zvládá dvě softwarová vlákna - a 4x2=8...
2flexo: Bozinku existuji tzv. synchronizacni primitiva, namatkou mutexy, spinlocky, fronty, na cingle CPU staci zakazat interrupt a kazda architektura podporuje nejake synchronizacni primitivum pro multi CPU. Ty pak implementuje kernel a na venek prave poskytuje jiz zminovane treba mutexy.
Jestli to nekoho zajima tak na MIPSu je to dvojice instrukci LL, SC (zde se testuje zda-li se adresa pameti objevila na sbernici mezi LL a SC, pokud ne je zamceno, jinak se to zopakuje). Na architekture x86 dobre zafunguje instrukce xchg.
Jinak AFAIK procesorove cache se udrzuji hardwarove synchronizovane. Tedy pokud se pusti vice vlaken modifikujicich stejnou pametovou bunku ve strance, nemohou bezet paralelne, pac pokazde budou cekat na sync cache cpu.
Proto napriklad dve vlakna (dve funkce)
a(void) { i++;} b(void) { i++;}
pobezi ve vysledku vyrazne pomaleji na SMP nezli seriove za sebou na jednom CPU. A proto je planovani uloh na CPU tak tezke... NP-uplny problem ;-).
2Dalibor_:
Sak som tam pisal nieco o synchronizacii, ty trdlo :) Mna ale zaujima prave problem ked dve vlakna ktore bezia na dvoch jadrach modifikuju tu istu pamatovu stranku a synchronizaciu nepouzivaju... Ak ma kazde jadro dvoju vlasnu L2 cache a v nej ulozenu kopiu tej istej stranky tak je to problem. V niektorych architekturach sa to neriesi a proste ked nepouzivas synchronizaciu tak je vysledok nedefinovany (zalezi na tom ktore jadro kedy spravy flush L2 cache do L3 cache resp. RAM). A ako spravne pises, pri jednom jadre niektore paralelne programy bezia ovela rychlejsie nez na dvoch... Preto ma tato problematika zaujima. Je asi velky rozdiel ak v AMD moze mat pamatovu stranku v L2 cache len jedno jadro pricom si ju jadra medzi sebou kradnu (kopirovanim cez L3) alebo nieco ako ma Intel... No nic, na tomto fore sa odpovedi k tomu nedopatram :-D Jedine tak studovat materialy pre konkretnu architekturu.
2flexo: nejsem sice zrovna programator, taze to neni muj denni chleb, ale z toho co o x86 architekture vim, se mi to jevi tak, ze x86 CPU dodrzuji plnou koherenci kesi (vsech urovni), takze to ze by jedno jadro dostalo ke zpracovani jina data nez jine (napr. kazde by dostalo jina data se "sve" L2 kese) je vyloucene. Aby se to nestalo musi zafungovat tzv. cache coherency protocol, neboli mechanismus pro synchonizaci kesi, na ktery ma napr. INTEL celou furu patentu (a zlepsovaku, takze je jasne, ze je tato problematika asi opravdu trapi) a porovnani ucinnosti implementace u AMD vs. INTEL je napr. zde: http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=2897&p=2&n.... Tak snad jsem se nejak zasadne nesekl se svoji uvahou a bude vam to k uzitku.
2RaStr: pozeram ten link a je to zaujimave, dik! ;-)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.