|
Joined: Sep 2007
Posts: 109
Vogon poet
|
OP
Vogon poet
Joined: Sep 2007
Posts: 109 |
We can measure the speed of a code to know which is better?
|
|
|
|
Joined: Jan 2009
Posts: 116
Vogon poet
|
Vogon poet
Joined: Jan 2009
Posts: 116 |
you could store $ticks or $ctime in a variable at the start of a script, then calculate the difference at the end. for example: var %ticks $ticks
;; code goes here
echo -a completed in $calc(($ticks - %ticks) / 1000) seconds.
http://zowb.net/server -m irc.p2p-network.net -j #zomgwtfbbq (ssl on port 6697 and 7000)
|
|
|
|
Joined: Sep 2007
Posts: 109
Vogon poet
|
OP
Vogon poet
Joined: Sep 2007
Posts: 109 |
Thank you very much Knoeki!!!
Another question... There are other types of measures?
-Thanks again-
|
|
|
|
Joined: Jan 2007
Posts: 1,156
Hoopy frood
|
Hoopy frood
Joined: Jan 2007
Posts: 1,156 |
To test speed of execution what else do you have to test but the time it takes?
To truly test you need to try it many times. Like 20,000.
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
I have heard of other measuring types, but they are not relevant to mIRC. I recommend using $ticks rather than $ctime as $ticks is measured in milliseconds. Please also note that my experience with $ticks has shown that it can be off by anywhere up to 5 milliseconds.
Thus if your timing using $ticks shows 45 milliseconds, it could really be as low as 40 or as high as 50.
This probably is subject to the speed of the system, but I haven't noticed a difference between my systems, the slowest of which is 866 Mhz, the fastest 2.2 Ghz.
|
|
|
|
Joined: Jan 2009
Posts: 116
Vogon poet
|
Vogon poet
Joined: Jan 2009
Posts: 116 |
Please also note that my experience with $ticks has shown that it can be off by anywhere up to 5 milliseconds.
Thus if your timing using $ticks shows 45 milliseconds, it could really be as low as 40 or as high as 50. Interesting. From other sources I hear that it can be off by as many as *150*ms. Besides, it doesn't *actually* count miliseconds, it just happens to be damn well close enough for most cases. I'd still wish there was a way to calculate the execution time of a script in miliseconds WITHOUT the inaccuracies of $ticks.
http://zowb.net/server -m irc.p2p-network.net -j #zomgwtfbbq (ssl on port 6697 and 7000)
|
|
|
|
Joined: Feb 2006
Posts: 546
Fjord artisan
|
Fjord artisan
Joined: Feb 2006
Posts: 546 |
general reply: i had an idea a while ago about an improvement that could be made on existing benchmark scripts. it does not result in benchmarking perfection (that's rather unrealistic), but it's a step towards it i hope :P the idea involves a certain bold assumption, which is obviously not valid in general, but it's a small modification that we can make to try and compare scripts in a standard way. in particular, it assumes that if you run 2 pieces of code on 2 different machines, the ratio between the execution times on each machine will be the same. this approach is naive and greatly underestimates the true nature of processing code! however, it can be quite accurate and is probably worth considering, so i've modified the code and added some comments:
; /benchmark <N> [-icm] <text>
;
; Switches: i = identifiers, c = basic commands, m = multiple commands
;
; With no switches it defaults to evaluating <text> as a command unless
; it contains what appears to be identifiers or variables.
;
; You can suppress the first more technical echo with /.benchmark
;
; Identifiers are tested using /!noop <text>
; Commands are tested using /<text>
; Multiple commands are tested using /!scid $cid <text>
;
; If you wish to benchmark structures such as if statements, while
; loops or /var, you need to use the 'm' switch.
;
; The 'speed factor' is an attempt to standardize the results of these
; benchmarks across a variety of machines by calculating (before and
; after the main benchmark) the time it takes for your PC to perform a
; simple while loop which it then uses in the overall calculation.
; If done correctly, a 'speed factor' should be a property of <text>
; and should be independent of the number of iterations and, more
; importantly, the PC the benchmark is performed on.
;
;
; Basic operations such as the evaluation of $null seem to have
; a speed factor of around 1 or less.
;
; Examples:
;
; /benchmark 20000 -i $crc(text, 0)
; /benchmark 20000 -i $hash(text, 32)
;
; /.benchmark 10000 -m if (8 & 1) noop
; /.benchmark 10000 -m if (2 \\ 8) noop
;
; /benchmark 200 -c /myalias
alias benchmark {
var %i = 50000 | ; number of iterations to use to determine the 'speed factor'
if ($1 !isnum) {
echo -egac info * /benchmark <N> [-icm] <text>
return
}
var %before = %i, %after = %i, %main = $1, %cid = $cid, %identifier, %command, %multi, %out
if ($2 == -c) {
%out = / $+ $3-
%command = $3-
}
elseif ($2 == -i) {
%out = /!noop $3-
%identifier = $3-
}
elseif ($2 == -m) {
%out = /!scid % $+ cid $3-
%multi = $3-
}
elseif ($wildtok($2-, $!*, 1, 32)) || ($wildtok($2-, % $+ *, 1, 32)) {
%out = /!noop $2-
%identifier = $2-
}
else {
%out = / $+ $2-
%identifier = $2-
}
!set -l %time $ticks
while (%before) !dec %before
!set -l %before $ticks - %time
if (%command != $null) {
!set -l %time $ticks
while (%main) {
[ [ %command ] ]
!dec %main
}
!set -l %main $ticks - %time
}
elseif (%multi != $null) {
!set -l %time $ticks
while (%main) {
!scid %cid %multi
!dec %main
}
!set -l %main $ticks - %time
}
else {
!set -l %time $ticks
while (%main) {
!noop [ [ %identifier ] ]
!dec %main
}
!set -l %main $ticks - %time
}
!set -l %time $ticks
while (%after) !dec %after
!set -l %after $ticks - %time
var %total = %before + %after
echo -qgace info First loop: %before $+ ms - Second loop: %after $+ ms - A total of $&
%total $+ ms for $calc(2 * %i) trivial cycles ( $+ $calc(%total / 2 / %i) $+ ms per cycle)
linesep -a
echo -gac info2 Results for $1 cycles of: %out
echo -gac info2 %main $+ ms for $1 cycles ( $+ $calc(%main / $1) $+ ms per cycle) - Speed factor: $&
$calc((%main / $1) / (%total / %i))
linesep -a
}
it is important to minimize the overhead involved when performing the actual benchmark (while at the same time remaining pragmatic and considering differences on the order of what is actually measurable) which is why some of the code may look a little funny.
"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
|
|
|
|
Joined: Nov 2009
Posts: 295
Fjord artisan
|
Fjord artisan
Joined: Nov 2009
Posts: 295 |
I found a DLL that gets time in a better way than mirc. At least back in 2006 when the DLL was made. Granted I notice a difference between the DLL and $ticks http://www.mircscripts.org/comments.php?cid=2972try this, with the time.dll in the mirc dir
//clear | echo -a $ticks $dll(time.dll,GetTime,.) | .timer -m 1 10 echo -a $!ticks $!dll(time.dll,GetTime,.)
time.dll seems to give better time than $ticks, but please remember there will be inconsistencies with the timer etc. $ticks also seems to be +200 from what time.dll returns, i wouldn't know why though. disclaimer: These are just the results I got on my pc with mirc 7.1. Any different results should be expected. (simply, just don't flame me or anything, lol)
|
|
|
|
|