 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> I think MSVC actually *does* output warnings... It's just that every
> time you compile the sources, it generates many hundred lines of
> "stuff", and any warning messages are swamped by all the other output. I
> think I've seen a warning or two flash past, but it would be quite
> time-consuming to actually go read them all.
In principle you should get 0 warnings for a properly-written program.
> (And most warnings are just
> "printf is deprecated; please use printf_s instead".)
That particular warning can be turned off in VC. A google search should
tell you how.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
From what I can tell, C was developed at a time when you actually ran
CPP by feeding in your source files and header files on several tapes,
and having CPP output the final, combined output onto another tape. You
then unload CPP, load CC, and then it reads the tape in and spews out
the machine code as it reads. (Which is why you need forward
declarations and stuff; the source code is literally too large to hold
in memory all at once.)
When 16K was a huge amount of RAM, these kinds of gyrations were
necessary. On my dev box, with 4GB of RAM, it seems kinda silly...
(Having said that, if you have a microcontroller with 2K of RAM and 4K
of ROM, then C is about the only language that can target it.)
> (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.)
Curiously, the Haskell compiler does heaps and heaps of really
high-level optimisations like removing redundant computations, inlining
functions, transforming nested conditional tests and so on. But it
utterly fails to perform trivial low-level optimisations like replacing
arithmetic with bitshifts. Partly because that stuff obviously varies
somewhat per-platform - and partly because it's not very "exciting".
Design a radical new optimisation pass and you can publish a paper on
it. Implement mundane stuff that other compilers have done for years and
nobody will care.
(This is in part why there's now an LLVM backend. Hopefully LLVM will do
this kind of stuff for you...)
>> 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's not so much the jump, it's the not being able to start prefetching
the instructions at the other end until after the target address has
been computed, leading to a pipeline bubble.
That said, if you're running JIT-compiled code with garbage collection
and whatnot, the overhead of a few extra jumps is probably moot. (E.g.,
if your code is Java or C# or Python or something.)
>> Part of the problem is probably also that I don't completely understand
>> how variable initialisation works in C++.
>
> Basic types do not get implicitly initialized (except in some
> circumstances), user-defined types do.
Yeah, for some reason I had it in my head that it's whether the variable
is a class member or just a local variable. What you said makes more sense.
> A raw pointer is a basic type and thus will likewise not be implicitly
> initialized.
So it points to random memory?
> std::shared_ptr is a class and will always be initialized
That is what I thought.
> (to null.)
That's the bit I failed to anticipate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> A raw pointer is a basic type and thus will likewise not be implicitly
>> initialized.
>
> So it points to random memory?
>
Yes. C++ still allows you to shout yourself in the foot.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 30/05/2013 10:46 PM, Francois Labreque wrote:
>>> A raw pointer is a basic type and thus will likewise not be implicitly
>>> initialized.
>>
>> So it points to random memory?
>
> Yes. C++ still allows you to shout yourself in the foot.
Oh, I wasn't disputing that. Just checking.
Today I discovered that some of the code I copy-pasted actually had some
memory allocation in it, and I hadn't explicitly deallocated it again.
To be clear... I only need to do explicit deallocation if I've done
explicit allocation in the first place, right?
unsigned char foo[512];
vs
unsigned char * foo = new[512];
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> To be clear... I only need to do explicit deallocation if I've done
> explicit allocation in the first place, right?
Every 'new' must have a correspondent 'delete'. If you don't write 'new'
then you don't have to worry about any deletes either.
Of course the exception to this is if you are using a smart pointer like
std::shared_ptr or std::unique_ptr, in which case you do write 'new',
but let the smart pointer do the 'delete' for you.
If you really need to explicitly allocate memory, then it's usually a
good idea to use such a smart pointer, because they will make sure that
they will delete the object when the last smart pointer to it dies, and
delete it only once.
The thing is, even if you have written one 'new' and one 'delete' in your
code, the object might be being deleted more than once. This is because of
the wonderful thing in C++ that is copying and assigning of classes.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/05/2013 09:41 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> To be clear... I only need to do explicit deallocation if I've done
>> explicit allocation in the first place, right?
>
> Every 'new' must have a correspondent 'delete'. If you don't write 'new'
> then you don't have to worry about any deletes either.
>
> Of course the exception to this is if you are using a smart pointer like
> std::shared_ptr or std::unique_ptr, in which case you do write 'new',
> but let the smart pointer do the 'delete' for you.
>
> If you really need to explicitly allocate memory, then it's usually a
> good idea to use such a smart pointer, because they will make sure that
> they will delete the object when the last smart pointer to it dies, and
> delete it only once.
>
> The thing is, even if you have written one 'new' and one 'delete' in your
> code, the object might be being deleted more than once. This is because of
> the wonderful thing in C++ that is copying and assigning of classes.
Without revealing too many details about the product I'm working on, it
deals with byte-level processing of binary protocol data. So there's A
LOT of char* variables floating around the place. In short, it's just
the sort of code where a tiny bug will make the program output gibberish
or crash spectacularly. It makes me feel twitchy inside...
The other fun thing is that sometimes one function calls another
function, and the other function returns a char*. So "you" didn't
allocate anything, but the function you called did, and you need to
remember to deallocate it. (Arguably that's poor design, but hey, I
didn't write the code...)
PS. What black magic is it that makes delete[] work correctly?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> Without revealing too many details about the product I'm working on, it
> deals with byte-level processing of binary protocol data. So there's A
> LOT of char* variables floating around the place. In short, it's just
> the sort of code where a tiny bug will make the program output gibberish
> or crash spectacularly. It makes me feel twitchy inside...
If a program needs to use lots of raw pointers to dynamically allocated
memory, it requires quite a lot of experience and following certain design
principles in order for the code to be safe. (There are situations where
smart pointers just can't be used. For example a smart pointer won't help
you a bit if you need a pointer that points to some element of a
dynamically allocated array.)
I freely admit this is just an evil that one has to live with if one is
programming with a language of the C family. However, having to actually
write that kind of code is a lot less frequent than one might think,
especially if you are writing the entire program and you get to design it
properly from the very start.
In most cases one should avoid allocating arrays directly with 'new',
and use std::vector instead. Then, if possible, one should avoid having
raw pointers pointing to the elements of the vector, except in very simple
situations (where it's trivial to see that no such pointer will get
invalidated or be used after the vector has been destroyed.) Prefer
indexing the vector object directly, if possible. (Or use vector iterators.
Many compilers can add checks to them in debug mode, which can help quite
a lot.)
Sure, there are situations where std::vector won't cut it, or where such
pointers just have to be used, but these situations are not all that
common in practice.
> The other fun thing is that sometimes one function calls another
> function, and the other function returns a char*. So "you" didn't
> allocate anything, but the function you called did, and you need to
> remember to deallocate it. (Arguably that's poor design, but hey, I
> didn't write the code...)
That's extremely poor design, and is one of the big no-no's in C++
programming. It's asking for trouble.
> PS. What black magic is it that makes delete[] work correctly?
It depends on the compiler and the runtime library, but most probably
there's metadata at the beginning of an allocated block of memory that
says how many elements there are in said block. 'delete[]' probably just
blindly takes that value (which is probably located at the pointer's
position minus some fixed offset) and assumes there are that many elements
in the array. (Obviously it will break horribly if you try to delete[]
a pointer that's not pointing to the first element of a dynamically
allocated array.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/24/2013 12:00 PM, Warp wrote:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> This would be acceptable if VC offered some how to find out WHAT
>> TEMPLATE it was attempting to expand when the error occurred. But no, it
>> just shows you the source code for the STL (or Boost or whatever) and
>> points at the line on which the problem was actually detected. There
>> seems to be no way that I can discover what line of which file resulting
>> in this template being invoked in the first place - and THAT is surely
>> where the problem is, not in STL itself.
>
> All compilers I know if will give you the full chain of calls that
> ended up in the erroneous line. (And usually looking at the first error
> message that refers to your code will immediately reveal the problem.)
>
> I would be quite surprised if VC didn't do this.
The version of VS C++ I use at work does not give a reference chain for
any error. In a number of cases I am unable to discern what caused the
cited file to be invoked.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
