Re: g++ and library optimisations

[Paul Pluzhnikov]

"pemo" <usenetmeister@gmail.com> writes:

> 1. Is there a recommended [tried/tested] version of the STL Vector class 
> that's likely to be faster than the one she's using [I've no idea as to 
> where her existing one came from, but, knowing her department, it would have 
> simply come bundled with something else - g++ perhaps]?

There are only two choices I know of -- use the STL that came with
g++, or use STLport. I do not believe STLport has any speed advantage
over the "bundled" implementation.

Besides, if it's the vector code that she thinks is slow, then she
should look at he algorithms. For example:

  std::vector<int> v;
#if 0
  // commenting this in will remove
  // about 10 calls to realloc and memcpy in most std::vector implementations.
  v.resize(1024); 
#endif
  for (int i = 0; i < 1024; ++i) { v.push_back(i); }


> 2. How difficult would it be to recompile parts of the library code she uses 
> [if she can find the sources], e.g., is the STL Vector class easy enough to 
> recompile into a .o etc?

You appear to believe there is some "library code that implements vector".
There is no such thing -- most STL is templates, and they are
compiled right into your own objects.

> 3. Are there debug versions of the standard and STL libraries?

For STL see answer 2.
It's not clear what you mean by "standard libraries", probably libc.
There are no Linux distributions that compile libc without
optimization (in fact, last time I looked, libc couldn't be compiled
without optimization at all).

> And, how can 
> one tell if a library is a debug version or not [just want to check she's 
> not linking with these right now!]

That's not quite as easy as it used to be:
- gcc can produce optimized libraries with debug info (so if the
  library has debug info, it doesn't mean it's not optimized).
- conversely, one can produce un-optimized library without debug info.

But none of this probably matters, because of answer 2.

> **and** is there an easy way to find what 
> libraries she's linking with - perhaps through asking the linker [rather 
> than following paths]?

Sure: just add '-Wl,-verbose' and it will spit lines like this:

attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc.so failed
attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc.a succeeded
attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc_s.so succeeded
-lgcc_s (/usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libgcc_s.so)
attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libc.so failed
attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/libc.a failed
attempt to open /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../libc.so 
succeeded
opened script file /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../libc.so
opened script file /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/../../../libc.so
attempt to open /lib/libc.so.6 succeeded

> 4. What are a decent set of basic compiler optimisation switches to use - 
> for speed [think she's using -O3 at the moment]?

That should be good enough. However note that gcc-4.x (4.1.2 is
current) may be able to do a *much* better job than gcc-3.x.

> 5. How can I help her profile her code [and make sense of the results]

Compile with '-pg', run the exe (on a smaller test case), then use
'gprof' to analyze the results.

Note that there are some significant deficiencies in 'gprof'.
Some other choices are listed here:

  http://bitwagon.com/tsprof/tsprof.html#Features

She might also have 'sysprof' installed, which has pretty nice and
intuitive GUI, though interpreting results is sometimes tricky.

Note that correct profiling is a bit of "black art", best performed
by someone who can examine and understand what the compiler did
(and why) at the assembly level, and understands what inlining,
loop unrolling, etc. mean.

Lastly, if she is on Linux/x86 or Linux/x86_64, she might get some
significant speedup with Intel 'icc' (or not).

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.