On Thu, 10 Mar 2005 07:33:21 +0100, xs0 <xs0@xs0.com> wrote:
> I'll reply to OT stuff via e-mail later, as it probably is of no interest to anybody but us..

If you like.

>> The reason I didn't address the cache comment is because you  missunderstood what I was trying to say, here is the thread:
>>  [snip quotes]
>>  caching didn't apply to what I was saying.
>
> Yes it did. You're suggesting that there exist two methods (actually, two entire classes)

Yes, two classes.

> , one without the aspect code, the other one with aspect code.

Yes.

> Code also occupies cache. If the compiled original method is 1000 bytes long, and the new method is 1200 bytes, they take 2200 bytes of cache. If you just have one version that checks a flag, it's like 1210 bytes (including the flag). Considering that L1 cache is usually really small (like 16K for code and 16K for data), that can be a significant difference. I'm not saying it's always the case that it's better to check flags than to have two methods, I'm just saying it can be faster in some cases.

Ahh.. I see what you're saying now.

> Not to even mention how much more flexible a flag is than conditionally doing something with two separate classes..

It's more flexible in that it allows a runtime change in behaviour. I think it has a place regardless which method Walter chooses to use (if he chooses to implement AOP).

> If you test this with really simple/short functions (I did test), flag checking is indeed slower, because you'll have everything in cache anyway (although even such a simple thing as "if (flag) a++; else a+=2" is only like 2% slower compared to having two methods that "a++" or "a+=2"), but in "real" code, flag checking may be faster.

So, in short, if code is cached, flags are slower, but, if the code isn't cached, flags may be faster.

> Efficiency (as in speed) in modern systems is really not that simple anymore. I read an article the other day on real-time ray tracing, and the two things that provided the biggest speed gains were using SSE instructions (because they can work on more than one data at a time) and a cache-friendly layout of data structures.
>
> It was faster to unconditionally do 4 calculations than to conditionally do one. It was faster to convert everything to triangles so that only one case exists, than to handle other primitives (even though a single sphere became like 50 triangles). It was faster to just compute some stuff than to have a check if it is even needed and only then compute it (even though the check was far simpler and the total executed instructions count would be lower, the time that took was longer). These cases all go against the conventional wisdom that the fastest code is the one that doesn't get executed (that is still true, of course, just not 100% of time).

So, from this we can conclude that efficiency is not a pro nor con for either method, as it's dependant on the exact situation in which the code is used.

Regan