Getting Peak Olympus Performance Using the Studio 12 Compilers
The new Sun Studio 12 compilers have been optimized to produce the best performance for SPARC64-VI binaries. It is possible to achieve gains of 30% or more over binaries compiled with the Studio 11 compilers.
We recommend using the following options when compiling for SPARC64-VI:
-xchip=sparc64vi
Generate code that is tuned for SPARC64-VI. The binary will run on any SPARC processor, but will perform best on a SPARC64-VI system.
-xarch=sparcfmaf -fma=fused
Both of these options are necessary to enable the usage of the new fused multiply add instructions. The binary will only run on SPARC64-VI, and any future SPARC systems that support the fused multiply add instructions. These instructions improve the performance of some floating point programs.
-xtarget=sparc64vi
A combination of -xchip=sparc64vi and -xarch=sparcfmaf. It is still necessary to use -fma=fused to enable fused multiply add instructions.
Posted by Jeroen on May 27, 2007 at 11:11 PM EDT #
To allay any concerns, I'll let you know that during development of the M-class servers, we didn't even have the compiler changes until very late. But we were still able to run the same Solaris build as the rest of Sun's UltraSPARC product line.
Posted by Bob Hueston on May 28, 2007 at 09:39 AM EDT #
I compiled a new binary using these CC Flags: "-KPIC -xchip=sparc64vi -xarch=sparcfmaf -m64 -fma=fused -xcode=abs32 -DEOS_SUN -DEOS_UNIX"
Yet a file command showed this:
"ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC1 Extensions Required, dynamically linked, not stripped"
According to your blog this should not be executable on anything less than a Sparc64VI yet this binary ran just fine on a Sparc IIIi. Am I missing something?
I want to be sure that we are getting all the new performance enhancements
Posted by David Brossard on December 05, 2007 at 02:19 PM EST #
Rupert writes:
It looks like he found a bug in the compiler, but the expected behavior is actually not what he thinks.
We're moving away from marking the binary using the ELF header flags, and transitioning over to a "capabilities" model. The xarch values for sparcvis2 and before will still be marked in the ELF header flags. But the newer xarch values, including xarch=sparcfmaf will be marked using capabilities.
Under the capabilities model, a capability is only marked if an instruction is actually used in the object file. In this case, he compiled without optimization, so we wouldn't have generated any fma instructions. So the expected behavior in this case is for no capabilities to be marked, but for the ELF flags to show
ELF 64-bit MSB relocatable SPARCV9 Version 1, UltraSPARC3 Extensions Required.
The bug is that the binary was marked as requiring only UltraSPARC1 extensions. I have reproduced this problem, and will file a bug. The problem only appears when compiling without optimization.
Posted by Bob Hueston on December 06, 2007 at 10:27 AM EST #
David, you should try adding -xO2 along with the other CC Flags, that will give the desired result. Your binary will only run on sparc64VI afterwards, with an error like this.
ld.so.1: fmaOPT: fatal: hardware capability unsupported: 0x100 [ FMAF ]
Killed
Posted by Abel Lopez on March 20, 2008 at 12:37 PM EDT #