Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,974 of 33,346    |
|    Francis Glassborow to Thomas Richter    |
|    Re: Sequence container capacity after ca    |
|    05 Apr 13 10:33:17    |
      From: francis.glassborow@btinternet.com              On 05/04/2013 00:01, Thomas Richter wrote:       > On 27.03.2013 22:54, James K. Lowden wrote:       >       >> Are you saying vector::operator[] takes 30% more time than a bare       >> pointer? Or that your program's *overall* performance is 30% faster       >> if you use C arrays instead of std::vector? Or something else?       >       >> From my personal experience: I once tried to replace raw C++ arrays       > (and pointers to such) with the std::valarray, hoping that the guarantee       > that valarray does not impose aliasing would have some impact on the       > speed of the compiled program. It did not. In fact, std::valarray was       > slower. I don't remember slower by how much, but at least so much that I       > no longer consider using it.       >       > The algorithms I'm using are digital signal processing (actually,       > wavelet filters for image compression), and they better have to be fast.       > All the fancy C++ mechanisms do not help here, their overhead is just       > not acceptable.                     OK that makes perfect sense. This is one of a relatively small number of       areas where optimisation at almost any cost is worthwhile.              I am reminded of an early weather forecasting program that was producing       very good 24 hour forecasts. The problem was that on the then available       hardware it took 48 hours to run. Increase the performance by a factor       of 10 and a purely academic program becomes a viable one. Increase it by       a factor of 100 and it becomes possible to run it multiple times with       slightly different data (as is done these days) to determine the       stability of the forecast (allows forecasters to recognise when the       'butterfly' effect may be important.)              However note that the value of the output needs to be high to justify       the costs of programmer intensive optimisation and the consequential       maintenance costs.              Francis                     --        [ See http://www.gotw.ca/resources/clcm.htm for info about ]        [ comp.lang.c++.moderated. First time posters: Do this! ]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca