Performance Factors in C++
in [C++]
|
From: Mathias Gaunard on 4 Sep 2009 08:31 On 4 sep, 15:38, James Kuyper <jameskuy...(a)verizon.net> wrote: > I'm only questioning the claim that "it is hard (NP-hard even)" to > perform such a check; I'm not arguing that it's a good thing to do. I said it is hard to do alias analysis, which is a static analysis done at compile-time. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kuyper on 4 Sep 2009 22:40 Jens Schmidt wrote: > James Kuyper schrieb: > >> I'm only questioning the claim that "it is hard (NP-hard even)" to >> perform such a check; I'm not arguing that it's a good thing to do. > > I came to the understanding that you are talking about different things. > > The NP-hard claim was done for a compile-time check, where the check > is not even computable in all cases (halting problem equivalent). The original claim that this could not be done was by Mathias Gaunard in the message with a Date: header of Sun, 30 Aug 2009 08:44:59 CST. While he mentioned the lack of static knowledge of the alignment and size, to me this came across as a non-sequitur, because his claim was not specifically restricted to a compile-time decision; he simply said flatly that it couldn't be done at all. To me, it seemed he was ruling out making the decision at runtime, as well as at compile time. > For a run-time check this is trivial. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kuyper on 4 Sep 2009 22:42 Mathias Gaunard wrote: > On 4 sep, 15:38, James Kuyper <jameskuy...(a)verizon.net> wrote: > >> I'm only questioning the claim that "it is hard (NP-hard even)" to >> perform such a check; I'm not arguing that it's a good thing to do. > > I said it is hard to do alias analysis, which is a static analysis > done at compile-time. Yes, but my real point was that it's not obvious why you thought that alias-checking at compile time was necessary, when pointer comparisons at runtime were clearly sufficient for the job. You made a flat claim that it was not possible for std::copy<> to decide whether to use memcpy() or memmove() - you did not restrict that assertion to decisions made at compile time. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Brian Neal on 4 Sep 2009 22:50 On Sep 3, 7:10 pm, Brian Neal <bgn...(a)gmail.com> wrote: > On Aug 30, 9:44 am, Mathias Gaunard <loufo...(a)gmail.com> wrote: > > > On 30 ao�t, 01:24, Thomas Maeder <mae...(a)glue.ch> wrote: > > > > 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. > > I've seen a std::copy() turn into a memcpy() call on gcc. And this was > way back on gcc 2.95. It used template magic to determine it was being > passed pointers to built in types. I don't recall if it did any > overlap checking, but it might have. > I just checked out the implementation in gcc 4.2.4. There are memmove () calls all over the place. That's a very nice optimization. There is a comment in there now (bits/stl_algobase.h) about how they can't use memcpy because of overlap issues. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrew on 5 Sep 2009 17:29
On 28 Aug, 18: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? 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 really depends on what the program is doing. I worked on some C++ price feeds once where my initial implementation copied the fields into string variables before doing various things, such as atoi conversions etc. This was very expensive. A quick gprof analysis showed the time was being spent in string copying. This is because we had a dozen or fields per message and thousands of ticks a second. A bright chap on the team wrote a library with a class he called a string descriptor. This basically held the char* pointer and the length. It also provided string compare routines that did a compare in place. Numeric conversion routines were also provided. This was very efficient. Perhaps you need something like this. Regards, Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |