Donal K. Fellows <
donal.k...@manchester.ac.uk> wrote:
> On 25/06/2012 12:58, Andreas Leitgeb wrote:
>> Donal K. Fellows <
donal.k...@manchester.ac.uk> wrote:
>>> On 25/06/2012 10:59, Donal K. Fellows wrote:
>>>> On 22/06/2012 19:28, Prof Craver wrote:
>>>>> Of course, if we want performance the best bet is
>>> proc fib n { expr {round(((0.5*(1+5**0.5))**($n+1))/5**0.5)} }
>> Doing it with floating point means, that results are correct
>> only till about 70, so for this limited range, hardcoding
>> the values into an array fib and accessing $fib($n) might
>> be still a notch faster.
> [fib 70] is indeed the first wrong value, and a precalculation strategy
> is indeed very quick (though a list is faster than an array).
Array access is less verbose than lindex, though ;-)
> My main interest though was in how the different ways of writing
> the above piece of mathemagics would result in changes to the
> bytecode sequence.
The improvement by bracing was to be expected, but I admit, Ι didn't
expect the effect of inlining the constant's formula.
Makes me brainstorm about tcl::mathconst ;-) Those "consts" would,
if changed, increment the generation-counter and cause recompilation
of all, but allow inlining their value into compiled expressions.
> It also turns out to be faster these days to use [global] to bind a
> global variable to a local variable instead of using a fully-qualified
> variable name, even for a single access. What's more, [variable] is even
> faster again.
I typically "declare" (really link in) a couple of global variables in
one global statement, and that isn't equally possible with variable,
unless I also want to initialize each but maybe the last one.
> This is somewhat unexpected, and likely to change how I
> write code in the future. (Checked in 8.5 and 8.6 with both optimized
> and debugging builds, and consistently true.)
What prevents global from being optimized similarly?