time a procedure takes in microseconds ? not milli

Blitz3D Forums/Blitz3D Beginners Area/time a procedure takes in microseconds ? not milli

RemiD(Posted 2016) [#1]
hello,

from what i have found online :
1 second = 1 000 milliseconds = 1 000 000 microseconds
so 1 millisecond = 1 000 microseconds

and as i understand it, with Blitz3d, we can only get the current milliseconds value since the computer started.

but sometimes, the time in milliseconds is not precise enough to get an idea of the time a procedure takes.
so an ugly workaround that i use is to run the procedure 1000 times so that it gives me an idea of the time it takes in microseconds (or a float value in milliseconds taking into account microseconds) :

(be sure to run the code with debug mode desactivated...)
is there any other (more precise) way to get the microseconds value since the computer started ?


_PJ_(Posted 2016) [#2]
Many years ago I posted a function timing routine on these boards that provides sufficient repetition and accounts for the time delay in the processing of the actual timing itself.

I'll see if I can find the post...


skidracer(Posted 2016) [#3]
searching blitz3d queryperformancecounter led me here

oh sorry, it's blitzmax code...


_PJ_(Posted 2016) [#4]
Well I couldn't find the topic opr posts I mentioned. You might have better luck searching, but all I can say it was at least 3 years ago and maybe as many as 6 - I cannot even recall if this was in Code Archives, B3D or Blitz 3D Beginners...


___

Anyway the crux of the issue are a number of points:

1) As you have identified a number of iterations are required to ascertain a more accurate mean approximation of the duration for a given function. Theoretically, the more iterations, the more accurate result...

2) Each iteration, however incurs a modicum of time that is required for the testing routine to call the function and process the timing as well as keyboard input etc. polling and, if relevant, the compiler/debugger. This will always be included in the total duration recorded. It is therefore necessary to account for this addition and subtract it from the final result.

3) Other factors are also going to severely impact the result. Depending on CPU, this may be multithreading operations from other processes or the OS, the ability to cache repeated code (actually making your function timing faster) and so on.


4)Odd/Even "jump-labels" can even affect timing.

There are a number of other areas under-the-hood in which the duration of one part of the code may actually be affected significantly (i.e. over 50%) by the presence of certain other aspects.

For example, consider the change in the size of the EMPTY (which ought to be fairly static and NOT dependant on any other code-related changes) duration when different variable types are processed in the TEST:


EnableDirectInput False
Delay 500; This just gives Blitz time to pop up its initial window on the screen.
Local Iter

Const TRIALS=8
Const ITERATIONS=1000;Large number for accuracy. Also converts To "µs"

Global EMPTY[TRIALS]
Global TEST[TRIALS]
Global EMPTYTOTAL
Global EMPTYMEAN#
Global TESTTOTAL
Global TESTMEAN#
Global TIMESTAMP

Local Trial
Local PerIter#
Local M
Local Calculate

;POPULATE EMPTY
For Trial= 1 To TRIALS
	TIMESTAMP=MilliSecs()
	For Iter=1 To ITERATIONS
		M=MilliSecs();Tracks time of call
	Next
	EMPTY[Trial-1]=M-TIMESTAMP
Next

;CALCULATE EMPTY MEAN
For Calculate=1 To TRIALS
	EMPTYTOTAL=EMPTYTOTAL+EMPTY[Calculate-1]
Next
EMPTYMEAN#=Float((Float(EMPTYTOTAL)/Float(TRIALS)))

;POPULATE TEST
For Trial=1 To TRIALS
	TIMESTAMP=MilliSecs()
	For Iter=1 To ITERATIONS
		
;INSERT TEST FUNCTION HERE!
		
	Next
	TEST[Trial-1]=MilliSecs()-TIMESTAMP
Next

;CALCULATE TEST MEAN
For Calculate=1 To TRIALS
	TESTTOTAL=TESTTOTAL+TEST[Calculate-1]
Next
TESTMEAN#=Float((Float(TESTTOTAL)/Float(TRIALS)))

Print "Mean duration for function process:"
Print Str(TESTMEAN)+" - "+Str(EMPTYMEAN)+" = "+Str(TESTMEAN-EMPTYMEAN)+"µs"




Bobysait(Posted 2016) [#5]
I'm pretty sure I've add this on an old c++ library I made for blitz3d
It was on google.code, I didn't port it to github so it may be lost, but, I probably have a backup.

[edit]
Ok, I got it
* http://mdt.bigbang.free.fr/bbAddon/v0.4/v0.4.rar (latest stable version)
* http://mdt.bigbang.free.fr/bbAddon/v0.41/v0.41.rar (latest version - some stuff may be broken ... I don't remember)

it contains a lots of addons for blitz3d but it's pretty old now (I'm not even sure it will work with latest versions of blitz3d.
All the sources are available in the archive.

The library also contains :
- linked list
- some maths functions
- scripted class
- a tokenizer
- an event queue manager (like blitzmax')
- a counter sdk (which contains time in microseconds -> require a high definition cpu -> probably available on all 5-10 years old cpu)

(la liste des fonctions disponibles dans le fichier decls)




RemiD(Posted 2016) [#6]
@Bobysait>>thanks i will try your function MicroSecs()


xlsior(Posted 2016) [#7]
Quick and dirty alternative: call your function a thousand times in a row, and measure how many millisecs passed. Divide by 1,000 to see how many microseconds each iteration took.


RemiD(Posted 2016) [#8]

call your function a thousand times in a row, and measure how many millisecs passed. Divide by 1,000 to see how many microseconds each iteration took.


apparently you read the first post ;)


so an ugly workaround that i use is to run the procedure 1000 times so that it gives me an idea of the time it takes in microseconds




Panno(Posted 2016) [#9]
microseconds and windows? this will not work because win is not realtime.

gtx


_PJ_(Posted 2016) [#10]
The accuracy will go right out the window with around 200µs at best.
Although I will concede that milliseconds timing is somewhat ineffective nowadays with a vast majority of processes taking <500µs and therefore any attempts to identify a deltatime of this will show 0 at the millisecond resoluition (due to rounding).
Ideally current spec would probably require 0.1ms as the target fidelity resolution.


RemiD(Posted 2016) [#11]
after some tests, it seems better to run the procedure 100times and then to divide the result by 100 (to have a millisecond value with 0.01 precision) because if you try to measure the mstime it takes of a complex procedure like renderworld, this seems to disturb the result in a weird way (takes more time)...