compiling without the -g flag

Help
2007-02-06
2013-04-22
  • Hello,

    I installed brlcad from source on my old Linux box using

         ./configure --enable-optimized

    and everything went swell except I only pulled a benchmark of 131 and benchmark says the example machine nearest mine pulls 250.  Then I noticed the compiler flags had been set to both -g and O3.  So I tried several times to get rid of the -g, ending with

         ./configure --disable-automatic-flags --enable-optimized --disable-runtime-debug --disable-debug

    which did the trick but now benchmark seems broken; it wants to run forever.

    So my questions is generally what to do.  Does brl-cad need debugging symbols to run correctly?  Are my compile options conflicting with each other? Etc.

    Thanks!

     
    • Same anon here. It looks like the problem was the "--disable-automatic-flags" option. 

         ./configure --enable-optimized --disable-runtime-debug --disable-debug

      still got rid of the -g and allowed the benchmark to run. On my machine, however, losing the -g debug option didn't help much by itself. The real improvement came from "--disable-runtime-debug" --- about 40% faster.

      I also noticed I got consistently better benchmarks when I ran the benchmark program in the installation directory rather than the one installed in /usr/brlcad. Odd.

      brlcad brl-cad installation install

       
      • Sean Morrison
        Sean Morrison
        2007-02-09

        Thanks for narrowing down the problem to the automatic-flags option.  That should make it easier to track down the cause of the problem but almost undoubtedly -fno-strict-aliasing.  The flag should just probably be more verbose about how dangerous it is to use given it turns off *everything* flag-wise including stuff you might otherwise take for granted, i.e. it's for expert/dev use only generally speaking.

        Getting a nice performance boost when disabling run-time debug is expected (and even recommended for stable use situations where the model has already been created and you're just ray-tracing).  If there's any chance of hitting a bug, though, run-time debug is useful to limit memory, data, or geometry corruption.

        As for running faster from the compilation directory, there's a reason for that.  Libtool modifies the library search path and/or relinks the binary if necessary so that the binary will run "in-place" in a reliable cross-platform manner.  This can result in a tuned binary that easily finds the symbols it needs.  Once installed, the binary no longer has that advantage and relies on usual system linkage and library lookup behavior.  That said, you should be able to obtain that same level of performance if you are so inclined, and at the expense of disk space, by compiling static binaries only (i.e. --disable-shared configure option).  That will usually be even faster all-around but will result in massive binaries.

        Cheers!
        Sean

         
    • Sean Morrison
      Sean Morrison
      2007-02-09

      Several of your comments are rather interesting.  You do seem to have run into some bug, but it's hard to say without more information what exactly was the cause of the problem.

      BRL-CAD doesn't need debugging symbols to run correctly and to get rid of the -g flag, the --disable-debug option is what did the trick.  General use would have been to run: ./configure --enable-optimized --disable-debug

      It would be interesting to know if that still wants to run forever with just those two flags, indicating some problem with the automatic-flags or runtime-debug configure options.  They "should" all work together, and I suspect the problem is more related to the speed of the machine you're running on, but there are many variables in play.  Either way, not terminating is a bug .. and it would be good to figure out where it's "stuck".  Is it in a loop ray-tracing, is it generating infinite frames, does it make no frames?  What does one of the .log files say (e.g. moss.log) or the output of benchmark for that matter?

      At that low of a benchmark, there's rather big differences in the hardware you could find at the time where benchmarks were in the 50-500 range.  Mostly identical hardware shipped from a different vendor might make the entire difference between performance differences, especially if the hardware architecture was different, depending on the compiler user and cache sizes and kernel being used, etc.

      Cheers!
      Sean