AltME: Rebol School

Messages

Gregg
No quick suggestions here, but it's nice to see you again.
Geomol
Some ideas, but yours seem to be faster:
extend-mask: func [
    i
][
    i or either i > 0 [extend shift i 1] [0]
]
extend-mask: func [
    i
    /local r
][
    r: i
    while [0 < i: shift i 1] [r: r or i]
    r
]
hm, *extend* should be extend-mask in first one.
so a recursive

Gabriele
If speed is not a problem, then your version is probably the best choice.
If speed becomes a problem and you want to avoid floating point, there is a faster version of what Geomol proposed:
func [i] [
    i: i or shift i 1
    i: i or shift i 2
    i: i or shift i 4
    i: i or shift i 8
    i or shift i 16
]
You need an extra line if you are using R3 and 64 bits integers.
Geomol
That's neat, Gabriele!
It seems, Steeve only need the function to work on 8 bits at a time, so this is faster!
extend-mask: func [i] [i: i or shift i 1 i: i or shift i 2 i: i or shift i 4]
DideC
With Steeve func optimized, it's as fast as Gabriele's one on 8 bits :
extend-mask: func [i] [to integer! 2 ** (1 + to integer! log-2 i) - 1]

Gabriele
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%
>> 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.038712
[f]
0:00:00.07201
== 86%
>> 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.005999
[f]
0:00:00.120692
== 1911%
Gregg
>> comp 10000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.545457
[f]
0:00:01.114441
== 104%
>> comp 10000000 [1 + 1][f]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[1 + 1]
0:00:00.825999
[f]
0:00:01.327313
== 60%
Steeve
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
]
And my result  for calling a function:
>> comp 100000 [to integer! 8.0][to-integer 8.0]
core 2.100.111.3.1 Windows win32-x86 20-Feb-2011/16:24:43
[to integer! 8.0]
0:00:00.025229
[to-integer 8.0]
0:00:00.038491
== 52% (overhead)
Gregg
COMP n arg needs to be integer!, not int!.
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.046459
[to-integer 8.0]
0:00:00.028882
== -37%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.021502
[to-integer 8.0]
0:00:00.029488
== 37%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.024317
[to-integer 8.0]
0:00:00.028619
== 17%
>> comp 100000 [to integer! 8.0][to-integer 8.0]
atronix-view 3.0.91.3.3 Windows win32-x64 2-Dec-2014/18:03:44
[to integer! 8.0]
0:00:00.04053
[to-integer 8.0]
0:00:00.038208
== -5%

Gabriele
make it run for at least a couple seconds each if you want a stable result.

Last message posted 184 weeks ago.