In REBOL's case the interpretation overhead is probably much bigger than the floating point operations.
Steeve
Hi, playing with perf measures today. It comes that calling a function vs. inlining it gives a +20% speed overcost in my R3 version. And you people ?
>> f: does [1 + 1] >> comp 1000000 [1 + 1][f]
core 2.100.111.3.1 Windows win32-x86 20-Feb-2011/16:24:43 [1 + 1] 0:00:00.131209 [f] 0:00:00.15853 == 20% (on average)
I should add that I run REBOL with WINE on Ubuntu 32 bits.
Here the mezz I used for:
perf: func [n [integer!] b [block!] /local t] [ bind b 'n t: stats/timer repeat i n [n: i do b] stats/timer - t ] comp: func [n [integer!] a [block!] b [block!] /ref][ print reform bind [product version platform build] rebol ref: perf n [] ; time reference for empty code block a: to-decimal probe abs (perf n probe a) - ref b: to-decimal probe abs (perf n probe b) - ref to-percent (to-integer b - a / a * 100) / 100 ]
Gregg
[1 + 1] 0:00:00.04964 [f] 0:00:00.091698 == 84%
Atronix 64-bit on Win7.
Steeve
Did you run it sevearl times just to be sure ?
the overhed seems huge. An explication ?
*overhead
perhaps you should raise the number of iterations. If it's too low for your cpu power. There is more variance in the measures
Gregg
Yeah, could be something funny: >> comp 1000000 [1 + 1][f] atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44 [1 + 1] 0:00:00.043496 [f] 0:00:00.06899 == 58%
It comes to my mind that if recycle is not turned off during the tests, it could explain the variance. So I did the test, ans yes, it's a lot better. Here the new version:
comp: func [n [int!] a [block!] b [block!] /local ref][ print reform bind [product version platform build] rebol recycle/off ref: perf n [] a: to-decimal probe abs (perf n probe a) - ref b: to-decimal probe abs (perf n probe b) - ref recycle/on to-percent (to-integer b - a / a * 100) / 100 ]
Steeve
Again I fucked up ref calculation. Lot more stable now
perf: func [i [integer!] b [block!] /local t n] [ n: 0 t: stats/timer bind b 'n ; to use vars i,n in b loop i [do b ++ n] stats/timer - t ] comp: func [n [int!] a [block!] b [block!] /local adjust][ print reform bind [product version platform build] rebol recycle/off adjust: n / to-decimal perf n [] a: adjust * to-decimal probe perf n probe a b: adjust * to-decimal probe perf n probe b recycle/on to-percent (to-integer b - a / a * 100) / 100 ]
make it run for at least a couple seconds each if you want a stable result.
DideC
Gregg: it seems your machine has several process that take CPU in the background. Hence the funny results. Has Gab say: make a longer loop (1M) to reduce this effect... or kill process ;-) Could be funny to 'comp the exact same code and has so different results.
Pekr
Maybe Gregg's machine is reporting to NSA, FBI, CIA and other agencies in the background? :-)
Gabriele
the code i used on R2 was:
time*: func [n block /local start] [ start: now/precise loop n block difference now/precise start ] time: func [block /local count time result] [ time: 0:00 count: 1 while [time < 0:00:01] [ time: time* count block result: divide to decimal! time count ; multiply by two for faster convergence ; (ie. aim for 2 seconds) count: 0:00:01 * count * 2 / time ] result ]
>> time [1 + 1] == 7.25799625998013E-8 >> f: does [1 + 1] >> time [f] == 1.39604952270899E-7
Drake
How do I save the contents of dir-list to a file from the console ?