#29 Du kan jo prøve at køre en compression-test uden boost, og så holde øje med din task-manager. Testen stresser CPU'en max. Hvis du så kører den som single-threaded, så bliver CPU'en kun stresset på en kerne. Husk at komprimeringen kræver en mindre mængde hukommelse, og dette betyder at der er meget trafik i cachen, og da alle kerner deler cache, kan dette være forklaringen 🤡
#30 Nice!
#31 Ser ud som om Everest & BB bruger nogenlunde samme testmetode - men med følgende forskel: Everest bruger 16MB, som læses/skrives i 1MB blokke. BB Bruger 10MB der læses som DWORDS. "Almindelige" programmer kan ikke bruge mem på samme måde som everest, og derfor kan du se det som at everests resultat primært kan overføres til spil & directx programmer, der bruger en anden tilgang til hukommelsen end alm. windåse programmer. Desuden bruger Everest hukommelsen ud fra "best-case-scenario" princippet, og det er kun sjældent at programmer har sådan et scenarie - med alt respekt for everest. BB bruger konventionel adgang til hukommelsen, som kan overføres til feks. Internet Explorer, FireFox, Office osv. Man kan sådan set sige, at BB's måde at skrive/læse hukommelsen på er et "average-case-scenario".
Og hvis vi så lige kigger lidt på matematikken, så kan jeg se at din FSB er ~250Mhz, og du kører dual-channel, som er 128bit - hvilket giver følgende regnestykke for din mem-write formåen:
250 * 128 / 8 = 4000MB/Sec
hvilket svarer til PC-4000 (DDR-500), hvilket er det du har, ikke? Hvis vi tager udgangspunkt i Everest's skrive-resultat på ~5200MB/Sek, så får vi følgende resultat:
5200 * 8 / 128 = 325Mhz
Hvilket svarer til PC2-5300 (DDR2-667).