I just benchmarked a critical application compiled with both CC 5.4
(Forte 7) and CC 5.8 (Sun Studio 11) on an UltraSPARC-IIi CPU.
CC 5.4 generates code that is 20% faster than CC 5.8.
That's aweful! What gives?
Switches used:
CC -mt -fast -xtarget=ultra2 -template=wholeclass,no%extdef -instances=explicit -c
UltraSparc II systems are old, and we no longer do performance testing on them. If you find that performance has regressed on US III or US IV, we would definitely be concerned.
If you have a service contract with Sun, you can file a bug report via the support channel, and have it escalated. That is the most likely way to get a fix.
If you don't have a service contract, you could file a bug report via bugs.sun.com.
EIther way, you would need to provide a test case that demonstrates the performance regression of Studio 11 vs Forte 7. Even via bugs.sun.com, someone will look at the problem and determine a priority for fixing it.
[slow CC 5.8]
> CC -mt -fast -xtarget=ultra2
Wouldn't -xtarget=ultra2i make more sense,
> -template=wholeclass,no%extdef -instances=explicit -c
Ugh! I mean ugh!!! Do you really need wholeclass and explicit? In my previous workplace, we had 'wholeclass' imposed on us. I never could see any justification with Studio 10 and 11. It only bloats the object code and potentially forces definitions of meaningless/dangerous members.
Paul
So it's "give me money and I'll fix it?"
Sorry, I don't think so. I just had to back out the recent
patches to the 5.4 compiler because they broke it.
Also had to back out the recent Solaris8 patch
cluster because I got this lovely little crash:
panicstr: free: freeing free block, dev:0x%lx, block:%ld, ino:%lu, fs:%s
So I just wasted an entire day reloading a backup to get back
to the stable 2003/4 versions. You guys have totally lost
your quality. Hardly matters as my primary systems are all
AMDs running Linux. I keep the old Ultrasparc around for
supporting a couple of laggard customers who still use them.
I was thinking I might support Niagara, but now I seriously
doubt it. AMD quad-cores will be here shortly.
As far a performance goes, the degradation with the 5.8
compiler is actually closer to 25%. I don't buy for a second
that it will work better on an Ultrasparc III or IV. There's
not much difference between IIs and the later CPUs.
We're sticking with the old compiler and old patch levels.
> So it's "give me money and I'll fix it?"
Not exactly that.
In theory we would love to fix all the bugs and implement all the features we ever thought of.
Yet in real world it comes down to resources and proper prioritizing.
We will definitely address any correctness problems reported (and its pity to hear that Solaris8 patch gets you into trouble), however when it comes to performance it is a different ballpark.
Sorry, if it sounds too trivial to be truth, but there is no such thing as ideal optimization. Optimization is always a tradeoff, and heuristics happen to shift towards a newer architectures.
I'm pretty much sure that most (if not every) of the modern compilers happen to compile badly for an aging architecture, even if they did know how to compile efficiently for it.
Besides code generation (which should not really deteriorate) there are high level optimizations, or even design decisions which are not always properly attributed to (old) target platform.
It depends, but your given performance regression might be very hard to fix w/o compromising newer targets. And if we have to choose, then its logical to choose target that is important for majority of our customers.
Which is not, to my knowledge, ultra2 (I might be wrong, though).
However you should keep in mind that through all these new releases we were also adding new features, which might well help you even on that ultra2.
As a bottom point, if you are absolutely happy with the old compiler on the old platform - then, frankly, stick with it.
If you need more performance then you'll have to change to a newer platform (and almost inevitably to a newer compiler as well).
> I just had to back out the recent patches to the 5.4 compiler because they broke it.
Please, report this problem through whatever channel you have (bugs.sun.com would do that).
As I said, we are really concerned about correctness problems.
> I was thinking I might support Niagara, but now I seriously doubt it.
Honestly, from all the thread above I still dont understand why.
regards,
__Fedor.
> So it's "give me money and I'll fix it?"
That is not what I said. The compiler is free, and this forum is free, and filing bugs via bugs.sun.com is free. We do pay attention to all submitted bugs, and assign them priorities.
Priorities are assigned based on the perceived severity of the problem, how many customers are likely to be affected, and available resources. Some bugs filed via bugs.sun.com have been judged important enough to fix immediately, even though they were reported by someone who hadn't paid for anything.
Since Sun is a business, we naturally give higher priority to customers who pay for support. After all, thatt is what they are paying for. Isn't that how your business is run?
As Fedor already replied, if you have found correctness regressions in patches, please report them via bugs.sun.com. We treat such regressions seriously, no matter who reports them.
Sorry guys, but I don't have any more time to waste on this. I feel like I just touched the third rail--my hair is still smoking. Four friggin' days completely wasted: two to apply the Solaris 8 patch levels and install and benchmark the 5.8 compilers. Another day to explore how bad the compiler was and discover serious regressions in the OS patches and 5.4 compiler patches. Yet another day to restore the system from backups.
I used to patch and update about once every eight months. It was always a pain, but seemed worth the trouble since at one time Sun software improved with every release. The two year delay since the last cycle was because our code wouldn't compile with post 5.4 C++ version for that entire time, and everything was otherwise working fine. I submitted two compiler bugs two years ago against C++ 5.6 through a major Sun account's support channel and it took TWO YEARS for the fix to make it into the compiler.
The good news is that the big delay saved me from sinking into a hole of bad patches, regressions and wasted time. My system sare now back at their spring-of-2004 state of blissful stability. I'm never going to touch them again till the last customer kills off their last Sparc machine and I unplug them and throw them away. It's really sad.
