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

[russofris]

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

[Hirager]

"-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++.

[Qaridarium]

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.

[Drago]

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

[razibuzouzou]

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

[XorEaxEax]

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.

[pingufunkybeat]

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.

[russofris]

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

[Hirager]

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.

[curaga]

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.