Salve a tutti, avrei una domanda da porre a voi appassionati di elettronica. Supponiamo di avere un programma al mio PC di cui voglio conoscere le performance, cioe' la velocita' con cui esegue calcoli.
Per fare cio' faccio misurare al mio PC (in automatico) il tempo necessario affinche il mio programma svolga un determinato calcolo. Qual'e' la precisione massima praticamente raggiungibile che il mio pc puo' raggingere sulla misura del tempo di calcolo? In altre parole, quale frazione di secondo è in grado di spaccare l'orologio del mio (o un comune) PC?
Se il mio PC ha un processore che funziona a 3 GHz è corretto dire che l'orologio puo' arrivare ad una precisione di 1/3,000,000,000 di secondo?
no la precisione del tuo orologio non ha nulla a che vedere con la frequenza di clock del tuo processore. Sicuramente c'è chi ti potrà dare una risposta più certa e precisa ma penso che la tua richiesta non abbia una risposta univoca. L'orologio del pc non è poi tanto preciso e la sua precisione dipende dalla tua motherboard (e dal chip dell'orologio che monta a bordo).
Bisogna fare parecchie considerazioni. Intanto ti posso garantire che l'RTC dei PC non =E8 una risorsa precisa per questo tipo di misurazioni. Dipende essenzialmente dal sistema operativo. Anticamente, l'MS-DOS caricava l'ora dall'RTC su boot e poi l'aggiornamento dipendeva dal software per mezzo degli interrupt di sistema, basati sulle frequenze precise ricavate dal quarzo a 14.318 MHz. Il quarzino da 32.768 kHz serviva solo per mantenere aggiornati ora e data a macchina SPENTA. L'orario, quindi, era aggiornato dal software circa 60 volte al secondo. E' evidente che la precisione dell'RTC =E8 insufficiente per misurare performance di programmi di brevissima durata, mentre diviene utile su lunghi periodi (decine di secondi, magari).
In base a questo, sarebbe bene basarsi sui contatori standard di scheda madre riferiti al vecchio ma ancora integrato IC Intel 8254 (3 contatori a 16 bit). Uno =E8 usato per il refresh delle RAM (ora inutile ma credo mantenuto per compatibilit=E0). Il secondo per l'RTC. Il terzo per il buzzer. Ciascuno di essi divide praticamente lo stesso clock per fattori diversi anche se, credo, giunga agli ingressi gi=E0 con fattori di divisione differenti.
La considerazione pi=F9 importante, comunque, riguarda il tipo di test. Se il programma gira sotto un OS multitasking (praticamente tutti), la divisione di tempo falser=E0 sempre i risultati sul medio termine (millisecondi). O il programma =E8 estremamente corto da non richiedere abbastanza tempo per non essere interrotto dal sistema o deve essere abbastanza lungo per rendere insignificante il tempo "rubato" dallo scheduler e da tutto ci=F2 che frena la macchina. Inutile dire che pi=F9 task sono attivi, pi=F9 la misurazione perde di significato.
Non è essato. Cioè sono daccordo con te che OS ci mette parecchio di suo, pero' i programmi non e che vengono schedulati quando pare al OS. Voglio dire, vengono schedulati se sono in IDLE. Se uno fa
for ( ; ; );
ti blocchi il PC anche con un sistema multitasking ( o per lo meno lo rallenti molto ) perché fai schizzare la CPU a 100% ( anche se in realtà non stai facendo niente ) per il semplice fatto che non dai mai il controllo al Sistema operativo. Il sistema operativo schedulerà ma schedulerà molti pochi processi ( giusto quelli "vitali" ).
E per questo che se uno ha un for molto impegnativo è sempre consiglibile mettere al suo interno un "sleep( 1 )" proprio per ridare il controllo al sistema operativo e non bloccare tutto il sistema.
Io di mio per vedere quanto ci mette un operazione chido l'ora all'inzio ( compresi i centesimi di secondo ) faccio quello che devo fare
e poi li richiedo alla fine e poi faccio la differenza.
Ovvio comunque che non si puo' sperare di beccari operazioni piccole ma su operazioni "complesse" ci si riesce ( che so il rendering di una scena tanto per dirne una ).
--
Il Razziatore,
"Lo sviluppo di una nazione si misura anche dallo stato della sua rete
ferroviaria". Camillo Benso Conte di Cavour
"Per tutto quanto non previsto nel presente regolamento il capostazione
deve usare senno e ponderatezza." Regolamento d'esercizio FS
-----------------------------------------------
MSN : IlRazziatore@netscape.net
ICQ : 67552596
Yhaoo : Razziatore82
-----------------------------------------------
Founder of MediaPlayer Project
http://razziatore.no-ip.com/mpp/
[Il Razziatore]
[Piccio] Analogamente, sui micro mando alto un segnale I/O all'inizio di una routine o interrupt e lo abbasso all'uscita. Con l'oscilloscopio mi rendo conto precisamente del tempo di calcolo. Con altri I/O creo anche dei trigger.
[Il Razziatore]
[Piccio] I miei ordini di grandezza sono molto inferiori, di solito adeguati ad inseguire degli eventi molto veloci. Molte volte mi son trovato nelle condizioni di adeguare le temporizzazioni con ritardi calcolati in base all'esecuzione di istruzioni (NOP per eccellenza). Un millisecondo =E8 un eone in certi casi. :-)
L'RTC sulla scheda madre ha una cadenza di 18.2 Hz, quindi non è molto preciso.
Tuttavia da diversi anni a questa parte (dai Pentium in poi), tutti i processori x86 possiedono un registro detto Time Stamp Counter che viene incrementato ad ogni colpo di clock, quindi se possiedi un processore a
3 Ghz, avrai un 3 miliardi di cicli di clock al secondo e quindi in teoria puoi misurare in modo estremamente preciso un intervallo di tempo leggendo prima e dopo il TSC e facendone la differenza.
Il problema viene dopo, perchè in realtà il processore non va' esattamente a 3.000.000.000 Hz, per cui il TSC da solo è inutile se devi misurare quanti secondi impiega il tuo algoritmo/software/cronometro a svolgere il suo compito.
Esiste un altro contatore, credo implementato fisicamente sulla scheda madre da qualche parte, che ha un clock intorno ai 3 Mhz mi pare, quindi abbastanza preciso per gli usi generali, che però ha il vantaggio di essere fisso e quindi risulta facile rapportare i cicli di clock con il tempo in secondi.
Se non vuoi sbatterti troppo, Windows mette a disposizione due api di kernel32.dll che sono QueryPerformanceCounter e QueryPerformanceFrequency che in genere offrono un contatore ad alta risoluzione se disponibile nel sistema. La prima restituisce un intero a
64 bit il cui valore è il contatore, mentre la seconda restituisce la frequenza del contatore. Con queste due api puoi creare qualunque cronometro tu abbia bisogno.
Il giorno Mon, 13 Oct 2008 00:09:55 +0200, blackshard ha scritto:
Il compilatore C DJGPP ha la funzione
uclock_t uclock(void);
definita in time.h:
"This function returns the number of uclock ticks since an arbitrary time, actually, since the first call to uclock, which itself returns zero. The number of tics per second is UCLOCKS_PER_SEC (declared in the `time.h' header file.
uclock is provided for very high-resolution timing. It is currently accurate to better than 1 microsecond (actually about 840 nanoseconds). You cannot time across two midnights with this implementation, giving a maximum useful period of 48 hours and an effective limit of 24 hours. Casting to a 32-bit integer limits its usefulness to about an hour before 32 bits will wrap."
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.