time a procedure takes in microseconds ? not milli
Blitz3D Forums/Blitz3D Beginners Area/time a procedure takes in microseconds ? not milli
| ||
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 ? |
| ||
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... |
| ||
searching blitz3d queryperformancecounter led me here oh sorry, it's blitzmax code... |
| ||
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" |
| ||
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) |
| ||
@Bobysait>>thanks i will try your function MicroSecs() |
| ||
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. |
| ||
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 |
| ||
microseconds and windows? this will not work because win is not realtime. gtx |
| ||
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. |
| ||
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)... |