An easy check would be to see if there is a Makefile glitch of some kind, and you're getting some 32-bit binaries when you think you're getting 64-bit binaries. That would run significantly slower on x86.
Something like: find . -type f | xargs file | grep 32-bit It's easy to get this kind of 32/64 problem with Sun compilers because they default to 32-bit on 64-bit machines, which is the opposite from gcc. I'll forward your original email to the x86 compiler team to see if they have any ideas. --chris Joerg Schilling wrote: > Chris Quenelle <Chris.Quenelle at sun.com> wrote: > >> The Sun Studio team has many performance tests we use to make >> sure we continue to deliver a 64-bit x86 compiler that has >> world-class optimization. I can't say anything about your specific >> test case obviously. Is the "mdigest" program a part of some >> widely used benchmark or a commonly used open source application? > > The program is a wrapper on the message digest implementation from > FreeBSD/OpenBSD, so it seems to be of general interest. The version I > am talking about was made portable by me, so it may now be used on many > places. > > >>> Is there a chance that SunStudio will get better optimization for amd64? >> I believe our amd64 optimization gets better with each release, >> although the nature of compiler optimization means that there >> will always be some give-and-take between releases in any specific app. > > I have another higly optimized piece of code (a reed solomon coder) that is > notably faster when compiled with gcc. In all cases, I see a common tendency: > the 32 bit binary from SunStudio is faster than the one compiled with gcc and > the 64 bit binary is slower compared to the binary produced by gcc. > > BTW: the reed solomon coder is the latest version of the only free (OSS) > implementation of a reed solomon coder for CD data sectory. > > J?rg >
