Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

Moederborden, processors, overklokken, casemodding en koeling

Vervolg op de geheugendiscussie in het topic van Joske_power

Captain_Kansloos
3 antwoorden
  • 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.
  • :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….
  • [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)

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.