Page 3 of 3 FirstFirst 123
Results 21 to 27 of 27

Thread: GLAMOR Acceleration Might Work On Newer X.Org

  1. #21
    Join Date
    Mar 2011
    Posts
    87

    Default

    Quote 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

  2. #22
    Join Date
    Dec 2012
    Posts
    403

    Default

    Quote 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.

  3. #23
    Join Date
    Mar 2011
    Posts
    87

    Default

    Quote 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...

  4. #24
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,721

    Default

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

  5. #25
    Join Date
    Dec 2012
    Posts
    403

    Default

    Quote 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.

    Quote 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.

  6. #26
    Join Date
    Mar 2011
    Posts
    87

    Default

    Quote Originally Posted by Rexilion View Post
    Apologies, I mistook you for jrch2k8.
    no offence taken.


    Quote 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.

    Quote 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.

    Quote 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.

  7. #27
    Join Date
    Dec 2012
    Posts
    403

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •