Prev: ON_BLOCK_EXIT and e.g. C4189
Next: operator== for aggregate types / member wise comparison
From: Mathias Gaunard on 29 Aug 2009 23:44
On 30 ao�t, 01:24, Thomas Maeder <mae...(a)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! ]

From: Joe Smith on 29 Aug 2009 23:45

Carlo Milanesi <carlo.nospam.milanesi(a)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! ]

From: Thomas Maeder on 30 Aug 2009 09:55
Mathias Gaunard <loufoque(a)gmail.com> writes:

> On 30 ao�t, 01:24, Thomas Maeder <mae...(a)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! ]

From: Jens Schmidt on 30 Aug 2009 09:54
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! ]

From: bf on 31 Aug 2009 11:10
On Aug 29, 1:37 am, Mathias Gaunard <loufo...(a)gmail.com> wrote:
> On 28 ao�t, 19:52, Sada <steggi...(a)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! ]

 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: ON_BLOCK_EXIT and e.g. C4189
Next: operator== for aggregate types / member wise comparison