28 svar · 746 visningar · startad av fluff · sida 2 av 2
Hej. Jag tänkte snickra ihop nåt litet program som utför 'cpu intensiva' operationer och tar tid på det, för skojs skull :D Tidtagningen är lätt, men jag lyckas inte komma på nån operation som tar väldigt mycket kraft! Kör just nu en liten for-sats som dubblar ett tal massa gånger samt skriver ut det, men om man tar bort själva utmatningen till skärmen så går det på 0.0001 sekunder :o Hur gö
Läs frågan i sin helhet →Japp, debug-skillnaden har jag märkt :D
Men, kan man 'mäta' nånting så det blir 'jämt' mellan olika OS? :O
Sen tycker jag resultatet med clock() på linux-datorn är helmysko, jag menar. jag VET att det tog flera minuter, returnerar inte clock() samma info på olika OS? :q
Jag menar, 1 'clock()' enhet är väl 1 'clock()' enhet på ett annat os?
developer skrev:
Du vet då säkert också att ändra IRQL är något man inte gör i vanliga applikationer i usermode, utan just drivrutiner i kernelmode.
Ja, visst vet jag det. Men om man nu exakt ska "tima" en tät kodsnutt utan att behöva
ta hänsyn till att operativet ligger och switchar mellan trådar så kan det väl
i vissa fall vara en bra idé? Fast allt detta beror ju på hur koden
ser ut och vad syftet är. Vill vi jämföra två olika algoritmer på samma maskin?
Eller vill vi jämföra hur "samma" kod uppför sig på två olika OS?
Vad är det mest "ödesdigra" som kan inträffa? Att musen "fastnar" och att man
måste trycka på resetknappen?
fluff skrev:
Men, kan man 'mäta' nånting så det blir 'jämt' mellan olika OS? :O
Ja, exekveringstiden. Som jag föreslog tidigare, gör mätningen under en längre tid så du får ett stabilt medelvärde.
Men jag förstår inte vad du är ute efter. Vill du se hur två operativsystem utför samma kod, ska du köra på samma maskin för att kunna göra en rättvis mätning. Dessutom borde du inte använda C Runtimen för att allokera, eftersom då får väldigt stor påverkan fast den inte alls är en del av operativsystemet. Att se hur snabbt man kan allokera heapminne från OS:et är väl iofs kanske intressant, men siktar man på hög prestanda vinner man oberoende av OS på att eftersträva att undvika heap-allokeringar i största möjliga mån.
fluff skrev:
Sen tycker jag resultatet med clock() på linux-datorn är helmysko, jag menar. jag VET att det tog flera minuter, returnerar inte clock() samma info på olika OS? :q
Jag menar, 1 'clock()' enhet är väl 1 'clock()' enhet på ett annat os?
Läs "How Many Ways Can You Tell Time? " mot slutet av dokumentet här: http://www.embedded.com/2000/0010/0010feat1.htm
niko skrev:
Ja, visst vet jag det. Men om man nu exakt ska "tima" en tät kodsnutt utan att behöva
ta hänsyn till att operativet ligger och switchar mellan trådar så kan det väl
i vissa fall vara en bra idé? Fast allt detta beror ju på hur koden
ser ut och vad syftet är. Vill vi jämföra två olika algoritmer på samma maskin?
Eller vill vi jämföra hur "samma" kod uppför sig på två olika OS?Vad är det mest "ödesdigra" som kan inträffa? Att musen "fastnar" och att man
måste trycka på resetknappen?
Poängen att göra mätningen under en längre tid är att påverkan av kringliggande saker minskar så de blir obetydliga i sammanhanget. Det är väl ganska uppenbart att man inte samtidigt håller på att defragmentera hårddisken och kör håller på med en brute-force knäckning samtidigt, utan datorns enda tunga jobb ska vara testet man vill utföra. Jag ser ingen vinst i att försöka med det du föreslår, det skulle bara kunna orsaka problem. Vad händer exempelvis om man får ett page fault och måste läsa från pagefilen när du gjort CLI?
Ska man göra bättre mätningar än så är det bästa sättet att använda en bra profiler, exempelvis: http://www.compuware.com/products/devpartner/profiler/
Marcus E skrev:
Det ska du vara glad för. Att stänga av avbrottsförfrågningar (cli) kan vara (är) ödesdigert. Hela systemet kraschar antagligen.
Man kan ju alltid ändra prioritet med SetPriorityClass(,)
developer skrev:
rdtsc är bra (lättare att använda än GetTickCount eftersom den inte slår runt). Man bör dock bara medveten om att många processorer varierar frekvensen för att spara ström och då fungerar rdtsc dåligt för tidsmätning.
Ja, det krånglar ju onkeligen till det lite...
Men om man utför sådana operationer att CPU load hela tiden ligger på 100% så bör det ju inte vara några som helst problem. Processorn måste ju ligga på sin maxfrekvens när det behövs, annars skulle jag köpa en ny processor.
developer skrev:
Vad händer exempelvis om man får ett page fault och måste läsa från pagefilen när du gjort CLI?
Tja, ingenting? Hanteringen av pagefaultet når aldrig fram och man läser glatt vidare från
helt fel minnesutrymme. Som sagt, om man anropar cli så får man nog veta vad man gör och
se till att de variabler man använder finns där de ska. (Finns möjlighet att allokera "oswapbara"
delar av minnet.)
Dock har jag fortfarande svårt att se några "ödesdigrare" konsekvenser än att man kan bli
tvungen att trycka reset. Någon skrivning till disk kan ju tex aldrig ske eftersom den
kräver interrupts som ändå aldrig når fram.
Men, men .. Känner mig väldigt off-topic (och delvis besegrad) så jag lägger därför ner diskussionen. :)
fluff skrev:
Jag menar, 1 'clock()' enhet är väl 1 'clock()' enhet på ett annat os?
Absolut inte.
CLOCKS_PER_SEC anger hur många clock_t det går på en sekund.
Det kan va lite knepigt. Beroende på vad du gör så kan ju operativet gör en hel massa saker "bakom kulisserna" och då kommer du att få konstiga mätresultat varje gång du kör programmet beroende på en rad faktorer.
Okaj.
Så om jag visar stopClocks-startClocks / CLOCKS_PER_SEC så kommer det visa sekundrarna, oavsett plattform? :o
Kan man få det lite mer precist, med millisekunder eller dylikt :birp
wee, har testat detta på olika OS:
#include <iostream>
#include <ctime>
using namespace std;
void main() {
cout << CLOCKS_PER_SEC;
}
På debian blir det 1000000, på Mac OS X / openBSD 3.0 blir det 100, i windows blir det 1000..