[C/C++ VxWorks] Executietijd functie

[Rowwan]

Hoe kan ik de executietijd van een functie meten in nanoseconden?? Op internet kom ik vanalles tegen over clock-functies maar eigenlijk niks bruikbaars...

[curry684]

Nanoseconden? Wauw jij bent optimistisch De meest precieze timers van je systeem zijn de Performance Counters oftewel Multimedia Timers van je moederbord. Onder Windows kun je die opvragen met QueryPerformanceCounter en co, maar ik heb er nog nooit van gehoord dat ze onder andere omgevingen (zoals VxWorks) eenvoudig binnengetrokken konden worden.

Kzou eens zoeken op die termen die ik noemen, wellicht vind je ergens nuttige ASM die ze kan trekken...

[hobbit_be]

ik geloof dat je in PII and upwards via asm wel kunt vragen hoeveel 'clock' (ie cpu cycles) er zijn gebeurt vanaf een punt x.... maar of die nou handig is (een cpu cycle is natuurlijk wel direct samen met 'nanos'. Maar wel pure asm dus niet echt compatible.

de handigste method is gewoon die fucntie een paar duizend (millioen) keer aanroepen met een 'gewone' timer dan krijg je een gemiddelde. Een functie call hoeft niet perse altijd hetzelfde te zijn...

[.oisyn]

in de standaard C lib zit een functie clock () waarmee je tijdsverschillen kunt meten (ik geloof dat die functie retourneert hoe lang je programma al draait)

Als je deelt door CLOCKS_PER_SEC dan krijg je de tijd in seconden

De resolutie ervan valt echter wel tegen. Onder win32 is CLOCKS_PER_SEC altijd 1000 en heeft ie ook een resolutie van 1 ms. Onder linux is de resolutie nog lager, ik geloof iets van 55 ms

[Rowwan]

Mmmmm... De optie van hobbit_be lijkt me nog het beste.. Niet compatible, maar dat is ook niet nodig...

[Korben]

Ik heb even n testje gedraaid; op mijn systeem heeft de multimedia-timer onder Win32 een resolutie van 3579545 ticks per seconde. Minder dan een nanoseconde per tick dus.

[curry684]

De officiele resolutie ligt wel zo hoog (zei ik ook), maar 2 subsequent queries liggen aardig wat ticks uit mekaar. Vandaar mijn 'hoongelach' over het meten in nanoseconden

En beide genoemde methodes hebben hetzelfde probleem dat ze niet task-switch-proof zijn.

[matthijsln]

Bij x86 processors kan je de rdtsc instructie gebruiken om het aantal clockticks sinds het opstarten zetten in edx:eax.

Natuurlijk moet je rekening houden met task switches, pipelining en andere bijkomstigheden van je profiling code.

[Rowwan]

Volgens de "experts" is het task switchen van vxworks nu net het probleem. Dit schijnt een erg storende factor te zijn tijdens het meten... Is er niet ergens een tooltje dat de clockcycles (ongeveer) uitrekend? Ik kan me voorstellen dat dit niet zo moeilijk zo moeten zijn.

[RickN]

Korben schreef op 28 April 2003 @ 16:24:
Ik heb even n testje gedraaid; op mijn systeem heeft de multimedia-timer onder Win32 een resolutie van 3579545 ticks per seconde. Minder dan een nanomicroseconde per tick dus.

[curry684]

Rowwan schreef op 29 april 2003 @ 07:25:
Volgens de "experts" is het task switchen van vxworks nu net het probleem. Dit schijnt een erg storende factor te zijn tijdens het meten

Met een foutmarge van 1 tot ~10000% niet echt verwaarloosbaar nee. Maar iedere kernel die ik ken meet CPU-tijd per proces en thread, echter deze tellers halen geen microsecondeprecisie.

Je zoekt dan de VxWorks equivalent van deze functie.