Orchid Win7 v1 <voi### [at] devnull> wrote:
> 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.

C was also developed in a time where compilers did almost zero
optimization. Most C programs were "hand-optimized" for something
like 20 years, before compiler technology caught up, making such
manual optimization almost completely moot.

(Just as a concrete example, "i * 2" would for a quite long time produce
an actual multiplication opcode, which was extremely slow especially back
in those days, which is why it was usually written as "i << 1" by C hackers,
which produces a bit shift opcode that's much faster. Nowadays compilers
will detect both situations and use whatever is faster in the target
architecture, making the whole manual optimization completely moot.)

> 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?)

Calling a virtual function in C++ is no slower in practice than calling
a regular function. That additional indirection level is a minuscule
overhead compared to everything else that's happening with a function call.

It might make some difference in rare cases with very small functions
that are called in a really tight inner loop that runs for millions of
iterations, especially if said function can be inlined by the compiler.
However, it's rare to need dynamic dispatch in such situations anyway.

> 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...)

Basic types do not get implicitly initialized (except in some
circumstances), user-defined types do. In other words, if you have
an int and a std::string as a member of a class, the int won't be
implicitly initialized and you have to explicitly initialize it in
the constructor. The std::string will, because it's a class, and thus
doesn't need to be explicitly initialized.

A raw pointer is a basic type and thus will likewise not be implicitly
initialized. std::shared_ptr is a class and will always be initialized
(to null.)

-- 
                                                          - Warp

Post a reply to this message