Már dolgoznak a Windows utódján

"Í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ó.

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.)

Biztos vagy benne hogy 2 northbridge-t lattal? Tudnal linkelni oldalt ahol ilyen alaplapot latni?

a 32 bites technológi réééges rééégen elavult, már vagy 10 éve le akarják cserélni ;)

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???

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?

"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.

(Illetve Laci73 leírása is csak egy adalék, nem áll össze belõle a teljes kép.)

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?

Ez nagyszerû, de az említett dual-procis rendszer tudtommal szépen egyben látja azt a ramot.

"...í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.

"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.

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.

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.

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?

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.

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ú.

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...

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.

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.

É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. <#nezze>

Hát nem pont ezen dolgozik épp a microsoft?

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)

"é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.

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.

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.

Ú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.

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.

Mindezeket végigolvasva van értelme az AMD Reverse Hyper Threading dolognak :D

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?

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.

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.

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.

"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.

""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!!! <#ejnye1>

:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
hihihihihihihihihihihihihihiiiiiiiiiiiiiiiiiii!

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.

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!

"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.

É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...

"Igaz, de a "támogatást" kenheti a user hajára, ha mondjuk 10%-os gyorsul a szívének kedves program a 2 maggal, holott többet is gyorsulhatna ..."

Ha rosszul van megirva a program, akkor linux - vagy bármi más - alatt is 10%-ot gyorsul ma. (bár ott inkább mégkevesebbet) Amirõl a cikk szól, hogy még az ilyen programokat is szét fogja tudni osztani több proci között a win, amire jelenleg egyetlen oprendszer sem képes.

Remélem nem úgy gondolják, hogy az oprendszer tobzódik majd az erõforrásokban, amire meg nincs szüksége azt nagylelkûen átengedi az alkalmazásoknak?

Igaz, de a "támogatást" kenheti a user hajára, ha mondjuk 10%-os gyorsul a szívének kedves program a 2 maggal, holott többet is gyorsulhatna ...

de ha valaki játék közben vesz fel, annak a legjobb megoldás a többmagos processzor, egyiken megy a game, másikat terheli a felvétel...

http://www.sql-server-performance.com/images/jc_high_call_volume4.jpg

itt az látszik, ahogy a windows 2003 szétosztja az sql szerver 17.000 hivás/sec-es terhelését 16 proci között...

Itt meg 32 dualcore-os proci task managerben.

itt tényleg ennyi a mûszaki analfabéta? Nem sima többprocis/többmagos támogatásról van itt szó, mert az már az nt4 is támogatta (a windows 2003 pedig jópár 64 procis gépen fut jelenleg is) hanem egy olyan magasabb szintû kihasználásról, amit jelenleg egyetlen oprendszer sem támogat...

Akkor hiú ábránd marad hogy a Vista kihasználja majd a dualcore-os procimat?

Ez nem a Vienna lesz, azt 2009-12 közé tervezik (inkább 2010 után, nem hiszem, hogy csak 2 évet hagynának a Vistának). Jelenleg fut Singularity néven egy projekt, ami egy teljesen .NET alapú OS lesz amit a Windows utódául szánnak és a Vienna után fog megjelenni. Tehát lehet még várni...

na nem sinix (mert az is oprendszer és futott rajta)

azért egy nt-t csak felismerek egy többprocis sinix rendszeren