Announcement

Collapse
No announcement yet.

GLAMOR Acceleration Might Work On Newer X.Org

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by jrch2k8 View Post
    for example
    Qt-gui with -o2 native is fast ofc but you notice few Ms delay between click and apps opening
    Qt-gui with my 30 flags is almost open when you take your finger of the mouse
    Qt-gui with my 30 flags + PGO[<-- not easy] is instant i mean freaking instant

    so if you dare to play with your compiler setting you can gain some free perfomance and squeze some additional responsiveness
    my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

    Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there

    Comment


    • #22
      Originally posted by ryszardzonk View Post
      my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

      Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there
      The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

      Seriously, you don't want coreutils with lto and ffast-math.

      Comment


      • #23
        Originally posted by Rexilion View Post
        The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

        Seriously, you don't want coreutils with lto and ffast-math.
        Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...

        Comment


        • #24
          Why wouldn't one want LTO for coreutils? ~10% smaller binaries for free.

          Comment


          • #25
            Originally posted by ryszardzonk View Post
            Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...
            Apologies, I mistook you for jrch2k8.

            Originally posted by jrch2k8 View Post
            my make.conf pass around 30 flags to gcc including LTO/Graphite/bulldozer specifics/etc.[have a regular set of flags too without lto for some problematic packages maybe 30 in my whole emerge world]
            What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.

            Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.

            Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.

            Comment


            • #26
              Originally posted by Rexilion View Post
              Apologies, I mistook you for jrch2k8.
              no offence taken.


              Originally posted by Rexilion View Post
              What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.
              That is true but in my experience I does not happen all that often as it is believed. In years with Linux I reported quite a number of bugs and only like 1/10 of them where flag related and some of those few could be fixed by small changes in the code. In one case for example in this very forum in thread about llvm I reported problem with -DG_DISABLE_ASSERT and it turned out it was fixed with adding just one appropriate ifdef to the code already in place.

              Originally posted by Rexilion View Post
              Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.
              This might be true, but once in the past I tested decompressing speed of apps such as bzip2 and gzip once compiled with different flags -Os, -O2, -O3, -O3 + ffmath, etc and difference between slowest and fastest was 10-15%, where like 2-3% was betwwen -Os and -O2, 7-10% from -O3 and then the rest, so replacing default -O2 with -O3 for apps that use a lot of computations I believe to be very appropriate.

              Originally posted by Rexilion View Post
              Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.
              Yes it does replace it and one might not harness its full potential when simply is going with the default like the above test reveled for me. Going system wide with all the flags available is just plain wrong and will create problems, but saying they optimization are not to be tried on app by app or lib by lib is just as wrong and IMHO it is not only QT that will gain from it.

              Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.

              Comment


              • #27
                Originally posted by ryszardzonk View Post
                Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.
                I agree with the above statements. However, I want to add that, libjpeg-turbo is mostly handwritten asm. I do not believe that compiler flags will change much about it's performance.

                Comment

                Working...
                X