Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 41

Thread: AMD's FX-8150 Bulldozer Benefits From New Compilers, Tuning

  1. #21
    Join Date
    Jan 2009
    Posts
    462

    Default

    Quote Originally Posted by frantaylor View Post
    from the gcc docs:

    -mtune=native

    This selects the CPU to tune for at compilation time by determining the processor type of the compiling machine. Using -mtune=native will produce code optimized for the local machine under the constraints of the selected instruction set. Using -march=native will enable all instruction subsets supported by the local machine (hence the result might not run on different machines).
    "-mtune -O2" are CFLAGs.
    "+dvd +restricted-codes" are examples of USE flags

    I do not know whether or not the original poster knows the difference, so it is entirely possible that your response is fine.

    F

  2. #22
    Join Date
    Oct 2011
    Location
    Toruń, Poland
    Posts
    160

    Default

    Quote Originally Posted by russofris View Post
    "-mtune -O2" are CFLAGs.
    "+dvd +restricted-codes" are examples of USE flags

    I do not know whether or not the original poster knows the difference, so it is entirely possible that your response is fine.

    F
    I did three tries of Gentoo.
    1. Try to install it. FAIL
    2. Try to install and understand it. SUCCESS
    3. Try to use it. FAIL - The do-it-yourself model is not for me.

    I do understand the difference. Now, that I was reminded of -mtune=native I think about writing a PackageKit plugin which compiles the system with this flag. But first I have to finish learning C++.

  3. #23
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    the piledriver is mostly a bugfix for the bulldozer this "PhenomII-effect" will show how good the architecture really is.

    http://phoronix.com/forums/showthrea...m1-effect-quot

    i think the pile driver will get a fixed integer-divide-instruction-unit

    and piledriver will get 400-500mhz more because of Cyclos-clock-engine

    http://phoronix.com/forums/showthrea...the-Piledriver

    and the piledriver will get some speed-bug-fixes in the Firmware

    and the compiler optimisations will hit the market in the "closed source" world.

    in fact the bulldozerI is just the "PhenomI with TLB bug"

    i think the BulldozerII will be a great cpu.

  4. #24
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    500

    Default

    Quote Originally Posted by Qaridarium View Post
    the piledriver is mostly a bugfix for the bulldozer this "PhenomII-effect" will show how good the architecture really is.

    http://phoronix.com/forums/showthrea...m1-effect-quot

    i think the pile driver will get a fixed integer-divide-instruction-unit

    and piledriver will get 400-500mhz more because of Cyclos-clock-engine

    http://phoronix.com/forums/showthrea...the-Piledriver

    and the piledriver will get some speed-bug-fixes in the Firmware

    and the compiler optimisations will hit the market in the "closed source" world.

    in fact the bulldozerI is just the "PhenomI with TLB bug"

    i think the BulldozerII will be a great cpu.
    In one month we will see

  5. #25

    Default

    Hi,
    If I didn't misread the article, you used Open64 4.2.1. According to open64.net, this release is more than 3 years old !
    Could you run the same tests with Open64 5.0 ?
    Best regards

  6. #26
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by mayankleoboy1 View Post
    more proof that amd sucks at software.
    its own compiler produces slower binaries than GCC. when their developers have had some part in BD from the first working chips, and still they cant make a compiler that is producing better binaries than GCC.
    AMD supports GCC with optimizations for their cpu's, overall GCC has much better optimizations than Open64 so it's not surprising that specific AMD optimizations will yield better results in GCC than in Open64.

    As for USE flags and system-wide optimizations, I'd say that for the vast amount of software on your system you are better off with an optimization level like -O2 which strikes a good balance between code size and performance, and that also goes for cpu specific optimizations (-march=X). It really only pays to optimize those packages which are extremely CPU bound and even then I'd say only if you use them VERY regularly.

    For instance if I can shave off 15-25% time per frame when rendering 3d animations or physics/soft body/hard body simulations then recompiling that application with advanced optimizations like -Ofast and profile guided optimization is likely worthwhile. Or if you are playing a game on an emulator and it lags a bit under full frame rate it can be worthwhile to recompile it with better optimization just to give you a better experience when playing. But again, overall it's not something you'd want to do for your entire system as the gains (if any) in most cases will be extremely small.

    Of course I now some people who has it as a hobby to tweak their system into what they feel is the optimal performance/behaviour and that's no better or worse than most other hobbies. If it's something they find is fun/interesting doing, they should do it. It's their time after all.

  7. #27
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    People...

    Gentoo USE flags are not about optimisations, CFLAGS are about optimisations, and most Gentoo users leave it at "-march=native -O2" anyway.

    USE flags are about enabling and disabling functionality. Like building a Qt frontend (when supported by the program) instead of getting a GTK frontend with a KDE theme, just because some guy putting the distribution together thought that GNOME is more important. It's about disabling pulseaudio if you don't need it, without every program first trying to find it and giving you error messages. It's about compiling in patented features which are only legal when enabled at compile-time (think Mesa), which is why Debian will never have OpenGL 3 support, etc, etc.

    USE flags are about flexibility. They are cool. You use the program the way the programmer intended, not the way the distributor intended.

  8. #28
    Join Date
    Jan 2009
    Posts
    462

    Default

    Quote Originally Posted by pingufunkybeat View Post
    People...

    Gentoo USE flags are not about optimisations, CFLAGS are about optimisations, and most Gentoo users leave it at "-march=native -O2" anyway.
    This was pointed out a couple posts up. My feeling was that the OP either misspoke (had a senior moment and used the wrong word), or did not know the difference. His response indicated the former.

    F

  9. #29
    Join Date
    Oct 2011
    Location
    Toruń, Poland
    Posts
    160

    Default

    Quote Originally Posted by pingufunkybeat View Post
    People...

    Gentoo USE flags are not about optimisations, CFLAGS are about optimisations, and most Gentoo users leave it at "-march=native -O2" anyway.

    USE flags are about enabling and disabling functionality. Like building a Qt frontend (when supported by the program) instead of getting a GTK frontend with a KDE theme, just because some guy putting the distribution together thought that GNOME is more important. It's about disabling pulseaudio if you don't need it, without every program first trying to find it and giving you error messages. It's about compiling in patented features which are only legal when enabled at compile-time (think Mesa), which is why Debian will never have OpenGL 3 support, etc, etc.

    USE flags are about flexibility. They are cool. You use the program the way the programmer intended, not the way the distributor intended.
    However, in a way, USE flags do optimize the system in its own kind. But yeah, I agree this is not the regular, technical code optimization.

  10. #30
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,994

    Default

    Quote Originally Posted by gururise View Post
    Michael,

    Great article really showing the potential of the Bulldozer core with a well matched compiler. Please please do an update for the ARM cpu's comparing GCC 4.4 - 4.7

    Thanks
    This. Please test the latest Linaro gcc in addition to upstream releases.

Posting Permissions

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