Hi, it's been a while since I talked here (2 years ?)
Do you know if there is a better way to code this function ?
extend-mask: func[i][ ; set bits at the right of the MSB ; used to control if joining ADD operations together ; is allowed by their prefixed casting operation (and MASK). ; e.g. 00100100 => 00111111 ; Sorry if it's ugly since REBOL does not have a native for that. ; Well, the utility is rare, except when you write a code optimizer. int(2 ** (int (log-2 i) + 1) - 1) ]
(int) is a shortcut fot to-integer
Steeve
I don't want to use a precompiled array as a solution, the speed is not a problem... (currently)
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 :
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%