72
-
BiroAndras #72 "Így hát ha a prockó PAE módban indul, el lehet érni 32 biten is a 4GB feletti területet (ezt már a Win2000 óta az oprendszerek is támogatják) - ám kérdés mennyire hatékony megoldás ez 32 bites környezetben. 32 biten egy VM-ben futó folyamat max.mérete 3.6 GB-ban van korlátozva (fizikai korlát), így a 8GB fizikai memória 32 biten gyakorlatilag semmi pluszt nem ad."
Mint már írták, a process-ek más-más részét használhatják a fizikai memóriának, így kihasználhatják a 4GB feletti részt.
Másrészt 1 process is tudja lapozni a 4GB feletti részt. Ez ugyan lassabb, mint a direkt memória elérés, de sokkal gyorsabb, mint a vinyó. Pl. adatbázis szervereknél ez jól használható. -
dez #71 Nem 100%, de úgy emlékszem. De még ha van is olyan NB, ami lekezel két procit, és 8GB ramot, miért bonyolították, és főleg lassították volna a dolgokat az "up to" 8GB rammal? (Ha nem úgy van megoldva, hogy az egyik proci az egyik rammal van közelebbi viszonyban, a másik meg a másikkal, és a kereszt-hozzáféréseket intézik csak speciális módon.) -
fako #70 Biztos vagy benne hogy 2 northbridge-t lattal? Tudnal linkelni oldalt ahol ilyen alaplapot latni?
-
Su0my #69 a 32 bites technológi réééges rééégen elavult, már vagy 10 éve le akarják cserélni ;) -
#68
Nem semmi fába vágta megint a fejszéjét az MS. Még egy átlag applikációnál sem egyszerű a többszálas programozás, na de oprendszert fejleszteni így??? -
dez #67 Inkább az, hogy miért van egyátalán több, mint 4GB ezeken a lapokon, amikor ez csak megbonyolítja a dolgokat, és attól, hogy két proci van, bőven elég lehet 4GB is, illetve miért volt 2 NB (NorthBridge)? Nem "gyanús" ez neked? -
fako #66 "Inkább írd le pontosabban, hogy megy a dolog a régi (32 bites) rendszerben. Ahogy Laci73 írta?"
Ha az a kerdes hogy lehet 32bit-es rendszeren tobb mint 4gb mem-et hasznalni akkor igen.
-
dez #65 (Illetve Laci73 leírása is csak egy adalék, nem áll össze belőle a teljes kép.) -
dez #64 Megszoktad? Na ne mondd. Hány esetet tudsz felsorolni? Szerintem nem sokat. Ezzel ne vicceljunk, mert durva sértegetés. Én is emlékszek egyes esetekre, amikor én javítottam ki a te pontatlanságod, de azért ebből nem általánosítok.
Most sem azt magyaráztam meg, hogy nem azt mondtam. Nyilván nem két teljesen különálló rendszerről volt szó, egy lapon. Arra gondoltam, valahogy úgy mehet a dolog, mint a (multiprocis rendszerbe tervezett) Opteronoknál. Azért is gondoltam ezt, mert úgy emlékszem, 2 NB-t is láttam azokon a lapokon (nem az Opteronoson természetesen, még mielőtt valaki ezzel jönne).
Inkább írd le pontosabban, hogy megy a dolog a régi (32 bites) rendszerben. Ahogy Laci73 írta? -
dez #63 Ez nagyszerű, de az említett dual-procis rendszer tudtommal szépen egyben látja azt a ramot. -
fako #62 "...így a 8GB fizikai memória 32 biten gyakorlatilag semmi pluszt nem ad."
Ad plussz-t. 8gb lesz a fizikai memoria:)
Egy program tovabbra sem cimezhet 4gb-nel tobbet mert az fizikai korlatokba utkozik. Viszont a kulonbozo processzek kihasznalhatjak a nagyobb memoriat. -
fako #61 "Az egyetlen különbség a közös vagy nem közös cache, ami a több magos procik hátrányát okozza a több procis rendszerekkel szemben"
Ezt rosszul latod. A tobb magos procik gyorsabbak. A kulonallo processzorokkal a legfobb problemaja a cache koherencia. Ha egy adat mindket proci cacheben megtalalhato, es az egyik modosit valamit, akkor a masik procinak mar inkonzisztens adat lesz a cacheben. Ennek a szinkronizalasa elegge teljesitmenyigenyes.
Ha egy lapkan van a ket mag akkor lenyegesen gyorsabban megoldhato.
Ha netalantan kozos cacheuk is van akkor pedig meg is oldodik. Egyebkent a kozos cache inkabb csokkenti a miss-t minthogy novelne. Termeszetesen ilyenkor ugy kell megvalasztani a cache meretet hogy az elegendo legyen a ket mag szamara. -
fako #60 Mar megszoktam hogy mindig megmagyarazod hogy te nem azt mondtad amit mondtal:)
Az alaplapon a memoria bankok elhelyezkedesenek semmi koze az architekturalis felepiteshez. Oda epitik ahova eppen jut hely.
Ahogy mar emlitettem, tobbmagos/tobbprocis rendszerek kozos rammal rendelkeznek. Enelkul nagysagrendekkel bonyolultabb es lassabb lenne a kommunikacio a procik kozott.
Latom a memoria kapcsolodasaval kapcsolatban is van nehany homalyos folt: hagyomanyos modon (pl jelenlegi intel procik) az fsb-n keresztul kapcsolodnak egymashoz illetve a ramhoz.
Ezzel szemben pl egy opteron rendszernel minden proci mem vezerlojere van kotve ram (ezt lattad te 'tobb' ramnak). A procik egy ht buszon kozvetlenul kapcsolodnak, es a ramot egy cimternek latjak. Termeszetesen eleresi idoben van kulonbseg a kulonbozo memoria cimek kozott, de ezt a korszeru oprendszerek mind kezelik.
-
#59
Dez: Az x86-os processzorokban a PentiumPro óta van egy speciális memória-kezelő egység, a PAE (Physical Address Extension - Fizikai Címzés Kiterjesztés) amely lehetővé teszi - elméletben -64GB memória címzését (ilyenkor az MMU négy mezőben tárolja a virtuális címeket). Így hát ha a prockó PAE módban indul, el lehet érni 32 biten is a 4GB feletti területet (ezt már a Win2000 óta az oprendszerek is támogatják) - ám kérdés mennyire hatékony megoldás ez 32 bites környezetben. 32 biten egy VM-ben futó folyamat max.mérete 3.6 GB-ban van korlátozva (fizikai korlát), így a 8GB fizikai memória 32 biten gyakorlatilag semmi pluszt nem ad. -
dez #58 Ja, a cikket figyelembe véve, gondoltál már arra, hogy azért nem nagy a különbség, mert nem tökéletesen van itt még implementálva a dolog? -
dez #57 Ha egy program két szála egy területre/-ről dolgozik, akkor jól jön a közös cache. Épp ezért közös a L2 a Conroe-ban, és később a L3 az AMD valamely procijában. -
dez #56 Természetesen egynek látja a ramot a rendszer, de ha megnéztek pár dual-procis alaplapot, külön bank-csoport van a procikhoz. Így lehet 2db 32 bites procit tartalmazó alaplapon 8GB ram. Csak azt nem tudom, hogy olvas az A proci a B ramjából, és viszont. Valahogy meg van oldva, de nyilván lassú. -
#55
A processzek szétválásztásának hatékony megoldására csak hardver-szinten kerülhet sor, lehetőségeit és feladatát tekintve erre az oprendszer önmagában alkalmatlan. A probléma vagy egy különleges célhardver, egy optimalizáló-processzor beépítésével, vagy legalább hárommagvas CPU-k használatával lenne megoldható (ahol az egyik mag - vagy a beépített prockó - csak és kizárólag a tárból kiemelt processzek szétválogatásával, ütemezésével és továbbadásával foglalkozna)
Írta lentebb valaki hogy többprocesszoros megoldásoknál minden CPU-nak saját operatív tár dukáljon: még csak az kéne, pillanatok alatt holtpontra vágná a futó programot a tár szétszakítása. Ugyanis az egyes CPU-khoz tartozó, külön-külön operatív tárak értelemszerűen elrejtenék a bennük tárolt adatokat egymás elől, a futtatáshoz gyakorlatilag előre kéne optimalizálni a programot minden egyes gépre (pontosan megadva hány mag és ehhez tartozóan mekkora memória van az adott gépben - egyszerűen képtelenség)
De hogy ne fossam a szót, és érthető is legyek: szvsz. rövidesen megjelennek majd a megfelelő CPU-k, amelyek számára (helyesebben az oprendszer számára) az optimalizáció nem lesz gond, és elérhető lesz egy lényegesen nagyobb teljesítmény többprockós gépeinken. Persze ehhez hatékonyabb RAM felépítés sem ártana, de ezt majd később... -
Equ #54 erre mondtam, hogy már az xp is megkapta a HT-s patch-t (máshogy ütemez rajta, mint a sima dual rendszeren, de ez igazából pár %-os különbség csak, nincs nagy jelentősége) nemhogy a vista.
"Azért annak is van előnye, hogy a két mag egymás mellett van közös cachevel, mert két teljesen különálló procin egy program két szálát nehezebb összehangolni azthiszem."
semmivel nem könnyebb dualcore-on se összehangolni. A gond abból van, hogy mivel a két mag teljesen eltérő szálakat futtat, de a cache-ük közös, egymás elöl "misselik" be az adatokat és utasitásokat, ami persze a másik magnak semmire nemjó, igy az elkezdi kiszoritani az első mag által behozott cuccokat s.i.t. (persze ez nem ennyire egyszerű, meg igyekeznek ez ellen védekezni, de a teljesitmény különbség a független procikhoz képest erre vezethető vissza)
"VIszont ha több 1 szálú program fut, akkor talán mind1."
Ott is ugyanez a probléma, a közös cache hatékonysága alacsony. -
whitehawk #53 Habár pl egy hyper-threading képes proci 2 processzornak tűnik az OS számára, ez így közel sem valós, mivel a teljesítmény jóval az alatt marad, tehát jó ha az OS felismeri a helyzetet, és úgy alakítja az ütemezést, hogy figyelembe veszi, a "csonka" processzort. (hiszen az max 30% többletet ad). Azért annak is van előnye, hogy a két mag egymás mellett van közös cachevel, mert két teljesen különálló procin egy program két szálát nehezebb összehangolni azthiszem. VIszont ha több 1 szálú program fut, akkor talán mind1. -
Tripax #52 Én úgy érzem kéne egy szakmailag megalapozott, ámbátor mindenkiszámára - lásd laikusok számára is érthető - cikk ami minden kételyt eloszlatna. 
-
juzosch #51 Hát nem pont ezen dolgozik épp a microsoft? -
Equ #50 tévedés, nincs külön memória több procis gépnél sem. Az egyetlen különbség a közös vagy nem közös cache, ami a több magos procik hátrányát okozza a több procis rendszerekkel szemben, ellenben az os ezen minimális szinten tud segíteni. (bár egyébként erre vonatkozó update még az xp-re is megjelent, nemhogy a vista-ra) -
fako #49 "és az egy lapon 2 proci meg a leírt módon két külön rammal van? "
Multiprocesszoros rendszereknel csak 1 ram van.
Multiszamogepes rendszereknel (pl clusternel) van tobb ram. Egesz mas a ketto.
-
fako #48 A tobb magos proci az tobb proci egy lapkan. A programok szempontjabol nincs kulonbseg.
A tobb procis rendszerekkel szemben a teljesitmeny onnan szarmazik hogy a mar emlitett modon lehet kozos cache-uk, illetve a fizikai kozelseg miatt gyorsabb a kommunikacio a magok kozott.
-
dez #47 Ehh, bocs, a cache-hit arányt már arra gondolva írtam, hogy osztoznak a magok valamelyik cache-en, ami persze nem valósul meg, ha két proci egyszerűen egymás mellett van a tokban. -
dez #46 Úgy érted, az egy tokban két mag is egy memóriával dolgozik (mint most a Pendium D-k, ugye?), és az egy lapon 2 proci meg a leírt módon két külön rammal van? Nos, a második esetben olyan szálakat (olyan értelemben, hogy egy másik process is egy másik végrehajtási szál) érdemes egy időben futtatni (scheduling) rajtuk, amik az adott procin a hozzá tartozó ramhoz férnek leginkább hozzá (mert pl. onnan futnak). Az első esetben nagyjából mindegy, vagy adott esetben jobb, ha ugyanahhoz a memóriaterülethez tartoznak (mert pl. ugyanazon program szálai), akkor jobb a cache-hit arány. -
dez #45 Azért egy alapvetően egyszálas programot nem lehet olyan hatékonyan "szétosztani" több magra, mint ha egy eleve többszálúra/párhuzamos feldolgozásúra írt programról lenne szó.
Ezt nem is igazán lehet pusztán sw (OS) szinten megoldani. Lásd #40, ahol hw szinten van megoldva, és vélhetően az OS már eleve egy magnak látja ilyenkor. -
Inquisitor #44 Mindezeket végigolvasva van értelme az AMD Reverse Hyper Threading dolognak :D -
Inquisitor #43 Ezt én se vágom, annak idején volt pl. P2-es, meg P3-as dualprocis alaplap, az Asus meg árult Slot1-es átalakítót 2db FCPGA procihoz. Azt értem, hogy a ramhoz való hozzáférés ütemezése más lehet, de technikailag az egy tokban 2 mag vagy az egy laopn két proci között mi lenne a lényegi ülönbség programozási szempontból? -
dez #42 Külön prociknak külön cache-eik vannak, egy többmagos prociban osztozhatnak a magok valamelyik cache-en. Továbbá a kölön procikhoz általában külön ram tartozik, a többmagosak meg egy memóriával dolgoznak. Célszerű ezek figyelembe vételével vezényelni a dolgokat. -
Caro #41 A több magos transzparensen látszik többprocisnak nem?
Tehát az OS nem tud különbséget tenni, és felesleges is lenne.
Én úgy tudom, hogy a többszálú programokat, és szinte minden program többszálú, simán szét tudják osztani a magok között.
Egy szálat meg nem lehet osztani.
Max olyanokkal lehet trükközni, mint annó a pentiumnál a branch-prediction meg a pipeline. -
Artus58 #40 nemtom hallottatok e az AMD új ötletéről, a reverse hyper threadingról. ezzel a technológiával képes lenne a proci "összeolvasztani" a több magját, és így gyorsítani az egyszálú alkalmazásokat. szóval nem két közepes prociként dolgozna, hanem egy nagyongyorsként. így pl a játékosok teljesen kihasználhatják a többmagos rendszereket Vista alatt is. Ha az os nem is támogatja.. megoldják hardveresen a problémát. pletykák szerint az összes többmagos amd-ben benne van a technológia, majd egy drivert kell hozzá felrakni hogy aktiválódjon. -
BiroAndras #39 "Nem egészen azt válaszoltad, amit kellett volna: Hiszen többmagos prociról volt szó, te meg rávágtad a többprocis rendszereket."
Gondoltam, hogy lesz aki lecsap erre.
Az NT kernel eredetileg több procis gépekhez készült. Mivel akkor olyanok voltak.
Viszont innen a több mag támogatása gyakorlatilag ingyen van. A többmagos procik az OS felé alapvetően magonként külön prociként látszanak. Némi optimalizáció, meg főleg licenszelési dolgok miatt persze az OS-*nek tudnia kell, hogy többmagos proci, vagy több külön proci van-e alatta.
Az XP pl. vígan kezeli a multicore CPU-kat (tapasztalat).
"a többmagos támogatás nem egyenlő a többprocis támogatással!!!"
Amennyire én tudom, nincs túl sok különbség köztük az OS szempontjából. Ha tud több procit kezelni, akkor a többmagosakkal is elbír.
Egyébként ez annyira így van, hogy pl. az Intel kettő darab külön procit csomagol egybe multicore címén. -
#38
""Azért jó, hogy várhat valaki 2010-ig, mire ki tudná használni a többmagos prociját."
Nem kell várnia semeddig. Az NT kernel a kezdetektől támogatja a többprocis rendszereket. "
(idézettel együtt idéztem)
Nem egészen azt válaszoltad, amit kellett volna: Hiszen többmagos prociról volt szó, te meg rávágtad a többprocis rendszereket.
Úgy látom itt az emberek kevernek 1-2 dolgot: a többmagos támogatás nem egyenlő a többprocis támogatással!!!
-
intrex #37 :DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
hihihihihihihihihihihihihihiiiiiiiiiiiiiiiiiii! -
#36
Ha még nem is csinálnak semmit, legalább már elméleti szinten neki álltak. Legalább előlről, az alapoktól kezdve kidolgozzák hogy melyek a főbb irányvonalak, és azokra építenek mindent. Szerintem egyértelmű hogy a 64 bites technológia, a több magos processzorok kezelése, biztonság, hálózat kezelés a fő szempontok között vannak. A Vista is elég jóra sikeredett, bár én még csak Hyper-threading-os procin próbáltam, azon elég jól kezelte a virtualizációt, több magos procin még nem volt hozzá szerencsém, hogy mennyivel lenne gyorsabb az XP-hez képest. De az újraírt kernel, szerintem elég sokat dob rajta. Ha a Vista után következő windows-t már teljesen az alapoktól újraírják, és ezek lesznek a fő szempontok, akkor egy nagyon jó rendszert kapunk, amely kellőképpen kihasználja majd a hardverek teljesítményét. -
irkab1rka #35 Windows szidni nem más, mint divat: usereknek való.
Akit meg érdekel C++-ban játék proramozása (ogre), az meg ír privátban, hogy 'hö', oszt egyeztetjük a koncepciókat. Pénz nincs.
Éljen a sony ps3! Éljen Kenny McCormick! -
BiroAndras #34 "Hát akkor ennyit a VISTA által teljes mértékben kihasznált többmagos prickról VS Windows XP témáról."
Ezt nem egészen értem. Nem az OS-nek kell kihasználni a több magot, hanem a rajta futó szoftvereknek. Az OS és a fejlesztőeszközök csak támogatást nyújtanak ehhez.
A jelenlegi termékek tervezésekor még nem volt szó több magról, így kissé kezdetleges még a támogatásuk.
"Azért jó, hogy várhat valaki 2010-ig, mire ki tudná használni a többmagos prociját."
Nem kell várnia semeddig. Az NT kernel a kezdetektől támogatja a többprocis rendszereket. De ez régen a profik játékszere volt, ma meg hirtelen az átlagjúzeré lett. Ez utóbbira nincs felkészülve senki. Más fajta támogatás kell egy szuperszámítógép vagy egy nagy munkaállomás programozásához, és más egy PC-hez. -
TommyGun #33 Én azt hiszem hogy most már biztos hogy a több magos cuccok felé fog fejlődni a proci ipar...mikor kezték a vistát akkor nem volt ennyire egyértelmű, akkor még úgynézett ki hogy a 10Ghz is elérhető lesz....ennek jegyében kezték a vistát is el annó...persze a többmagos procikat sokkal jobban fogja lekezleni mint az XP de én úgy vélem hogy az MS is ráébredt már régebben hogy a Vista után teljesen elölről kell kezdeniük mmindent...a Vista egy elég alapos XP tuningnak tűnik számomra...de valszeg a köv oprendszer semmi hsaonlóságot nem fog mutatni e téren...valszeg új alapokra fogják helyezni az egészet....úgy ahogy az intel P4-el rájött hogy a Mhz kergetésnek vége és lépett más irányba úgy az MS is talán rájött hogy az NT-re építkezésnek a Vistával vége van...