change mixins

[retard]

Tue, 16 Feb 2010 21:56:46 +0100, grauzone wrote:

> retard wrote:
>> Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:
>> 
>>> retard wrote:
>>>>> Granted, even if logging is disabled, the compiler will push the
>>>>> arguments on the stack and call logInfo().
>>>> This is a case where a JIT compiler wins. The code runs equally fast
>>>> without the call at all and with logging turned off (dynamically). In
>>>> languages like D, the like has to be statically turned off unless
>>>> compilers have any new dynamic optimizations.
>>> Can the JIT really do this optimization? It sounds as if it'd detect
>>> that the variable never changes, and generate code with that fixed
>>> value.
>> 
>> It sure can recompile the code assuming that the logging policy doesn't
>> change that often - in case it does change often switching the code
>> might have larger overhead than testing the condition. In real life you
>> would probably start the program with either logging on or off. With
>> JIT compiled languages, the decision can be postponed to runtime, in D
>> it
> 
> We're talking about a globally accessible runtime variable here, right?
> Not just a local variable that was detected to be constant. What I don't
> understand is: how does the VM efficiently detect, that the value never
> changes, and that generating code for that fixed value may be
> worthwhile?
> 
> It is well possible in theory: the VM could just set up write barriers
> to detect changes to a variable, and then recompile speed critical code
> that uses the variable.
> 
> But it had to collect statistics about all accessed variables, and then
> decide to recompile the code. Both collecting and analyzing statistics
> and recompiling code takes time, and it has to be fast enough to not
> slow down the program even if there are "misses" (e.g. unexpected
> variable writes).
> 
> Other typical JIT optimizations sound easy compared to this case. I'd be
> really interested how this works out.

I need to study this further. A quick test just showed that the logging 
code didn't affect performance in any notable way when I logged things in 
a tight inner loop.