how do I change Cmake compiler switches in bricad

Help
2013-12-06
2013-12-08
  • cpumeshman

    cpumeshman - 2013-12-06

    Never seen this type of build with cmake before.

    There are sets of compiler switches that are enabled by default ! and I
    can't take them away through a
    standard textfile, hence I'm unable to make strict architecture build's
    of bricad.

    Most of the implemented dual redundant switches originates from old/pre
    4.6 mingw compilers.

    Please advice how to disable the deafault switches, as some actually can
    cause RT problems witn newer gcc compiler toolchains.

    Advices on gcc later models based on some billon lines of parsed src below.

    and have in mind that speed when it comes to app execution cant be
    compared with car driving.
    Speed is achieved by reducing the amount of cpu register swichings for
    each given function
    and mostly, if one can set the compiler right, makes the execution more
    safe and stable.

    The main issue when it comes to good performance of gcc 4.6 and up is to
    avoid the default build models based on ancient gcc compilers,
    E.G. build all implementing -O3 -fno-gcse -mtune=(host cpu) pentium3
    offers stunning performance allover the Winboxes i tested
    from an array of the most recent multicores/Win7 to over five year old
    XP''s, -march=(cputype) offers stunning performance but from
    version/gcc 4.6 and up , such exeutables will only run on the explicitly
    declared cpu architechture.

    This tested on src
    of,, Cmake, Paraview, VTK, ITK, BOOST, QT 4 and 5 (don't understand why
    5 is issued,as no gains for a redundant restructure) ,
    GMSH, Gimp, Imagemagick, Maxima, R, Povray, OpenCv, Qbittorrent, Five
    Browsers based of the latest QT Webkit,
    FLTK, GNUmeric, speed/stability critical parts of GTK, GNUplot, 7zip,
    UPX, Scite/scintilla, wxWidgets, OpenBabel/Avogadro,
    to mention a few,, into extremely fast and reliable executables. QT4
    caution as gcc 4.8.1-4 due to some restructuring of it's headers
    only goes half through QT4, but it's a minor problem as it's just to
    prebuild all with 4.7.3 first, as both use the samt RT.

    The latest mingw packages are phenomenal, outperforming MSCV builds with
    at least 30 percent in execution speed, my record
    was Gnuplot that are about 150% faster than other builds, tested using
    all demos enter down.

    Mingw/msys must be ahead of Windows in the path environment.

    have in mind that gcc are highly structurable and

    gcc 4.6/4.7/4.8 -O3 by default implements.

    -fdefer-pop
    -fmerge-constants
    -fthread-jumps
    -floop-optimize
    -fif-conversion
    -fif-conversion2
    -fdelayed-branch
    -fguess-branch-probability
    -fcprop-registers > -O on
    -fforce-mem
    -foptimize-sibling-calls
    -fstrength-reduce
    -fcse-follow-jumps -fcse-skip-blocks
    -frerun-cse-after-loop -frerun-loop-opt
    -fgcse -fgcse-lm -fgcse-sm -fgcse-las

    -fdelete-null-pointer-checks
    -fexpensive-optimizations
    -fregmove
    -fschedule-insns -fschedule-insns2
    -fsched-interblock -fsched-spec
    -fcaller-saves
    -fpeephole2
    -freorder-blocks -freorder-functions
    -fstrict-aliasing
    -funit-at-a-time
    -falign-functions -falign-jumps
    -falign-loops -falign-labels
    -fcrossjumping > -O2 on
    -falign-functions -falign-jumps -falign-loops
    -falign-labels -freorder-blocks -fprefetch-loop-arrays > -O3

    and most of them works just fine on gcc 4.6 and up,
    the gcse optimizers seems to be reliable only up to -O2, as garbling up
    computed goto's, together with
    -fguess-branch-probability, as I experimented with Gnuplot and some
    others -fno-gcse -fno-guess-branch-probability
    performed around 150% faster/superstable, compared with fully optimized
    msvc/latest versions.

    Beware of that -fguess-branch-probability actually fixes up code jumps
    of non perfectly structured code and
    hence can disable functionality of produced code, and another caveat is
    -g -O2 as of many default automake builds
    actually is a source of gcc debugging systems poor reputation as this
    switch produces slightly different binaries
    each and every build, -g -O2 -fno-guess-branch-probability gives the
    debugger a fair chance.
    I commonly use -O3 -fno-gcse -mtune=pentium3 -pipe -mthreads for all
    programs that will be under portable deployment,
    and add -march=(suitable cpu) -mtune=(suitable cpu) for stationary
    customized deployment, but such will only
    run on the specified cpu architechture only, they will of course perform
    extremely fast.

    CheersNseasonsGreetings in advance!

     
    • Sean Morrison

      Sean Morrison - 2013-12-06

      On Dec 5, 2013, at 11:03 PM, cpumeshman wrote:

      Never seen this type of build with cmake before.

      You've never seen cmake before or never seen a cmake build system as complex as BRL-CAD's?

      There are sets of compiler switches that are enabled by default ! and I
      can't take them away through a
      standard textfile, hence I'm unable to make strict architecture build's
      of bricad.

      The compilation flags are all controlled by a number of cmake variables. Nearly all of the ones we define are listed in our INSTALL file. For example, if you disable warnings, debug, and optimization, it should result in hardly any flags getting set except where to locate headers.

      Most of the implemented dual redundant switches originates from old/pre
      4.6 mingw compilers.

      What is dual/redundant? Please be specific.

      Advices on gcc later models based on some billon lines of parsed src below.

      and have in mind that speed when it comes to app execution cant be
      compared with car driving.

      Anything can be compared. Whether it's useful or logical to make such a comparison is left as an exercise for the reader. We have not made any such comparison, so I'm not sure why you feel the need to share this information.

      Speed is achieved by reducing the amount of cpu register swichings for
      each given function
      and mostly, if one can set the compiler right, makes the execution more
      safe and stable.

      Non sequitur, but that statement sounds an awful lot like a comment from a friend of mine regarding car racing: "Speed is achieved by reducing the gear shift time through turns and mostly, if one can get the engine tunings right, it makes for a better lap times." So much for not being able to compare it to car driving. ;)

      The main issue when it comes to good performance of gcc 4.6 and up is to
      avoid the default build models based on ancient gcc compilers,
      E.G. build all implementing -O3 -fno-gcse -mtune=(host cpu) pentium3
      offers stunning performance allover the Winboxes i tested
      from an array of the most recent multicores/Win7 to over five year old
      XP''s, -march=(cputype) offers stunning performance but from
      version/gcc 4.6 and up , such exeutables will only run on the explicitly
      declared cpu architechture.

      We don't add tuning flags so that the resulting binaries are more portable. You're welcome to compile and set your own tuning flags. Additional flags can be specified by setting the CFLAGS and CPPFLAGS prior to running cmake. There are other ways as well.

      Mingw/msys must be ahead of Windows in the path environment.

      It's not at all hard to compile faster than MSVC.

      gcc 4.6/4.7/4.8 -O3 by default implements.

      I'm not sure why you chose to share information about gcc flags.

      I commonly use -O3 -fno-gcse -mtune=pentium3 -pipe -mthreads for all
      programs that will be under portable deployment,
      and add -march=(suitable cpu) -mtune=(suitable cpu) for stationary
      customized deployment, but such will only
      run on the specified cpu architechture only, they will of course perform
      extremely fast.

      You're welcome to use whatever flags you like for your builds. We even provide an integrated performance benchmark suite that will tell you exactly how well our engine is performing under a given set of compilation flags. You can use that to compare the real-world performance of different compiler flags. Run "make benchmark" from a build tree or simply "benchmark" if you installed BRL-CAD.

      Cheers!
      Sean

       
      • cpumeshman

        cpumeshman - 2013-12-08

        On 2013-12-06 06:48, Sean Morrison wrote:

        On Dec 5, 2013, at 11:03 PM, cpumeshman wrote:

        Never seen this type of build with cmake before.
        

        You've never seen cmake before or never seen a cmake build system as
        complex as BRL-CAD's?

        /Cmake,, some hundreds of builds and in direct connection with kitware
        on issues./
        /I,m using 2.8 the latest builds setting up with the QT gui/, /and I've
        never seen so many presets in any build before/
        /and have problems to to change those presets through the gui/, /and
        never encountered such problems before./

        There are sets of compiler switches that are enabled by default !
        and I
        can't take them away through a
        standard textfile, hence I'm unable to make strict architecture
        build's
        of bricad.
        

        The compilation flags are all controlled by a number of cmake
        variables. Nearly all of the ones we define are listed in our INSTALL
        file. For example, if you disable warnings, debug, and optimization,
        it should result in hardly any flags getting set except where to
        locate headers.

        /O.K. I'm a stupid GUI drone in that case/.

        Most of the implemented dual redundant switches originates from
        old/pre
        4.6 mingw compilers.
        

        What is dual/redundant? Please be specific.

        /Just look at the generated makefiles and compare with the default gcc
        switches i sent./

        Advices on gcc later models based on some billon lines of parsed
        src below.
        
        and have in mind that speed when it comes to app execution cant be
        compared with car driving.
        

        Anything can be compared. Whether it's useful or logical to make such
        a comparison is left as an exercise for the reader. We have not made
        any such comparison, so I'm not sure why you feel the need to share
        this information.

        /I'm a "nonofficial member" of the 200 mph on public highway, in a
        custom built Brabus Mercedes, and regard driving in such speed
        quite dangerous, even if trained. Seems that people in general regard
        execution speed on computers/intuitively in the same manner.
        //As I've been programming cpu's with toolset, from solder iron, and up
        i see this clearly.
        To implement for example five to ten light switches in serial for to
        turn on a single bulb naturally
        increases chances to failure.
        /

        Speed is achieved by reducing the amount of cpu register swichings
        for
        each given function
        and mostly, if one can set the compiler right, makes the execution
        more
        safe and stable.
        

        Non sequitur, but that statement sounds an awful lot like a comment
        from a friend of mine regarding car racing: "Speed is achieved by
        reducing the gear shift time through turns and mostly, if one can get
        the engine tunings right, it makes for a better lap times." So much
        for not being able to compare it to car driving. ;)

        /As of above . . . . ./

        The main issue when it comes to good performance of gcc 4.6 and up
        is to
        avoid the default build models based on ancient gcc compilers,
        E.G. build all implementing -O3 -fno-gcse -mtune=(host cpu) pentium3
        offers stunning performance allover the Winboxes i tested
        from an array of the most recent multicores/Win7 to over five year
        old
        XP''s, -march=(cputype) offers stunning performance but from
        version/gcc 4.6 and up , such exeutables will only run on the
        explicitly
        declared cpu architechture.
        

        We don't add tuning flags so that the resulting binaries are more
        portable. You're welcome to compile and set your own tuning flags.
        Additional flags can be specified by setting the CFLAGS and CPPFLAGS
        prior to running cmake. There are other ways as well.

        /My point was that i always build with -mtune, and where can one find a
        box architecture that don't can run pentium3 tuning ?
        Since the introduction of gcc 4.6 -mtune whatever is fully portable on
        any intel type cpu. and about redundancy, -msse3 is turned on
        by default with -mtune, and the non portable -march.
        Tested extensively an an array of Winboxes. gcc has really gone through
        a radical development on these issues lately./

        Mingw/msys must be ahead of Windows in the path environment.
        

        It's not at all hard to compile faster than MSVC.

        gcc 4.6/4.7/4.8 -O3 by default implements.
        

        I'm not sure why you chose to share information about gcc flags.

        /To make coders understand the enhancements with recent gcc toolchains,
        as I in many cases envy their coding skills
        while quite confused why they not set the compilers right, and
        frequently are short of knowledge about
        the tools they are using./

        I commonly use -O3 -fno-gcse -mtune=pentium3 -pipe -mthreads for all
        programs that will be under portable deployment,
        and add -march=(suitable cpu) -mtune=(suitable cpu) for stationary
        customized deployment, but such will only
        run on the specified cpu architechture only, they will of course
        perform
        extremely fast.
        

        You're welcome to use whatever flags you like for your builds. We even
        provide an integrated performance benchmark suite that will tell you
        exactly how well our engine is performing under a given set of
        compilation flags. You can use that to compare the real-world
        performance of different compiler flags. Run "make benchmark" from a
        build tree or simply "benchmark" if you installed BRL-CAD.

        Cheers!
        Sean

        Cheers back !
        Peter.

        P.S

        I have some defect in my brain, hEh, frequently typing partially backwards,
        have no problem to write right and left hand simultaneously mirror wise.
        Have to live with that.
        Sent the first one by prematurely by mistake .
        Pere LoL.


        how do I change Cmake compiler switches in bricad
        http://sourceforge.net/p/brlcad/discussion/362510/thread/35ff9a95/?limit=250#d40c/e682


        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/brlcad/discussion/362510/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

         
        • Sean Morrison

          Sean Morrison - 2013-12-08

          On Dec 7, 2013, at 8:51 PM, cpumeshman wrote:

          /Just look at the generated makefiles and compare with the default gcc switches i sent./

          Your description of the problem was not clear to me. I don't think it's a good use of time to hunt for an unknown problem. As I originally stated, please be specific if you see a problem and I'll be glad to look into it.

          /I'm a "nonofficial member" of the 200 mph on public highway, in a
          custom built Brabus Mercedes, and regard driving in such speed
          quite dangerous, even if trained. Seems that people in general regard
          execution speed on computers/intuitively in the same manner.

          I'm not sure I see your point here either. Excessively waxing poetic. Sounds like you're saying people regard fast-running applications as potentially life-threatening, or perhaps application-threatening. Either way, the analogy isn't working for me.

          Let's stick to a tangible topic, please. If you have a point to say, just directly say it instead of through metaphor or analogy.

          /My point was that i always build with -mtune, and where can one find a
          box architecture that don't can run pentium3 tuning ?

          I happen to have several non-pentium boxes still in use, but irrelevant.
          You can build with whatever flags you desire including -mtune. If that really is your point, then my response is "okay." If you're trying to convince us to use it, that is unnecessary. I'm fully aware of what it does and we intentionally do not use it by default. There is nothing that prevents you from using it, though, and that is intentional.

          Since the introduction of gcc 4.6 -mtune whatever is fully portable on
          any intel type cpu. and about redundancy, -msse3 is turned on
          by default with -mtune, and the non portable -march.

          An application compiled with SSE instructions will crash on hardware without an SSE unit. We discovered that issue the hard way on more than one occasion.

          /To make coders understand the enhancements with recent gcc toolchains,
          as I in many cases envy their coding skills
          while quite confused why they not set the compilers right, and
          frequently are short of knowledge about
          the tools they are using./

          I follow the gcc developments quite closely and have done so for a couple decades, but your desire to help educate others is apparent. For what it's worth, BRL-CAD is actually a bit older than gcc but we invest a lot of time in effort in knowing our tools and setting up infrastructure that leverages them (as you noticed and complained about).

          Cheers!
          Sean

           

Log in to post a comment.