Performance Factors in C++

hi how can I improve the performance of a C++ program?

In my program I am using strcmp() strcpy() functions heavily , are
they costly? if so how can i avoid them??
Is memcpy() is better than strcpy()?

Please suggest me the factors that affect the performance of a C++
program.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 28 août, 19:52, Sada <steggi...@gmail.com> wrote:
> hi how can I improve the performance of a C++ program?
>
> In my program I am using strcmp() strcpy() functions heavily , are
> they costly?

Not that much. Profile your code and see whether this is really the
limiting factor.


> Is memcpy() is better than strcpy()?

Yes, memcpy is faster, since it knows the size beforehand.
Better yet, there are functions even faster than memcpy to copy memory
that is aligned on a specific boundary and where
the number of bytes to copy is a multiple of a given number. You can
deploy word-by-word copying and even use SIMD.


> Please suggest me the factors that affect the performance of a C++
> program.

A broad question, but here is an attempt at an answer anyway, by rough
order of importance:

- Algorithmic complexity.
- Concurrency synchronization.
- Inlining and other optimizations.
- Vectorization.
- Cache effects.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 8ÔÂ29ÈÕ, ÉÏÎç1ʱ52·Ö, Sada <steggi...@gmail.com> wrote:
> hi how can I improve the performance of a C++ program?
>
> In my program I am using strcmp() strcpy() functions heavily , are
> they costly? if so how can i avoid them??
> Is memcpy() is better than strcpy()?
>
> Please suggest me the factors that affect the performance of a C++
> program.
>
It's very rare that strcpy/strcmp is the bottleneck of a program
unless you do them for nothing. I suggest do a profiling and find the
really performane hot points and then try to remove them. Remember use
release build instead of debug build for profile.

{ edits: quoted banner removed. don't quote extraneous material. tia., -mod }


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard <loufoque@gmail.com> writes:
>
>> Is memcpy() is better than strcpy()?
>
> Yes, memcpy is faster, since it knows the size beforehand.
> Better yet, there are functions even faster than memcpy to copy
> memory that is aligned on a specific boundary and where the number
> of bytes to copy is a multiple of a given number. You can deploy
> word-by-word copying and even use SIMD.

IMHO, this kind of optimization is best left to the Standard Library
implementation.

Just use std::copy and let the library implementation sort out which
optimizations apply.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sada wrote:
> hi how can I improve the performance of a C++ program?

Read this wikibook: http://en.wikibooks.org/wiki/Optimizing_C%2B%2B

> In my program I am using strcmp() strcpy() functions heavily , are
> they costly?

No. Their cost is essentially that of loading the data from where it is
(disk swap area or RAM or CPU cache) to the CPU.
To optimize them, minimize the data size.

> Is memcpy() is better than strcpy()?

No.

> Please suggest me the factors that affect the performance of a C++
> program.

Of course the biggest factors are the algorithms used.
But the most typical inefficiencies specific of C++ programming are
excessive dynamic allocation/deallocation and pass-by-value of
non-elementary objects.

--

Carlo Milanesi
http://digilander.libero.it/carlmila

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 30 août, 01:24, Thomas Maeder <mae...@glue.ch> wrote:

> IMHO, this kind of optimization is best left to the Standard Library
> implementation.
>
> Just use std::copy and let the library implementation sort out which
> optimizations apply.

std::copy can't even call memcpy since the arguments are not
guaranteed not to overlap, at best it can call memmove.
It doesn't statically know the alignment and size of memory either, so
even if it the arguments were guaranteed not to overlap, it couldn't
do better than memcpy anyway.

If you really want fast copying, you'll have to use a function that
makes use of information std::copy doesn't have, and that is
especially optimized for your data set.

Of course, I seriously doubt this is the limiting factor in the OP's
code.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Carlo Milanesi <carlo.nospam.milanesi@libero.it> wrote:
> Sada wrote:
> [snip]
>> Is memcpy() is better than strcpy()?
>
> No.

Memcpy() might be better than strcopy, iff you happen to already have the
size of the null terminated character array you wish to copy. If you need to

determine that by calling strlen() first, then you would be better off just
calling strcopy().



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 30, 1:25 am, Carlo Milanesi <carlo.nospam.milan...@libero.it>
wrote:
> Sada wrote:
[..]
> > Is memcpy() is better than strcpy()?
>
> No.

This was my first thought, too, but I remember reading an article by
AMD back in 2002 that implementation details ain't that simple even on
a "simple" problem like this.
strcpy() must do it's job sequentially front-to-end since it does not
have any idea how much data to copy. A simplified implementation would
be

void strcpy( char* source, char* target ) {
while ( *target++ = *source++ );
}

Some CPUs even have specialized operations to perform this loop in a
single command.

Even so, with memcpy() the order and chunk size in which the data is
copied is much more free. A greater chunk size, i.e. using 64-bit
transfers instead of byte transfers, or use multi-byte MMX CPU
operations, greatly improves performance. What really surprised me,
reordering the data transfers to a non-intuitive sequence (AFAIR,
working cache buckets in-order, each bucket's data reverse order) is
an even greater optimization. This scheme makes sure data is always
read from the CPU's first level cache and burst-filling the cache
happens in the background while the current bucket is processed.
If I remember properly, an AMD Athlon did the most optimized memcpy()
presented in the article about seven times faster than the simplistic
approach as in the strcpy() above.
strcpy() is much more resistent to such optimizations.
Multi-core CPUs, like the Core i7, or SIMD machines should add another
level of speedup. (E.g. on a 256KB transfer let 256 cores of a massive
parallel machine transfer 1KB each.)

Conclusion, both strcpy() and memcpy() are O(n) for data size n but
the extra information memcpy() receives gives it the edge. A strlen()
followed by a memcpy() instead of a single strcpy() is no alternative,
though... :-)

best,

MiB.



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 28 Aug, 19:52, Sada <steggi...@gmail.com> wrote:

> Please suggest me the factors that affect the performance of a C++
> program.

You might find the book by Bulka and Mayhew useful:

http://www.amazon.com/Efficient-C-Pe...niques/dp/0201
379503/ref=sr_1_1?ie=UTF8&s=books&qid=1251623915&sr=8-1

Rune

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sada wrote:

> hi how can I improve the performance of a C++ program?

First, measure the time the program spends for each part.
Then concentrate on the parts taking too much time.

> In my program I am using strcmp() strcpy() functions heavily , are
> they costly?

A definite "maybe". This entirely depends on the size of the copied
areas and what else your program does.

> if so how can i avoid them??

Check if the program can get away with just copying references to
the data instead of the data itself. References have a small constant
size and so are much faster.

> Is memcpy() is better than strcpy()?

It is different. As others already wrote, memcpy is probably faster
in copying per byte, but strcpy often has to copy less.
--
Greetings,
Jens Schmidt



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard <loufoque@gmail.com> writes:

> On 30 août, 01:24, Thomas Maeder <mae...@glue.ch> wrote:
>
>> IMHO, this kind of optimization is best left to the Standard Library
>> implementation.
>>
>> Just use std::copy and let the library implementation sort out which
>> optimizations apply.
>
> std::copy can't even call memcpy since the arguments are not
> guaranteed not to overlap, at best it can call memmove.

Provided the iterators are pointers (or close relatives to pointers),
which is the prerequisite for considiering the usage of memmove() or
memcpy(), std::copy can certainly determine whether the areas overlap.

And if the iterators are pointers, it's also very easy to find out
whether the memory areas overlap.


> It doesn't statically know the alignment and size of memory either,

It *does* know the alignment at compile time.

And normally, it knows the size at compile time if the programmer
attempting to manually optimize knows it.


> so even if it the arguments were guaranteed not to overlap, it
> couldn't do better than memcpy anyway.

So if I copy an array of doubles, and the platform provides a very
fast copier for memory chunks the size of doubles, I don't see why
std::copy() couldn't use it.


> If you really want fast copying, you'll have to use a function that
> makes use of information std::copy doesn't have, and that is
> especially optimized for your data set.

What information would that be?


> Of course, I seriously doubt this is the limiting factor in the OP's
> code.

Agreed.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 31 août, 02:55, Thomas Maeder <mae...@glue.ch> wrote:

> Provided the iterators are pointers (or close relatives to pointers),
> which is the prerequisite for considiering the usage of memmove() or
> memcpy(), std::copy can certainly determine whether the areas overlap.

No, it can't.
The compiler could do it, by doing alias analysis, which is a hard (NP-
hard even) problem -- which is why you can't rely on the compiler
doing it -- but a function certainly cannot.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 29, 1:37 am, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 28 août, 19:52, Sada <steggi...@gmail.com> wrote:
>
> > hi how can I improve the performance of a C++ program?
>
> > In my program I am using strcmp() strcpy() functions heavily , are
> > they costly?
>
> Not that much. Profile your code and see whether this is really the
> limiting factor.

True, but caution, though. If the profiler shows strcmp() and strcpy()
to be the performance bottlenecks, is it their implementation or their
use?


Here's an exerpt from real-world code that the original author thought
suffered from string and heap operations being inefficient:

#include <iostream>
#include <ostream>
#include <istream>
#include <fstream>
#include <cstring>

int main(int argc, char *argv[])
{
std::ifstream in(argv[1]);
if (!in)
{
std::cerr << "Can't open " << argv[1] << std::endl;
return 1;
}
char *result = new char[std::strlen("")+1];
std::strcpy(result, "");
for (;
{
char *tmp = new char[std::strlen("")+1];
in.read(&tmp[0], 1);
if (!in) {
delete[] tmp;
break;
}
tmp[1] = '\0';
char *tmpresult = new char[std::strlen(result) + std::strlen
(tmp) + 1];
std::strcpy(tmpresult, result);
std::strcat(tmpresult, tmp);
delete[] result;
delete[] tmp;
result = tmpresult;
}
std::cout << result << std::endl;
delete[] result;
return 0;
}

As any reasonably seasoned programmer recognises, the real problem is
the amazingly poor algorithm, made worse by the lack of understanding
of how C-strings work.

> > Please suggest me the factors that affect the performance of a C++
> > program.

> A broad question, but here is an attempt at an answer anyway, by rough
> order of importance:

> - Algorithmic complexity.
> - Concurrency synchronization.
> - Inlining and other optimizations.
> - Vectorization.
> - Cache effects.

I think that if the algorithms and are sound, cache effects probably
comes in second or third. Cache-aware data structures can do a lot to
improve performance; in my experience, usually a lot more than
inlining.
_
/Bjorn


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Sada wrote:

> hi how can I improve the performance of a C++ program?
>
> In my program I am using strcmp() strcpy() functions heavily , are
> they costly? if so how can i avoid them??
> Is memcpy() is better than strcpy()?
>
> Please suggest me the factors that affect the performance of a C++
> program.
>
Avoid allocating and deallocating memory, or passing large objects by
value. Both of these will impair performance.

JB

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard wrote:
> On 31 août, 02:55, Thomas Maeder <mae...@glue.ch> wrote:
>
>> Provided the iterators are pointers (or close relatives to pointers),
>> which is the prerequisite for considiering the usage of memmove() or
>> memcpy(), std::copy can certainly determine whether the areas overlap.
>
> No, it can't.
> The compiler could do it, by doing alias analysis, which is a hard (NP-
> hard even) problem -- which is why you can't rely on the compiler
> doing it -- but a function certainly cannot.

Could you explain that in more detail? It seems to me that
std::copy<T*>(p,q,n) could certainly make use of std::less<T*> to check
whether [p,p+n) overlaps [q,q+n). What's the barrier to performing such
a comparison?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]