Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 45

Thread: The "Dirndl" On AMD Opterons Are Impressive

  1. #31
    Join Date
    Dec 2009
    Posts
    71

    Default

    Quote Originally Posted by Welsh Dwarf View Post
    If it is EKOPath, I'm going to regret not using Gentoo :P

    Anyhow, the PKGBUILD for mesa will get a tweak, that's for sure ^^

    David
    I hope it happens for every single PKGBUILD.

    Do you think Arch will switch to EKOPath any time soon?

  2. #32

    Default

    Quote Originally Posted by Viper_Scull View Post
    I hope it happens for every single PKGBUILD.

    Do you think Arch will switch to EKOPath any time soon?
    They didn't switch to systemd, so I doubt if they'll switch to EKOPath soon.

  3. #33

    Default

    Quote Originally Posted by clavko View Post
    They already released some of their code under BSD licence,

    http://www.prweb.com/releases/2011/5/prweb8464380.htm

    It would be nice if this code dump would be BSD too.
    This was for freebsd. This time it's different, so I hope they'll choose a GPL.

  4. #34
    Join Date
    Oct 2007
    Posts
    284

    Default

    Verry impressive results. But those results do remind me of the "compiler deathmatch" use the search function to find it. In that deathmatch gcc could be made A LOT faster than the stock settings. Archlinux four example it's using roughly the stock compiler settings. If this new compiler is just by default having all those optimizing things turned on than the current phoronix comparisons aren't even fair..

    Just my 5 cents..

  5. #35
    Join Date
    Jun 2009
    Posts
    2,925

    Default

    Quote Originally Posted by markg85 View Post
    Verry impressive results. But those results do remind me of the "compiler deathmatch" use the search function to find it. In that deathmatch gcc could be made A LOT faster than the stock settings. Archlinux four example it's using roughly the stock compiler settings. If this new compiler is just by default having all those optimizing things turned on than the current phoronix comparisons aren't even fair..

    Just my 5 cents..
    Gentoo guys will mostly tell you to stick to -march-native -O2 -pipe, anything more aggressive leads to breakage somewhere.

    Aggressive optimisations should be used per-package, when you know that they won't break a particular package.

  6. #36
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,968

    Default

    Any compiler guys around to tell whether a 2-3x increase like this over latest gcc is considered possible/doable? I was under the impression it's already very good, with icc only gaining 10-30% and visual studio less.

  7. #37
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,581

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Gentoo guys will mostly tell you to stick to -march-native -O2 -pipe, anything more aggressive leads to breakage somewhere.

    Aggressive optimisations should be used per-package, when you know that they won't break a particular package.
    In some cases it also leads to slower performance.

  8. #38
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Gentoo guys will mostly tell you to stick to -march-native -O2 -pipe, anything more aggressive leads to breakage somewhere.

    Aggressive optimisations should be used per-package, when you know that they won't break a particular package.
    That's -march=native

    I've been playing with -O3 and -Ofast using GCC 4.6

    -Ofast has problems with SQlite and wine won't start programs with -O3

    I think I may switch back to my tried and tested -Os though

  9. #39
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by curaga View Post
    Any compiler guys around to tell whether a 2-3x increase like this over latest gcc is considered possible/doable? I was under the impression it's already very good, with icc only gaining 10-30% and visual studio less.
    I personally find it very unlikely, which is why I'm leaning towards this being about a cpu+gpu compiler. I haven't seen icc reach anything near 2x against gcc/llvm in my (admittedly few) benchmark tests so I doubt ekopath would be able to generate so much better code as to result in 2x, 2.3x better performance (although it sure would be awesome!). As for Visual Studio, last time I benchmarked it against GCC, GCC generated faster code for Mame atleast (which was the only test I did), but that was VS 2008 though.

  10. #40
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by FireBurn View Post
    That's -march=native

    I've been playing with -O3 and -Ofast using GCC 4.6

    -Ofast has problems with SQlite and wine won't start programs with -O3

    I think I may switch back to my tried and tested -Os though
    Weird that sqlite has problems with -Ofast (assuming that it works with -O3) since -Ofast only turns on -ffast-math and I can't see why sqlite would depend on high-precision for it's floating point math.

    As for -Os, it prefers code size over code speed, so unless you are starved for ram I would suggest using -O2 where -O3 causes problems rather than -Os.

Tags for this Thread

Posting Permissions

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