-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Fuji X-T1 | XF14mm F2.8 R | XF23mm F1.4 R | XF35mm F1.4 R
Nikon D800 | AF-S 24-120/f4 VR2 | AF-S 50/f1.8G
Computer specs
Elke on-die geheugencontroller (de A64 heeft er 1, single channel, en de A64-FX en de Opteron hebben er 2, dual channel) ondersteunt gewoon maximaal 8 rijen, 512Mbit en 4GB aan DDR geheugen
Ik dacht al dat het een beetje ongegrond was.. maar was wel nieuwsgierigBalusC schreef op 31 oktober 2003 @ 10:48:
Uuh, er is geen "32bits" en "64bits" geheugen hoor
Elke on-die geheugencontroller (de A64 heeft er 1, single channel, en de A64-FX en de Opteron hebben er 2, dual channel) ondersteunt gewoon maximaal 8 rijen, 512Mbit en 4GB aan DDR geheugenBij de A64-FX en de Opteron is dat dus respectievelijk 16 rijen, 512Mbit en 8GB.
maar om op afterburn in te gaan.. moet je bij de Athlon64 ook 2 repen gebruiken ???
niet toch, dat was toch alleen bij de AthlonFX met dual channel ??
Maar de verbinding tussen de mem controller en het geheugen.. is die dan niet een bepaalde hoeveelheid bits ???
Hij is max. 400mhz.. maar hij moet toch ook een soort bandbreedde hebben ofzo
[ Voor 17% gewijzigd door mr._Anderson op 31-10-2003 10:54 ]
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Dat moet nietmoet je bij de Athlon64 ook 2 repen gebruiken ???
Dan nog, het is geen verplichting om geheugenreepjes in paren te gebruiken, in tegenstelling tot 16bits RDRAM.dat was toch alleen bij de AthlonFX met dual channel ??
Ja, da's 64bitsMaar de verbinding tussen de mem controller en het geheugen.. is die dan niet een bepaalde hoeveelheid bits ???
Nope, da's maximaal 200MHz DDR. De bandbreedte is logischerwijs 3200MB/s (PC3200). En trouwens, die rare MSN smileys werken hier nietHij is max. 400mhz.. maar hij moet toch ook een soort bandbreedde hebben ofzo
[ Voor 7% gewijzigd door BalusC op 31-10-2003 10:59 ]
Verwijderd
- 8 rijen = 8 * 8 bits /me edit: corrected
- 16 rijen = 16 * 8 bits /me edit: corrected
Maar dat klopt niet... Dit gaat namelijk over de maximale hoeveelheid aanstuurbare geheugenrijen, en niet over de bits tussen controller en geheugen (welke 64bit is). /me edit: corrected
Héél vroeger had je wel zoiets bij CPU's: 8086 had intern 16bits, maar extern maar 8 pinnen om data over te transporteren. Een beetje oude koe, dus niet meer echt relevant. Nu hebben we het over geheugen, en inmiddels worden allerlei dingen niet meer direct aangestuurd. Er zitten nu bufferIC's / controllers etc die elk hun eigen datapaden, buffers en bandbreedte hebben, en die onafhankelijk van de CPU opereren. Tel daarbij nog invloeden als cache hit/mis en optimalisatie etc en je bent helemaal de mogelijkheid kwijt om een formule te bedenken die naadloos overeenkomt met de praktijk. Theoretische bandbreedte is 1 ding, maar de praktijk is afhankelijk van honderden cq. duizenden factoren.
3200MB/s zul je dus niet halen, maar geeft wel aan wat het plafond is wat betreft dát onderdeel.
[ Voor 24% gewijzigd door Verwijderd op 31-10-2003 11:10 ]
Beter is om "bytes" te gebruikenVerwijderd schreef op 31 oktober 2003 @ 11:03:
Als je gek zou willen doen, zou je de aanstuurbare rijen als "bitjes" kunnen noemen.
- 8 rijen = 8 bits
- 16 rijen = 16bits
8 Bytes = 64 bits
aj.. ja slechte gewoonte van me die msn smileysBalusC schreef op 31 oktober 2003 @ 10:57:
[...]
Dat moet nietTrouwens, A64 heeft één geheugencontroller en ondersteunt dus geen dual channel geheugen.
[...]
Dan nog, het is geen verplichting om geheugenreepjes in paren te gebruiken, in tegenstelling tot 16bits RDRAM.
[...]
Ja, da's 64bits
[...]
Nope, da's maximaal 200MHz DDR. De bandbreedte is logischerwijs 3200MB/s (PC3200). En trouwens, die rare MSN smileys werken hier niet
ik bedoelde 200mhz natuurlijk. via ddr is dat effectief 400mhz
je zegt dat rdram 16bits is.. begrijp ik dan goed dat ddr 32bits is ?
of werkt dat heel anders dan rdram ? (ja weet dat het verschillende soorten geheugen zijn, die anders werken, maar gaat me op het bits verhaal hier
en ik weet dat de athlon64 alleen single channel is.. maar het ging me er dus om, om via 2 reepjes van 2*32bits een 64bits 'bus' naar het geheugen te krijgen.. maar volgens mij slaat dat dus nergens op ?
en het is geen verplichting nee bij de athlonFX.. maar dat doe je natuurlijk wel als je alzoveel geld voor een cpu uitgeeft
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Verwijderd
Ik neem aan dat de memory chip dat heeft beperkt, normaal zou het 2^64 zijn dacht ik......
SDRAM geheugen gebruikt 64bits datapadenmr._Anderson schreef op 31 oktober 2003 @ 11:08:
je zegt dat rdram 16bits is.. begrijp ik dan goed dat ddr 32bits is ?
Kijk eens in de RAM FAQ die je via de FAQ van dit subforum kunt vindenof werkt dat heel anders dan rdram ? (ja weet dat het verschillende soorten geheugen zijn, die anders werken, maar gaat me op het bits verhaal hier)
De geheugencontroller kan maximaal 512Mbit geheugen aan. Het grootst verkrijgbare 512Mbit reepje is een 1GB doublesided reepje. Verdeeld over 16 rijen kun je maximaal 8 stuks gebruiken en dat maakt dus 8GBVerwijderd schreef op 31 oktober 2003 @ 11:09:
Hummhh de FX kan maar 8Gb aan ? Dat zou 2^33 zijn, niet ?
Ik neem aan dat de memory chip dat heeft beperkt, normaal zou het 2^64 zijn dacht ik......
[ Voor 4% gewijzigd door BalusC op 31-10-2003 11:18 ]
ze werden dus nooit volledig gebruikt bij de vorige 32bits cpu's ???
of waren de mem 'bus' connecties altijd al 64bits??
en klopt mijn theorie straks wel als er bijv. 128bits cpu's komen ? (ja das toekomst muziek, maar ff voor de vraag
waarom zei je dit? als sdr 64bits datapaden heeft ????Uuh, er is geen "32bits" en "64bits" geheugen hoor
[ Voor 17% gewijzigd door mr._Anderson op 31-10-2003 11:20 ]
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Verwijderd
Zou er niet beter een 'dual-dual-channel' op kunnen dan ? Hoewel, dan moet je nu nog 4 banken vullen..... Ik denk dat er weer een andere standaard voor 64bit memory controllers moet komen, poeh!.
[ Voor 7% gewijzigd door Verwijderd op 31-10-2003 11:25 ]
Het aantal bits v.d. cpu heeft niks te maken met het aantal datalijnen v.h. geheugen (ook wel uitgedrukt in x aantal bits brede datapad). Jij haalt nu het fenomeen 'bit' doorelkaar; bits moet je in de juiste context zienmr._Anderson schreef op 31 oktober 2003 @ 11:18:
[...]
ze werden dus nooit volledig gebruikt bij de vorige 32bits cpu's ???
of waren de mem 'bus' connecties altijd al 64bits??
Just pick a dead end and chill out 'till you die.
Verwijderd
In beide gevallen maakt het "aantal bits CPU" niets uit.
Zie:
dit soort diagrammen:
- http://www.gb.tomshardwar...020305/images/chipset.jpg
- http://www.technoyard.com...onultra-kt400/chipset.jpg
- http://www.hp.com/product...set/images/4-way_chip.jpg
- http://www.segatech.com/g...otherboard%20datapath.gif
- http://www.amd.com/us-en/.../Additional/amd760mpx.gif
- http://www.intel.com/design/chipsets/860/pix/mch.gif
- http://www.karbosguide.com/images/_969.gif
- http://www.ixbt.com/video2/images/r300/r300-memcross.png
[ Voor 81% gewijzigd door Verwijderd op 31-10-2003 11:38 ]
Zelfs de allereerste Pentium heeft een 64bit Data Busmr._Anderson schreef op 31 oktober 2003 @ 11:18:
ze werden dus nooit volledig gebruikt bij de vorige 32bits cpu's ???
Verdiep je je eens in de materie: www.sandpile.org
Je was vrij onduidelijk in jouw vraagstelling en de definitie en de hele vraag is tevens compleet verwarrend, omdat ik ervan uit ging dat je de basismaterie toch wel een beetje kende, maar achteraf bleek dat dus niet zo te zijn.waarom zei je dit? als sdr 64bits datapaden heeft ????
nee, basis materie op dit vlak is miniem blijkt mij nu wel weer..Je was vrij onduidelijk in jouw vraagstelling en de definitie en de hele vraag is tevens compleet verwarrend, omdat ik ervan uit ging dat je de basismaterie toch wel een beetje kende, maar achteraf bleek dat dus niet zo te zijn.
van andere dingen weet ik dan wel weer dingen
en de rest...
bedankt jongens, ik vond het al raar ... maar wou toch wel graag even uitsluitsel hebben... het is me nu al wat duidelijker.. moet ik maar eens dieper opin duiken
[ Voor 59% gewijzigd door mr._Anderson op 31-10-2003 11:31 ]
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Verwijderd
Bij een 32 bit processor werkt het dan als volgt. De CPU levert 32 bits aan de geheugencontroller. Deze zorgt er echter voor dat op 1 adres twee keer 32 bits komen te staan.
Bij een 64 bit processor heeft de controler het makkelijker. Nu levert de CPU 64 bits aan de geheugencontroller. Deze kan nu gewoon naar 1 adres plaats toe schrijven.
De geheugencontroller zorgt er dus voor dat de het geheugen transparant is voor de CPU, m.a.w de CPU maakt zich niet druk over hoe het geheugen fysiek in elkaar zit.
Bij 128 bit processoren krijgen we wel een probleem met 64 datalijnen, dan zullen er twee schrijfacties nodig zijn, omdat er twee adresplaatsen nodig zijn
Hopelijk is het zo duidelijk voor je
aight, geluk dat ik nog even keek, dit verhaal maakt het wel heel duidleijk voor mij!! thx !!!Verwijderd schreef op 31 oktober 2003 @ 12:32:
Het klopt inderdaad dat de databus naar sdram 64bit is. Dat betekent ook meteen dat 1 adres plek uit 64 bits bestaat.
Bij een 32 bit processor werkt het dan als volgt. De CPU levert 32 bits aan de geheugencontroller. Deze zorgt er echter voor dat op 1 adres twee keer 32 bits komen te staan.
Bij een 64 bit processor heeft de controler het makkelijker. Nu levert de CPU 64 bits aan de geheugencontroller. Deze kan nu gewoon naar 1 adres plaats toe schrijven.
De geheugencontroller zorgt er dus voor dat de het geheugen transparant is voor de CPU, m.a.w de CPU maakt zich niet druk over hoe het geheugen fysiek in elkaar zit.
Bij 128 bit processoren krijgen we wel een probleem met 64 datalijnen, dan zullen er twee schrijfacties nodig zijn, omdat er twee adresplaatsen nodig zijn
Hopelijk is het zo duidelijk voor je
maar bij 128bits cpu's zullen ze wel uitbreiden naar 128bits mem bussen en 128bits geheugen... lijkt me toch verstandiger ..
[ Voor 6% gewijzigd door mr._Anderson op 31-10-2003 12:58 ]
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Verwijderd
De AMD64 beschikt al over 128 Data lijnen. Voor bereiding voor de toekomst.
Owh, jammer dat er nog geen berichten zijn over ddr ram wat gebruik maar van 128data paden.. dat zou wel een snelheids winst op kunnen leveren ?Verwijderd schreef op 31 oktober 2003 @ 14:58:
Nog een laatste update
De AMD Athlon64 beschikt al over 128 Data lijnen. Voor bereiding voor de toekomst.
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Trouwens: "AMD64" is géén CPU, maar een instructieset. Net als MMX, 3DNow!, SSE, etc
Dit topic biedt wellicht ook interessant leesvoer: [rml][ Discussie] AMD Athlon 64 & Opteron - Deel 3[/rml]
[ Voor 44% gewijzigd door BalusC op 31-10-2003 15:06 ]
In de consolewereld wordt onder de 'bitheid' vaak juist de breedte van de databus verstaan.
Verwijderd
De AMD athlon 64 beschikt over een een 128 bits DDR SDRAM Interface, voor de snelheden 100, 133, 166 en 200MHZ. Dit als voorbereiding op de toekomst.
Daarnaast zijn er in de instructie set van de AMD64 al 128-Bit media instructies.
Verwijderd
De grootte van de registers en het adresserings bereik zijn twee dingen die los van elkaar zijn. Als het om een 32 of 64 bit processor gaat, gaat het er om hoe veel bits hij in zijn register kwijt kan.Femme schreef op 31 oktober 2003 @ 15:08:
Onder 32-bit of 64-bit bij een processor verstaat men doorgaans de grootte van de registers en het geheugenadresseringsbereik. Dat heeft niets te maken met het aantal datalijnen van de bus.
In de consolewereld wordt onder de 'bitheid' vaak juist de breedte van de databus verstaan.
Hoe addresseer jij dan iets als het adres niet in je register past?Verwijderd schreef op 31 oktober 2003 @ 15:24:
[...]
De grootte van de registers en het adresserings bereik zijn twee dingen die los van elkaar zijn. Als het om een 32 of 64 bit processor gaat, gaat het er om hoe veel bits hij in zijn register kwijt kan.
De verwarring bij de TS/dit topic, gaat jiust over verschil aantal bits geheugen - breedte bus, zoals Femme zegt.
[ Voor 6% gewijzigd door Voutloos op 31-10-2003 16:28 ]
{signature}
Wat bedoel je met een adresplek in de eerste zin? Voor de rest klopt het ook niet helemaal want een 32bits cpu levert niet per definitie 32bits af bij de geheugencontroller, net zomin als er telkens 64bits door een 64bits cpu worden afgeleverd (32bit P4's maken bijvoorbeeld gebruik van 128bit cacheline's; de hoeveelheid data die telkens van en naar de geheugencontroller wordt verzonden). De hoeveelheid data (per tijdseenheid) staat _volledig_ los van het cpu type, of het nu een 32 of 64bits cpu is.Verwijderd schreef op 31 oktober 2003 @ 12:32:
Het klopt inderdaad dat de databus naar sdram 64bit is. Dat betekent ook meteen dat 1 adres plek uit 64 bits bestaat.
Bij een 32 bit processor werkt het dan als volgt. De CPU levert 32 bits aan de geheugencontroller. Deze zorgt er echter voor dat op 1 adres twee keer 32 bits komen te staan.
Bij een 64 bit processor heeft de controler het makkelijker. Nu levert de CPU 64 bits aan de geheugencontroller. Deze kan nu gewoon naar 1 adres plaats toe schrijven.
De geheugencontroller zorgt er dus voor dat de het geheugen transparant is voor de CPU, m.a.w de CPU maakt zich niet druk over hoe het geheugen fysiek in elkaar zit.
Bij 128 bit processoren krijgen we wel een probleem met 64 datalijnen, dan zullen er twee schrijfacties nodig zijn, omdat er twee adresplaatsen nodig zijn
Hopelijk is het zo duidelijk voor je
Laat dat laatste nu eens duidelijk zijn, als een cpu nu 32 of 64bits is heeft dat verder totaal geen gevolgen voor alles wat zich buiten de cpu afspeelt*: een 64bits cpu zou je zelfs prima kunnen combineren met een 16bits geheugeninterface, als je zou willen. Deze twee dingen staan tot elkaar als het aantal cilinders van een automotor en het aantal deuren van het koetswerk
De term 'bits' in geheugencontext wordt normaal gesproken alleen gebruikt als synoniem voor het aantal datalijnen tussen geheugencontroller en al het aanwezige geheugen. Een DIMM heeft te allen tijde 64 datalijnen (ik laat ECC even buiten beschouwing), deze DIMM is via z'n pinnen aangesloten op een geheugenbus welke eveneens 64 datalijnen telt. Op deze bus (channel) kunnen vervolgens meerdere DIMM's worden aangesloten maar het totaal van de bus blijft 64 datalijnen (indien meerdere DIMM's aanwezig op een bus worden de datalijnen v.d. bus gedeeld).mr._Anderson schreef op 31 oktober 2003 @ 15:01:
[...]
Owh, jammer dat er nog geen berichten zijn over ddr ram wat gebruik maar van 128data paden.. dat zou wel een snelheids winst op kunnen leveren ?
Nu is het mogelijk een tweede geheugenbus (dual channel) bij te plaatsen zodat de cpu het totaal geïnstalleerde geheugen via 128 datalijnen kan benaderen. Het effect laat zich raden: tweemaal zoveel datalijnen is in theorie tweemaal zoveel data per tijdseenheid
In het laatste geval heb je dus een 128bits geheugeninterface. Maar deze bit-cijfers an sich zeggen nog steeds helemaal niks over de totale snelheid. Zo kan een 32bits geheugeninterface in het geval van dualchannel PC1066 RIMM meer bandbreedte leveren dan een vier maal zo brede interface met dualchannel PC1600 om maar wat te noemen. Je moet dus tevens het type geheugen (en dus z'n snelheid) meenemen in de vergelijking.
Dual channel DDR-SDRAM bestaat al enige tijd, zelfs gewoon voor desktop gebruik (b.v. nVidia nForce(2), Intel E7205, i865/i875) en dit kan inderdaad snelheidswinst opleveren. Verkijk je hier echter niet op, tweemaal zoveel bandbreedte levert niet automagisch tweemaal zoveel performance. Het praktische effect is afhankelijk van factoren als cpu architectuur, werking v.d. geheugencontroller, de DIMM's zelf en natuurlijk de gebruikte software. Een goed voorbeeld hiervan is AMD's nieuwste Athlon 64. Deze cpu heeft een 64bits geheugen interface (single channel DDR-SDRAM) maar presteert in de praktijk niet veel minder als de met een 128bits geheugen interface (dual channel) uitgeruste Athlon FX.
*Om even terug te komen op de cpu zelf, het enige effect wat wat een 32bits of 64bits cpu op het geheugen heeft is de hoeveelheid die het kan adresseren: een 32bits cpu kan maximaal 4GB aansturen (2^32, het beschikt gewoonweg niet over meer adressen) en een 64bits cpu kan ettelijke malen zoveel aansturen (2^64, dat zijn héél wat adressen). Verder heeft het geen invloed op het type gegeugen, geheugenkanalen or whatsoever
Just pick a dead end and chill out 'till you die.
(Ik ben redelijk up2date, maar vroeg me dit gewoon even af)
Stel je hebt een P4 (32 bits CPU) met een single channel 64bit geheugen.
Stel je leest je geheugen lineair uit, haal je een snelheid van 3,2GB/s (PC3200)
De vraag is, welke snelheid meet je als je om de geheugenplaats uitleest, dus je slaat telkens 1 geheugenadres over. Volgens mij meet je dan exact de helft.
Mijn uitleg daarvoor:
De geheugencontroller leest per cycle 2 32bits waarden uit het geheugen, waarbij hij alleen de eerste nodig heeft. De tweede wordt niet meer gevraagd.
Nog een klein vraagje erbij:
Is er voor de Athlon64 een nieuw datatype bijgekomen, of zijn de datatypes gewoon 2x zo groot geworden (de inhoud is dan natuurlijk ^2 zo groot geworden)
Dan heb ik dus over de float, en int (bij IA32 32bit)
Want anders zou het geheugenverbruik van een 64bit processor weleens fors ongunstiger kunnen zijn.
Dus in jouw geval van het opvragen van adressen en er telkens een overslaan zal hij gewoon een hele range pakken.
Overigens is het sowieso geen issue omdat via de command en address lijnen de hele page waar de benodigde adressen in staan naar de sense amps wordt gekopieerd en de benodigde adressen in één keer worden uitgelezen door de geheugencontroller en naar de cpu worden getransporteerd. Along the line zullen er nog meer bits meegaan waar niet expliciet om is gevraagd, want de cache line moet wel vol. In een dergelijk geval zul je de maximale haalbare datatransfersnelheid halen alleen zal niet alles in die datastroom altijd worden gebruikt/gewenst door de cpu. Althans, dit is wat ik denk te weten v.d. P4 en z'n geheugengedragingen
Dit is natuurlijk theorie want die 3.2GB/s zal in de praktijk alleen kortstondig worden gehaald wanneer er geburst kan worden (dus na de initiële adressering de opvolgende adressen opeenvolgend in sneltreinvaart uitlezen).
Just pick a dead end and chill out 'till you die.
Verwijderd
ik denk dat je simpel kunt zeggen dat een x-bits processor een x-bits brede ALU heeft.Voutloos schreef op 31 oktober 2003 @ 16:27:
[...]
Hoe addresseer jij dan iets als het adres niet in je register past?(en dan niet over shiften en blaat beginnen)
breedte van registers is geen maatstaf omdat je dan altijd verwarring krijgt met andere dan GPR registers: de FPU (voor intel xeon bijvoorbeeld 80 bits breed en niet 32 bits ) en SIMD registers (128 bits voor SSE2)
addresseren van geheugen is ook geen maatstaf. de xeon bijvoorbeeld ondersteunt PAE waarmee de processor meer als 4G (namelijk 64G, dus een 36 bits addressrange) kan addresseren. dit is handig voor "drukke" servers.
een veel gehoord misverstand over PAE is overigens dat het performanceloss zou opleveren. de clue zit em echter in het feit dat virtual memory pages mbv aangepaste pagetabellen (bredere pageframe offsets 26 bits ipv 22 bits) de gehele 64G kan afmappen. de 32 bits logische proces space die een proces "ziet" kan dus verspreid worden over een fysieke addressrange die de 4G ontstijgt en doorloopt tot 64G. de logische processpace grootte blijft natuurlijk beperkt tot 4G, omdat IA-32 pointers 32 bits zijn.
Verwijderd
Waarom dual channel? Athlon64 heeft zoals elke processor graag een dikke geheugenbus. Dual channel levert dat...
Begint niet over Rambus, RambusDRAM is zo traag dat het niet kan winnen van SDRAM (zie 820-chipset). Met dual channel RDRAM is die sneller dan SDRAM. Single channel DDR-SDRAM is iets trager dan dual channel RDRAM. Maar Dual channel DDR-SDRAM is wel sneller dan dual channel RDRAM. Sis probeert met quad channel RDRAM de laaste stuiptrekking van RDRAM. Ik spreek nog niet over de prijs en rechtzaken...
[ Voor 61% gewijzigd door Verwijderd op 02-11-2003 13:42 ]
Ok, thanks, dit was wat ik wilde horen.Abbadon schreef op 01 november 2003 @ 19:09: [...] verhaal [...]
Ik vroeg me namelijk af hoe de geheugencontroller en cachealgoritmes omgaan met de verschillende busbreedtes.
Dus om kort samen te vatten:
De processor(cache) krijgt een zut informatie die snel leverbaar is, en de processor vist daaruit wat hij nodig heeft. Als je mazzel hebt is de rest nodig, anders is het pech.
Maar uiteindelijk zijn de kosten van wat extra data lager dan de opbrengst als die data toch nodig is.
Zomaar een vraagje, is er een artikel of site die hier duidelijk op in gaat? (die jij zou aanraden)
Google geeft veel eenvoudige verhalen zonder echte inhoud.
Ik werk normaal op een i850e mobo met DC PC1066 geheugen, en ik kan nou niet echt zeggen dat mijn bak onder doet voor een SDRam bak, sterker nog er zijn geen 533 FSB borden die sneller zijn dan mijn mobo. (inclusief DDR borden)Verwijderd schreef op 02 november 2003 @ 13:21:
[...]
Begint niet over Rambus, RambusDRAM is zo traag dat het niet kan winnen van SDRAM (zie 820-chipset). Met dual channel RDRAM is die sneller dan SDRAM. Single channel DDR-SDRAM is iets trager dan dual channel RDRAM. Maar Dual channel DDR-SDRAM is wel sneller dan dual channel RDRAM. Sis probeert met quad channel RDRAM de laaste stuiptrekking van RDRAM. Ik spreek nog niet over de prijs en rechtzaken...
Het is natuurlijk makkelijk om achteraf te zeggen... kijk er zijn *NU* snellere oplossingen.
Dat is hetzelfde als zeggen dat SDRam rommel is, want DDR is gewoon veel sneller... ja vandaag, maar enkele jaren geleden bestond DDR gewoon weg niet.
En sorry dat ik het moet zeggen, RDRam is gewoon een *GOED* product, het schaalt heel goed mee met de huidige processoren, en is op zeer hoge kloksnelheden bruikbaar. Dat het bedrijf misschien minder is wat het ontwikkelt heeft, betekent nog niet dat RDRam technisch gezien minder is.
* TheGhostInc heeft respect voor bedrijven die innovatief proberen te zijn, zeker als dat op een technisch superieure manier gebeurd, bv ATI boven nVidia, de die size van een nvidia chip is gemiddeld fors groter dan van een ATI chip, en dan toch zoveel performance op een lager procede eruit trekken, RESPECT
Kromme vergelijking. RDRAM is zwaar overkill voor een Pentium!!! chipset. Door de hoge wachttijden en door het knijpen van de RDRAM bandbreedte, omdat een Pentium!!! simpelweg veel te langzaam is, zul je inderdaad flink aan performance moeten inleveren ten opzichte van SDRAM. Zelfs zo erg dat de SDRAM in de meeste gevallen sneller is door de perfecte synchroniteit met de Pentium!!! processorVerwijderd schreef op 02 november 2003 @ 13:21:
Begint niet over Rambus, RambusDRAM is zo traag dat het niet kan winnen van SDRAM (zie 820-chipset).
Bedankt voor je verhelderende uitlegAbbadon schreef op 31 oktober 2003 @ 17:57:
De term 'bits' in geheugencontext wordt normaal gesproken alleen gebruikt als synoniem voor het aantal datalijnen tussen geheugencontroller en al het aanwezige geheugen. Een DIMM heeft te allen tijde 64 datalijnen (ik laat ECC even buiten beschouwing), deze DIMM is via z'n pinnen aangesloten op een geheugenbus welke eveneens 64 datalijnen telt. Op deze bus (channel) kunnen vervolgens meerdere DIMM's worden aangesloten maar het totaal van de bus blijft 64 datalijnen (indien meerdere DIMM's aanwezig op een bus worden de datalijnen v.d. bus gedeeld).
Nu is het mogelijk een tweede geheugenbus (dual channel) bij te plaatsen zodat de cpu het totaal geïnstalleerde geheugen via 128 datalijnen kan benaderen. Het effect laat zich raden: tweemaal zoveel datalijnen is in theorie tweemaal zoveel data per tijdseenheid
In het laatste geval heb je dus een 128bits geheugeninterface. Maar deze bit-cijfers an sich zeggen nog steeds helemaal niks over de totale snelheid. Zo kan een 32bits geheugeninterface in het geval van dualchannel PC1066 RIMM meer bandbreedte leveren dan een vier maal zo brede interface met dualchannel PC1600 om maar wat te noemen. Je moet dus tevens het type geheugen (en dus z'n snelheid) meenemen in de vergelijking.
Dual channel DDR-SDRAM bestaat al enige tijd, zelfs gewoon voor desktop gebruik (b.v. nVidia nForce(2), Intel E7205, i865/i875) en dit kan inderdaad snelheidswinst opleveren. Verkijk je hier echter niet op, tweemaal zoveel bandbreedte levert niet automagisch tweemaal zoveel performance. Het praktische effect is afhankelijk van factoren als cpu architectuur, werking v.d. geheugencontroller, de DIMM's zelf en natuurlijk de gebruikte software. Een goed voorbeeld hiervan is AMD's nieuwste Athlon 64. Deze cpu heeft een 64bits geheugen interface (single channel DDR-SDRAM) maar presteert in de praktijk niet veel minder als de met een 128bits geheugen interface (dual channel) uitgeruste Athlon FX.
*Om even terug te komen op de cpu zelf, het enige effect wat wat een 32bits of 64bits cpu op het geheugen heeft is de hoeveelheid die het kan adresseren: een 32bits cpu kan maximaal 4GB aansturen (2^32, het beschikt gewoonweg niet over meer adressen) en een 64bits cpu kan ettelijke malen zoveel aansturen (2^64, dat zijn héél wat adressen). Verder heeft het geen invloed op het type gegeugen, geheugenkanalen or whatsoever
-=[Een wijs man zei eens: als een tweaker heb ik zo mijn TCP-IP connecties. Deze uitspraak staat tot op de dag van vandaag © mr._Anderson]=-=[ AMD64 overclock en registratie site: AMDGeeks.net
Zo kun je het in een notendop inderdaad zienTheGhostInc schreef op 02 november 2003 @ 14:41:
[...]
Dus om kort samen te vatten:
De processor(cache) krijgt een zut informatie die snel leverbaar is, en de processor vist daaruit wat hij nodig heeft. Als je mazzel hebt is de rest nodig, anders is het pech.
Maar uiteindelijk zijn de kosten van wat extra data lager dan de opbrengst als die data toch nodig is.
Moest ff weer googlen maar hier een linkje naar een artikel welke ik een poosje terug heb gelezen. Heb ik o.a. ook de info vandaan van hierboven (dit is allemaal nog gedetailleerder maar ik lees 't vaak snel door en vind 't allang prima als ik de basis een beetje doorheb. Wil ik details, dan zoek ik 't wel weer op
Maar 't levert ook performanceverlies op, iig t.o.v. een full blown 64bits systeem (en daarmee wil je 't ook vergelijken). Je zit namelijk met die tabellen die je opnoemt, deze impliceren een extra bewerking (omrekenen) maar door de beperkte 32bits ruimte blijft het OS (de AWExtension) bezig met extra mappen, remappen en vrijmaken van geheugen. Daarnaast kunnen ook niet alle functies uitgevoerd worden op de virtuele adressen welke binnen de AWE range vallen. Al met al is het een lapmiddel welke niet in de schaduw kan staan van een true 64bits systeem.Verwijderd schreef op 02 november 2003 @ 10:07:
[...]
een veel gehoord misverstand over PAE is overigens dat het performanceloss zou opleveren...
Da's tamelijk kort door de bocht. Het is trouwens pas sinds de invoering van dual channel DDR400 ram (i865/875 chipsets) dat een RDRAM based systeem het onderspit moet delven. Een i850E is niks langzamer dan een E7205 met dual channel PC2100. Beiden hebben theoretisch dezelfde max bandbreedte (4266MB/s) maar in veel gevallen weet het RDRAM systeem zelfs net een procentje of wat beter te scoren. Waarschijnlijke oorzaak is dat een Rambus kanaal veel sneller van richting kan veranderen dan een DDR-SDRAM kanaal (dataverkeer kan tegelijkertijd maar één kant op) waardoor het de mindere eigenschappen compenseertVerwijderd schreef op 02 november 2003 @ 13:21:
Begint niet over Rambus, RambusDRAM is zo traag dat...
Prijs en rechtzaken is een compleet ander verhaal, dingen die op z'n zachtst gezegd niet veel goed hebben gedaan voor Rambus' goodwill factor.
Just pick a dead end and chill out 'till you die.
Verwijderd
neen, deze mapping vindt ook plaats in 32 en fullblown/true 64 bits (sic) systemen. het is de reguliere mapping dmv van page directories/tabellen van virtual memory pages naar fysieke memory frames. de extra bits in de tabellen in het geval van PAE zorgen niet voor performance loss. het maakt het alleen mogelijk een virtuele page te laten mappen naar een fysiek memory frame boven de 4G grens.Abbadon schreef op 02 november 2003 @ 16:38:
Maar 't levert ook performanceverlies op, iig t.o.v. een full blown 64bits systeem (en daarmee wil je 't ook vergelijken). Je zit namelijk met die tabellen die je opnoemt, deze impliceren een extra bewerking (omrekenen) maar door de beperkte 32bits ruimte blijft het OS (de AWExtension) bezig met extra mappen, remappen en vrijmaken van geheugen. Daarnaast kunnen ook niet alle functies uitgevoerd worden op de virtuele adressen welke binnen de AWE range vallen. Al met al is het een lapmiddel welke niet in de schaduw kan staan van een true 64bits systeem.
.
dat AWE wat jij noemt wordt waarschijnlijk gebruikt om de processpace van 1 proces groter te maken dan 4G, mbv windowing technieken ala DOS EMS? ik ken de AWE techniek niet, staat het soms voor Application Windowing? het is in elk geval niet wat ik bedoel.
het aanpassen van de pagetabellen is echter transparant voor de IA32 binaries, het veranderd namelijke de 32 bits virtual memoryspace niet. het zorgt er alleen voor dat meer dan 4G (namelijk 64G) fysiek geheugen gebruikt kan worden door meerdere IA32 processen. dit is handig voor serverconsolidatie van 32 bits toepassingen aangezien de machine minder snel zal gaan swappen omdat tot 64G fysiek geheugen gebruikt kan worden.
lees er maar eens over : http://www.microsoft.com/...rm/server/pae/pae_os.mspx
Verwijderd
verwerken van grotere loads.
databases enzo...