[C] ORARIO DI SISTEMA

[gio_085]

Salve a tutti!Io avrei bisogno di trovare il codice in c che mi permette di conoscere l'orario del sistema. In particolare ho bisogno che il valore restituito sia di una precisione dell'ordine dei microsecondi..visto che mi serve per verificare le prestazioni di un protocollo..qualcuno mi può aiutare??!

[71104]

in C ci sono una miriade di funzioni che servono a prendere il tempo; una che misura anche i microsecondi è questa qua:
http://www.linuxmanpages.com/man2/gettimeofday.2.php

ma forse a quei livelli avresti bisogno di un sistema realtime...

[gio_085]

io al momento devo solo far in modo che in un determinato istante che do io in ingresso come variabile mi parta un'operazione di misura senza utilizzare il real time..

[variabilepippo]

io al momento devo solo far in modo che in un determinato istante che do io in ingresso come variabile mi parta un'operazione di misura senza utilizzare il real time..

Anche perché non potresti... I sistemi operativi mainstream non supportano il realtime dunque presentano limitazioni (assolutamente non trascurabili se gli intervalli temporali di riferimento sono molto brevi) sulla risoluzione dei timer e sulla precisione delle misurazioni.

Anche usando un timer ad alta risoluzione dovrai tenere conto dell'overhead delle chiamate, dei limiti hardware e dell'esistenza di un ambiente multitasking.

[71104]

Originariamente inviato da variabilepippo

Anche usando un timer ad alta risoluzione dovrai tenere conto dell'overhead delle chiamate, dei limiti hardware e dell'esistenza di un ambiente multitasking.

tra tutte queste limitazioni è possibile eliminare almeno quella del multitasking utilizzando l'API Win32 GetProcessTimes, che permette di trovare il tempo trascorso in user mode dal singolo processo; è utile ad esempio per misurare il tempo richiesto da un algoritmo evitando di contare il tempo utilizzato dal dispatcher e da altri processi durante l'esecuzione dello stesso, ed inoltre ha una risoluzione molto elevata (intervalli di 100 nanosecondi, non ricordo quanti nanosecondi sia un microsecondo ma a occhio 100 nanosecondi dovrebbero essere un decimo di microsecondo).

[variabilepippo]

tra tutte queste limitazioni è possibile eliminare almeno quella del multitasking utilizzando l'API Win32 GetProcessTimes, che permette di trovare il tempo trascorso in user mode dal singolo processo; è utile ad esempio per misurare il tempo richiesto da un algoritmo evitando di contare il tempo utilizzato dal dispatcher e da altri processi durante l'esecuzione dello stesso, ed inoltre ha una risoluzione molto elevata

Se non ricordo male GetProcessTimes restituisce i tempi spesi da un intero processo nei contesti kernel mode ed user mode, come può essere usata per misurare il tempo di esecuzione di un algoritmo?

[71104]

Originariamente inviato da variabilepippo

Se non ricordo male GetProcessTimes restituisce i tempi spesi da un intero processo nei contesti kernel mode ed user mode, come può essere usata per misurare il tempo di esecuzione di un algoritmo?

se nel processo gira un solo thread non mi pare molto difficile, basta prendere il tempo trascorso in user-mode...

[variabilepippo]

se nel processo gira un solo thread non mi pare molto difficile

Ok, ma un conto è misurare il tempo speso in un thread/processo, un altro è effettuare il benchmark di un algoritmo: sia dal punto di vista concettuale che da quello pratico.

[71104]

Originariamente inviato da variabilepippo

Ok, ma un conto è misurare il tempo speso in un thread/processo, un altro è effettuare il benchmark di un algoritmo: sia dal punto di vista concettuale che da quello pratico.

scusa, se io scrivo un programma monothread e voglio misurare il tempo che richiede l'esecuzione di un algoritmo, la differenza dei tempi presi con la GetProcessTimes prima e dopo l'esecuzione mi sembra un ottimo indicatore...

giusto l'altro giorno stavo lavorando ad un progetto per l'università in cui bisognava condurre, come bonus, un "confronto sperimentale" tra alcuni algoritmi su grafi (Dijkstra, Bellman-Ford-Moore, Floyd-Warshall) che la traccia richiedeva di implementare in C. in quel progetto ho sentito la mancanza della funzione GetProcessTimes: non la potevo utilizzare perché le specifiche richiedevano che il codice fosse scritto in puro C89, ma sarebbe stata assolutamente perfetta per misurare i tempi richiesti da ciascuno.
(per la cronaca alla fine ho usato clock).

[variabilepippo]

scusa, se io scrivo un programma monothread e voglio misurare il tempo che richiede l'esecuzione di un algoritmo, la differenza dei tempi presi con la GetProcessTimes prima e dopo l'esecuzione mi sembra un ottimo indicatore...

Ciò è quasi vero sotto l'ipotesi, molto restrittiva peraltro, che il processo non faccia altro e soprattutto dopo aver accettato la forzatura che i termini "processo" ed "algoritmo" siano sinonimi.

Esiste una letteratura sconfinata sulle tecniche di benchmarking e sui pitfall nei quali si può incorrere se si utilizza un approccio troppo naïf.

[71104]

Originariamente inviato da variabilepippo

Ciò è quasi vero sotto l'ipotesi, molto restrittiva peraltro, che il processo non faccia altro e soprattutto dopo aver accettato la forzatura che i termini "processo" ed "algoritmo" siano sinonimi.

che altro può fare il processo se ci gira solo il thread che esegue quell'algoritmo?

[71104]

to', che minchione che sono:

http://msdn2.microsoft.com/en-us/library/ms683237.aspx

[variabilepippo]

che altro può fare il processo se ci gira solo il thread che esegue quell'algoritmo?

Anche tralasciando la questione processo/thread un programma non didattico fa tante altre cosette oltre ad implementare un dato algoritmo... Se un programmatore professionista pretendesse di usare la GetProcessTimes per effettuare un benchmark "serio" credo che finirebbe (giustamente) impalato su pubblica piazza.

[71104]

Originariamente inviato da variabilepippo

Anche tralasciando la questione processo/thread un programma non didattico fa tante altre cosette oltre ad implementare un dato algoritmo...

su Linux forse, a causa di quella porcata chiamata segnali, ma su Win32 ti assicuro che un thread può fare una sola cosa per volta.

Se un programmatore professionista pretendesse di usare la GetProcessTimes per effettuare un benchmark "serio" credo che finirebbe (giustamente) impalato su pubblica piazza.

e tu che proponi di meglio? posto che già abbiamo appurato che esiste una funzione migliore, ovvero la GetThreadTimes (vedi mio post precedente).

[variabilepippo]

su Linux forse, a causa di quella porcata chiamata segnali, ma su Win32 ti assicuro che un thread può fare una sola cosa per volta.

Ripeto, in un'applicazione non banale non è possibile misurare le prestazioni di un algoritmo valutando acriticamente il risultato di una GetThreadTimes o, ancora peggio, di una GetProcessTimes. Innanzitutto perché bisognerebbe prendere in considerazione la specifica architettura dell'applicazione e l'implementazione dell'algoritmo, l'algoritmo potrebbe essere distribuito su più thread oppure essere eseguito un numero imprecisato di volte (non a caso un benchmark inizia ad assumere un minimo di significato quando si pone in un contesto statistico) mediante molteplici thread.

Come ti ho già fatto notare esiste una letteratura imponente in materia di benchmarking, e sarebbe davvero molto comodo gettarla nella spazzatura chiamando una funzioncina... Purtroppo non è possibile, come non è possibile riassumere tutta la casistica e le soluzioni adottabili in un forum.

[71104]

Originariamente inviato da variabilepippo

Ripeto, in un'applicazione non banale non è possibile misurare le prestazioni di un algoritmo valutando acriticamente il risultato di una GetThreadTimes o, ancora peggio, di una GetProcessTimes. Innanzitutto perché bisognerebbe prendere in considerazione la specifica architettura dell'applicazione e l'implementazione dell'algoritmo, l'algoritmo potrebbe essere distribuito su più thread oppure essere eseguito un numero imprecisato di volte (non a caso un benchmark inizia ad assumere un minimo di significato quando si pone in un contesto statistico) mediante molteplici thread.

Come ti ho già fatto notare esiste una letteratura imponente in materia di benchmarking, e sarebbe davvero molto comodo gettarla nella spazzatura chiamando una funzioncina... Purtroppo non è possibile, come non è possibile riassumere tutta la casistica e le soluzioni adottabili in un forum.

bla bla, bla bla
con tutto rispetto per la letteratura sul benchmarking, l'informatica è una di quelle scienze in cui esiste letteratura per ogni cazzata, indipercui: OT

ricominciamo daccapo: un tizio arriva sul forum e mi chiede una funzione per prendere tempi ad alta risoluzione allo scopo di cronometrare del software; mi pare di non fargli nulla di male nel suggerirgli di prendere i tempi trascorsi in user-mode tramite GetProcessTimes e GetThreadTimes, in quanto gli permettono di eliminare direttamente gli overhead causati dal multitasking di un sistema che realtime non è.

ribadisco: tu che proponi di meglio?

se poi i suoi algoritmi sono implementati in multithreading o in maniera distribuita o infarciti di operazioni che non hanno nulla a che vedere con l'algoritmo, se la vede lui; lui ha chiesto una funzione per cronometrare, poi son fatti suoi.

[variabilepippo]

bla bla, bla bla
con tutto rispetto per la letteratura sul benchmarking, l'informatica è una di quelle scienze in cui esiste letteratura per ogni cazzata, indipercui: OT

Non capisco dov'è l'OT. Visto che stiamo parlando di un benchmark mi sembra il minimo citare la letteratura sull'argomento, senza avere idea delle problematiche (e sono tante!) si rischia di dire castronerie.

Ti suggerisco di fare una prova, cerca getthreadtimes benchmark con Google. Troverai una trentina di paginette scarse, la maggior parte delle quali off-topic. L'unica che ha attinenza con l'argomento (The Poorman's Profiler, il profiler del poveraccio per intenderci) recita:

You will notice that the times will not always be exactly the same. The reason for this is subtle. Although GetThreadTimes() is measuring the number of 100 nanosecond intervals that pass, your PC is not even remotely capable of being able to time anything to that small a degree. At best, one millisecond, but even that requires specialized hardware (use QueryPerformanceFrequency() to see if you have this hardware). This means that the CPU time for each quantum that your thread is scheduled is at best only an approximation. These small inaccuracies add up for very long runs, or for very heavily loaded systems where the scheduler is working overtime (more context switches). For a timing under a few hundred seconds I’ve found that even with a background compile, printing, or file transfers, the return timing varies by only a second or two.

Esistono delle librerie che agevolano le operazioni di benchmarking, non mi risulta che nessuna di esse sia basata su GetProcessTimes o GetThreadTimes, forse perché loro non considerano OT tutta la complessa teoria che sottende l'analisi delle prestazioni.

[71104]

Originariamente inviato da variabilepippo

Ti suggerisco di fare una prova, cerca getthreadtimes benchmark con Google. Troverai una trentina di paginette scarse, la maggior parte delle quali off-topic. L'unica che ha attinenza con l'argomento (The Poorman's Profiler, il profiler del poveraccio per intenderci) recita: [cut]

la parte quotata non mi trova in disaccordo: abbiamo accordato che per cronometrare l'esecuzione di un algoritmo con la precisione richiesta da gio_085 ci sono almeno tre insiemi di problemi: overhead delle chiamate, limiti hardware ed esistenza di un ambiente multitasking. GetThreadTimes, come ho spiegato, consiste in una possibile soluzione al terzo problema, non certo al secondo. anzi per la verità inizialmente citavo GetProcessTimes, ma fai conto che io abbia detto GetThreadTimes fin dall'inizio.

Esistono delle librerie che agevolano le operazioni di benchmarking,

questa la considero la risposta alla domanda su cosa proponi di meglio. a mia volta rispondo chiedendoti: tipo?

[variabilepippo]

Premessa: per il timing di programmini semplici le funzioni di sistema suggerite finora (GetThreadTimes, QueryPerformanceCounter, gettimeofday, ...) vanno più che bene.

L'impalamento scatta d'ufficio quando si cerca di applicare gli stessi metodi a sistemi software di una certa complessità, in tali casi librerie specifiche (es. Google Perfomance Tools) o strumenti quali i profiler (es. Intel VTune) sono indispensabili.

[71104]

Originariamente inviato da variabilepippo

L'impalamento scatta d'ufficio quando si cerca di applicare gli stessi metodi a sistemi software di una certa complessità,

e qui viene l'OT: se lui mi chiede una funzione per prendere i tempi io do per scontato che nel suo caso basti quella.