On 24/05/2013 05:58 PM, Warp wrote:
> Initializing variables takes clock cycles, which is why C hackers don't
> want them being initialized in situations where they are going to be
> assigned to anyway... (As if this matters at all in 99.999% of the cases.)

I was thinking about this the other day. AFAIK, C was designed to run on 
the PDP line of mainframes. Back in those days, the path to maximising 
performance was to minimise the number of opcodes to be executed. That's 
why we had CISC; the more work done per opcode, the fewer opcodes and 
hence the fewer fetch / decode cycles wasted.

Today, it appears to me that the number of opcodes is nearly moot. If 
you do 20 unnecessary arithmetic operations, on today's super-scalar 
architectures with deep pipelining, it'll probably run most of that lot 
in parallel anyway. But if your code causes a CACHE MISS or a BRANCH 
MISPREDICTION... it will cost you HUNDREDS of compute cycles.

In summary, it seems that doing work twice is no longer expensive. 
Accessing memory in the wrong order and doing indirect jumps are the 
expensive things now. (So... I guess that makes dynamic dispatch really 
expensive then?)

> Many compilers will analyze the code and give a warning about variables
> being used uninitialized, but this analysis will always be inevitably
> limited (because, as you may know, proving that eg. a variable is used
> uninitialized is an improvable problem.)

Yeah, I think VC might actually be giving me warnings, but they're 
getting lost in the miles of other output.

Part of the problem is probably also that I don't completely understand 
how variable initialisation works in C++. (E.g., class constructors get 
called whether you want them to or not, so if it has a nullary 
constructor, it should be initialised to something sane...)

> There are some external tools that can be used to analyze the program
> while it runs, and will detect things like this (as well as memory leaks
> and accessing freed memory or out-of-bound accesses.) The only free one
> I know of is valgrind. However, it only works on Linux and Mac OS X. No
> such luck in Windows.

Oh, really? I wasn't aware valgrind didn't work on Windows... (Then 
again, it's not like I've looked into it. I doubt I could even figure 
out how to work such a complex tool.)

Post a reply to this message