mboost-dp1
unknown
Jeg kunne godt have tænkt mig at se en test med AMD's nye 4800+ processor...
..Men bort set fra det, så er det da en okay test.
..Men bort set fra det, så er det da en okay test.
Jeg synes mange af deres test er lidt underlige, da de forsøger at starte flere programmer og udføre en række handlinger.
Jeg tror ærlig talt ikke at disse målinger er særlig sigende for hvilken processor der yder bedst - ikke desto mindre forsøger de at lave hvad man vil kalde en mere "almindelig" stress test. Nu er det bare sådan at det mest er harddisken der er en flaskehals.
Men som svar til #1:
Var det ikke intels D 840 der umiddelbart klarede sig bedst?
(personligt foretrækker jeg AMD - men lad det ikke blive til en amd vs. intel diskussion)
Jeg tror ærlig talt ikke at disse målinger er særlig sigende for hvilken processor der yder bedst - ikke desto mindre forsøger de at lave hvad man vil kalde en mere "almindelig" stress test. Nu er det bare sådan at det mest er harddisken der er en flaskehals.
Men som svar til #1:
Var det ikke intels D 840 der umiddelbart klarede sig bedst?
(personligt foretrækker jeg AMD - men lad det ikke blive til en amd vs. intel diskussion)
Jeg undrer mig også lidt over Anandtech's test - at afspille en .ogg fil og have en flok browsere åbne tager kun ganske få procent CPU - selv på min oldtids-PC.
Jeg synes kun det var testen med kompilering og spil samtidigt der virkelig var interessant, da begge disse ting laver en masse IO og bruger meget CPU hele tiden.
Jeg synes kun det var testen med kompilering og spil samtidigt der virkelig var interessant, da begge disse ting laver en masse IO og bruger meget CPU hele tiden.
#5:
AnandTech kører disse fler-process tests fordi en dual-core CPU, eller for den sags skyld et dual CPU system, skal ha' splittet sin process så begge kerner bliver brugt. Men siden der ikke er så mange, er der overhovedet nogen, programmer som er optimeret til det så må man vel bare køre flere programmer af gangen.
Correct me if I'm wrong, men sådan har jeg ihvertfald forstået dual-core CPUer ;)
AnandTech kører disse fler-process tests fordi en dual-core CPU, eller for den sags skyld et dual CPU system, skal ha' splittet sin process så begge kerner bliver brugt. Men siden der ikke er så mange, er der overhovedet nogen, programmer som er optimeret til det så må man vel bare køre flere programmer af gangen.
Correct me if I'm wrong, men sådan har jeg ihvertfald forstået dual-core CPUer ;)
#7 Det jeg kritiserer er, at de programmer de bruger i mange af tests'ne (såsom browsere og lign.) kun bruger CPU i brøkdele af et sekund - d.v.s. det er svært at få nogen fornuftig bedømmelse ud af det, andet end at prøve at se hvor hurtigt vinduerne genoptagnes når man flytter dem hen over skærmen.
Og under Linux bliver programmer som bruger prioritet i lang tid af gangen sikkert automatisk skruet ned i prioritet ligesom i FreeBSD - hvis det er tilfældet, vil den form for test slet ikke give noget særligt godt indtryk af hardwaren.
Det er kun den slags programmer som konstant står og skaber en belastning af en eller anden slags, jeg synes er interessante i en sådan test - og ikke browsere og lign. passive programmer, som 99% af tiden kun står og optager et ram-område.
Og under Linux bliver programmer som bruger prioritet i lang tid af gangen sikkert automatisk skruet ned i prioritet ligesom i FreeBSD - hvis det er tilfældet, vil den form for test slet ikke give noget særligt godt indtryk af hardwaren.
Det er kun den slags programmer som konstant står og skaber en belastning af en eller anden slags, jeg synes er interessante i en sådan test - og ikke browsere og lign. passive programmer, som 99% af tiden kun står og optager et ram-område.
#8
Det er ikke korrekt, du har ret i at selve programmet kun bruger CPU i et par sekunder, men hvis du starter store programmer udløser det disk læsning, med disk buffering og disk cache fyldning til følge, hvilket betyder at når du bagefter starter et andet program er der en stor chance for at systemet skal udføre en masse arbejde baseret på vedligeholdelsen af den disk cache der kører. Det viser noget om hvordan et system med 2 kerner håndterer hukommelsesforbruget og det ligger pres på en god scheduler implementation.
Det du også skal være opmærksom på er at hvis du kører mange processer der hver skal bruge bare en smule cpu engang imellem, så får du en masse process shifting, det bør være mindre betydeligt på dual core cpu'er, hvor man i teorien kunne tillade større timeslices og få bedre performance på den måde, derfor viser det også noget om hvordan systemet håndterer flere processer af gangen. Bemærk at pga. shifting vil 2 timeslices af 2 sekunder nå mindre end 1 timeslice af 4 sekunder, medmindre den skal vente på I/O.
Synes det er meget interessante tests, jeg så dog helst at den var noget mere omfattende, kunne godt bruge en sammenligning med dual cpu systemer.
Det er ikke korrekt, du har ret i at selve programmet kun bruger CPU i et par sekunder, men hvis du starter store programmer udløser det disk læsning, med disk buffering og disk cache fyldning til følge, hvilket betyder at når du bagefter starter et andet program er der en stor chance for at systemet skal udføre en masse arbejde baseret på vedligeholdelsen af den disk cache der kører. Det viser noget om hvordan et system med 2 kerner håndterer hukommelsesforbruget og det ligger pres på en god scheduler implementation.
Det du også skal være opmærksom på er at hvis du kører mange processer der hver skal bruge bare en smule cpu engang imellem, så får du en masse process shifting, det bør være mindre betydeligt på dual core cpu'er, hvor man i teorien kunne tillade større timeslices og få bedre performance på den måde, derfor viser det også noget om hvordan systemet håndterer flere processer af gangen. Bemærk at pga. shifting vil 2 timeslices af 2 sekunder nå mindre end 1 timeslice af 4 sekunder, medmindre den skal vente på I/O.
Synes det er meget interessante tests, jeg så dog helst at den var noget mere omfattende, kunne godt bruge en sammenligning med dual cpu systemer.
#10: Man får kun process shifting sålænge der er mere end en _aktiv_ process per CPU. Og det er der ikke mange chancer for, når der kun er tale om browsere og lign. Og chancerne for process shifting bliver endnu færre, når der nu er 2 CPU'er.
For at der skal ske process shifting (hvilket jeg er enig med dig i, er det interessante), skal der være mindst 3 _kørende_ processer på et system med 2 CPU'er.
For at der skal ske process shifting (hvilket jeg er enig med dig i, er det interessante), skal der være mindst 3 _kørende_ processer på et system med 2 CPU'er.
#11
Tja, prøv engang at kigge på dit process træ (ps -ax eller whatever), og se hvor mange processer du egentligt har der kører. X tager en hel del hos mig (den står jo for drawing), derudover har jeg en masse småprocesser der, selvom de ikke har synligt forbrug, så er jeg ret sikker på at flere af dem laver periodiske checks, der også fremkalder process shifting.
Om alle omstændigheder så hvis du starter processer grafisk (og ikke bruger framebuffer?!?), så har du mindst 2 processer kørende, og X æder trodsalt en hel del cpu tid, min ligger typisk på ½-2% når den er idle, og 3-10% når den er let i brug (periodiske opdateringer af skærmindhold).
Men jeg tror såmænd vi er enige.
Om ikke andet kan vi nok blive enige om at det ikke er så let at finde en måde at teste det her på der tager hensyn til stress testing af alle de faktorer der indgår.
Tja, prøv engang at kigge på dit process træ (ps -ax eller whatever), og se hvor mange processer du egentligt har der kører. X tager en hel del hos mig (den står jo for drawing), derudover har jeg en masse småprocesser der, selvom de ikke har synligt forbrug, så er jeg ret sikker på at flere af dem laver periodiske checks, der også fremkalder process shifting.
Om alle omstændigheder så hvis du starter processer grafisk (og ikke bruger framebuffer?!?), så har du mindst 2 processer kørende, og X æder trodsalt en hel del cpu tid, min ligger typisk på ½-2% når den er idle, og 3-10% når den er let i brug (periodiske opdateringer af skærmindhold).
Men jeg tror såmænd vi er enige.
Om ikke andet kan vi nok blive enige om at det ikke er så let at finde en måde at teste det her på der tager hensyn til stress testing af alle de faktorer der indgår.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund