Vervolg op de geheugendiscussie in het topic van Joske_power

[anoniem]

Om niet off topic te gaan, maar wel een interessante discussie voor te zetten gaan we hier maar even verder. :) [quote:7e51def818]Om eerst maar even onderscheid te maken tussen swap file geheugen en RAM geheugen. De swapfile moet je niet echt zien als mem. 't is wel een soort geheugen dat windows creeert, maar je proc kan 't echt niet rechtstreeks aanspreken. [/quote:7e51def818] Jullie praten een beetje langs elkaar heen, vanuit een software standpunt is de swapfile gewoon extra geheugen. Maar vanuit een hardware standpunt is de swap zo gruwelijk traag dat je het als het even kan niet wilt gebruiken. [quote:7e51def818]Verder bestaan de registers maar uit 32 bits. 't kan wel zijn dat er 1 of andere truckendoos is opengetrokken in 't verleden, maar dit wordt dus niet toegepast in de normale desktop systemen. [/quote:7e51def818] Hier heb je gelijk in. De 36 bits hack is PAE, maar om die te kunnen gebruiken heb je speciale software ondersteuning nodig die in de consumentenmarkt ontbreekt. Daar komt bij dat het ook geen echte 36 bits is, maar 32 bits segmenten binnen een 36 bits geheugenruimte. Heen en weer springen tussen de verschillende segmenten is ook niet triviaal, voor de software en voor de prestaties. En als een 32 bits segment te klein is heb je pech. Dat alles maakt de hack totaal onbruikbaar voor de gewone desktop. [quote:7e51def818]De switch naar 64 bits heeft niet alleen te maken met een toekomstig gebrek aan adresseerbaar geheugen. Het heeft vooral te maken met de verwerkingssnelheid van data. Een 64 bits brede databus kan theoretisch per klokslag nou eenmaal 2x zoveel data verstouwen tov een 32 bits databus. [/quote:7e51def818] Dit is niet waar. Geheugenadressering is de enige reden dat AMD de x86 instructieset heeft uitgebreid naar 64 bits. Om van de nood een deugd te maken hebben ze tegelijkertijd een aantal registers toegevoegd en een aantal archaïsche instructies eruit gekicked. Sterker nog, in principe presteert een 32 bits CPU bijna altijd beter dan een 64 bits. Om de simpele reden dat een CPU praktisch altijd met getallen werkt die kleiner zijn dan 32 bits. Maak je die 64 bits, dan nemen ze dus alleen maar meer ruimte in. Vergelijk 0001 + 0010 (4 bits) en 00000001 + 00000010 (8 bits). Ze geven dezelfde uitkomst, maar de eerste is makkelijker op te slaan en uit te rekenen. Enige waar 64 bits getallen voor van pas komen is encryptie. [quote:7e51def818]De huidige 64-bits procs werken ook nog voor het grootste gedeelte met 32-bits instructies, aangezien er nog nauwelijks 64-bit software beschikbaar is voor Windows wordt de 64-bits instructieset dus ook nog nauwelijks gebruikt. Voor linux is een ander verhaal.[/quote:7e51def818] Zelfs 64 bits software werkt default met 32 bits data. Om ruimte en bandbreedte te besparen, zoals ik boven al uitlegde. In x86-64 heb je zelfs een speciale prefix nodig om aan te geven dat je 64 bits data wilt gebruiken. Overigens moet je onderscheid maken tussen instructies en data. De lengte van de instructies varieert namelijk per instructie in x86. Veelgebruikte instructies zijn korter, net als veelgebruikte woorden in het Nederlands. [quote:7e51def818]Vergelijk een 32-bits en een 64-bits proc maar eens in prestaties. De A64 gaat in dat geval ook stukken harder en dat heeft er weinig mee te maken dat de kloksnelheid wordt opgeschroeft. Dat is voornamelijk de strategie van Intel, maar AMD zorgt er juist voor dat er per klokslag meer instructies worden uitgevoerd. AMD 64 heeft een IPC van 12 tov de K7 met 9 Instructies per seconde in het geval van de Barton.[/quote:7e51def818] Ten eerste hebben de prestaties inderdaad helemaal niets met de bitheid van de CPU te maken, zolang je ten minste niet naar encryptiesoftware kijkt. Ten tweede kloppen je IPC waarden niet, omdat geen enkele moderne CPU erin slaagt zijn executieeenheden maximaal te benutten. K7 kan maximaal iets meer dan 2 x86 instructies per klokcyclus decoderen, K8 iets minder dan 3. Dit is omdat de K8 decoders veel flexibeler zijn dan die van K7. Maar die cijfers slaan ook nergens op, omdat het aanvoeren van data en instructies een veel groter probleem is dan het verwerken. Het IPC hangt dus sterk af van de software, als ik me goed herinner scoort K7 in SPEC2000 een IPC van 1,0, K8 haalt 1,2. [quote:7e51def818]Ook het werken met de instructiesets als SSE2 en SSE3 zorgt nog eens voor een snellere dataverwerking.[/quote:7e51def818] Klopt, denk er ook aan dat een 32 bits CPU met SSE2 probleemloos met 64 bits getallen werkt. En de x87 FPU was al vanaf de eerste 32 bits CPU 80 bits. :) [quote:7e51def818]Natuurlijk kan een hogere IPC de prestaties oppeppen. Maar vooral de gewijzigde cache strategie bij de Athlon64 zorgt voor de performance boost, want verder lijkt hij sterk op de K7 core: http://www.cpuid.com/K8/index.php[/quote:7e51def818] Als je met cache strategie de ingebouwde geheugencontroller bedoelt heb je gelijk. Maar voor K8 heeft AMD grote delen van de K7 eruit gehaald, opnieuw ontworpen en weer teruggestopt. Het is veel meer dan een K7 met ingebouwde geheugencontroller.

[anoniem]

:off: Zat me al af te vragen waar 't gedeelte heen was waar ik op antwoorde. ATM ff weinig tijd om precieze linkjes bij elkaar te zoeken enz, maar reply komt er nog aan. Ik vind deze discusse toch wel erg intressant. Kan me ook niet voorstellen dat intel nu nog steeds die noodgreep toepast, maar reply volgt....

[anoniem]

[quote:f422f32707="YoupY"]ATM ff weinig tijd om precieze linkjes bij elkaar te zoeken enz, maar reply komt er nog aan.[/quote:f422f32707]Same here. I'll be back 8)

[anoniem]

[quote:aaeeaee443="egslim"]Jullie praten een beetje langs elkaar heen, vanuit een software standpunt is de swapfile gewoon extra geheugen. Maar vanuit een hardware standpunt is de swap zo gruwelijk traag dat je het als het even kan niet wilt gebruiken.[/quote:aaeeaee443]Klopt, maar ondanks dat swap mem traag is, blijft het 'geheugen' dat geadresseerd moet worden door de CPU. Tenminste, dat is wat mij geleerd is (of ik heb iid écht liggen slapen...) [quote:aaeeaee443]Hier heb je gelijk in. De 36 bits hack is PAE, maar om die te kunnen gebruiken heb je speciale software ondersteuning nodig die in de consumentenmarkt ontbreekt. Daar komt bij dat het ook geen echte 36 bits is, maar 32 bits segmenten binnen een 36 bits geheugenruimte. Heen en weer springen tussen de verschillende segmenten is ook niet triviaal, voor de software en voor de prestaties. En als een 32 bits segment te klein is heb je pech. Dat alles maakt de hack totaal onbruikbaar voor de gewone desktop.[/quote:aaeeaee443] PAE staat voor? Ik geef onmiddelijk toe dat ik geen idee heb hoe dat '36-bits' geadresseer werkt, of wat voor bokkensprong Intel daar gemaakt heeft. Kun je het iets duidelijker proberen uit te leggen? [quote:aaeeaee443][quote:aaeeaee443]De switch naar 64 bits heeft niet alleen te maken met een toekomstig gebrek aan adresseerbaar geheugen. Het heeft vooral te maken met de verwerkingssnelheid van data. Een 64 bits brede databus kan theoretisch per klokslag nou eenmaal 2x zoveel data verstouwen tov een 32 bits databus. [/quote:aaeeaee443] Dit is niet waar. Geheugenadressering is de enige reden dat AMD de x86 instructieset heeft uitgebreid naar 64 bits. Om van de nood een deugd te maken hebben ze tegelijkertijd een aantal registers toegevoegd en een aantal archaïsche instructies eruit gekicked.[/quote:aaeeaee443]Nou ja, mijn vergelijking gaat sowiezo scheef, want een 64 bits brede databus heeft niet zoveel met een 64 bits register voor adressering te maken. Daarnaast heb ik links en rechts gelezen dat dat databus al sinds de P1 ofzo opgerekt is naar 64 bits. Maar nooit geweten dat geheugen adressering de enige reden was om over te gaan op 64-bits. Ik dacht dat het meer de combinatie van factoren was: In de toekomst is 64-bits waarschijnlijk vereist, DUS gooien we de hele architectuur op de schop, verbreden idd de registers naar 64 bits en verdubbelen meteen het aantal (naar 16). [quote:aaeeaee443]Sterker nog, in principe presteert een 32 bits CPU bijna altijd beter dan een 64 bits. Om de simpele reden dat een CPU praktisch altijd met getallen werkt die kleiner zijn dan 32 bits. Maak je die 64 bits, dan nemen ze dus alleen maar meer ruimte in. Vergelijk 0001 + 0010 (4 bits) en 00000001 + 00000010 (8 bits). Ze geven dezelfde uitkomst, maar de eerste is makkelijker op te slaan en uit te rekenen. Enige waar 64 bits getallen voor van pas komen is encryptie.[/quote:aaeeaee443]Ik heb [url=http://www.cpuid.com/K8/index.php]hier[/url] gelezen dat - juist door de specifieke implementatie van AMD - het voordeel voor 32 bits tov. 64 bits wel meevalt. Door AMD's implementatie worden 32 bits instructies in 64 bits code maar 1 byte groter dan native 32 bits instructies. Maar omdat 64 bits gecompileerde code gebruik kan maken van het dubbele aantal registers, wordt dat nadeel - afhankelijk van diverse factoren - weggestreept tegen een efficientere code.[quote:aaeeaee443]Ten eerste hebben de prestaties inderdaad helemaal niets met de bitheid van de CPU te maken, zolang je ten minste niet naar encryptiesoftware kijkt.[/quote:aaeeaee443]Volgens mij is dat een beetje voorbarig. Idd is zeker niet alles in 64 bits code sneller, of überhaupt nodig (waarom 64 bits als het in 32 bits ook kan). Maar ik kan me voorstellen dat er meer toepassingen zijn/komen die voordeel halen uit 64 bits code. Juist de uitbreiding van het aantal registers en daarmee mogelijk efficientere code mag je ervan uitgaan men er waarschijnlijk iig niet sterk op achteruit gaat. [quote:aaeeaee443][quote:aaeeaee443]Natuurlijk kan een hogere IPC de prestaties oppeppen. Maar vooral de gewijzigde cache strategie bij de Athlon64 zorgt voor de performance boost, want verder lijkt hij sterk op de K7 core: http://www.cpuid.com/K8/index.php[/quote:aaeeaee443] Als je met cache strategie de ingebouwde geheugencontroller bedoelt heb je gelijk. Maar voor K8 heeft AMD grote delen van de K7 eruit gehaald, opnieuw ontworpen en weer teruggestopt. Het is veel meer dan een K7 met ingebouwde geheugencontroller.[/quote:aaeeaee443]Ja, mijn conclusie was een beetje kort door de bocht. Een K8 is idd meer dan een K7 met gewijzigde mem controller. Maar goed, ze lijken in bepaalde onderdelen wel sterk op elkaar. BTW, Eildert, ik heb gelezen dat de Athlon 64 een 40bits register voor fysieke geheugen adresssering en een 48 bits register voor de virtuele mem adressering gebruikt, maar ik heb geen idee hoe ze dat precies geïmplementeerd hebben? Jij wel (naar ik aanneem 8) )?