In case anyone was curious, these are my latest results for AMD K8-based
(Opeteron, Athlon64, Sempron64) processors running in a 64-bit Linux.

gcc, CFLAGS=CXXFLAGS=default
Total Time:    0 hours 20 minutes  5 seconds (1205 seconds)

icc, CFLAGS=CXXFLAGS="-O3 -ip -xW"
Total Time:    0 hours 21 minutes 10 seconds (1270 seconds)

icc, CFLAGS=CXXFLAGS="-O3 -ip -xP"
Total Time:    0 hours 21 minutes 27 seconds (1287 seconds)

gcc, CFLAGS=CXXFLAGS="-O3 -mfpmath=387"
Total Time:    0 hours 25 minutes 44 seconds (1544 seconds)

gcc, CFLAGS=CXXFLAGS="-O3 -mfpmath=sse,387"
Total Time:    0 hours 22 minutes 13 seconds (1333 seconds)

Notes:
- benchmark.pov scene, command-line switch: -w384 -h384 +a0.3 +v -d -f -x
- Results are on my Athlon64 (2.4 GHz)
- Patched icc to allow optimized code to run on non-Intel processors

Post a reply to this message

Forgot to mention the compilers used:
1) gcc 3.4.4
2) icc 9.0

Post a reply to this message

> 2) icc 9.0

	Do you confirm you are using icc for EM64T-based applications, aka icce?

http://pov4grasp.free.fr/articles/fastpov1/

	- NC

Post a reply to this message

Yes. Here's the file output:

povray-icc-xp: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped

Nicolas Calimet <pov### [at] freefr> wrote:
> > 2) icc 9.0
>
>  Do you confirm you are using icc for EM64T-based applications, aka icce?
>
> http://pov4grasp.free.fr/articles/fastpov1/
>
>  - NC

Post a reply to this message

> - Patched icc to allow optimized code to run on non-Intel processors

	Doing some quick tests, I don't seem to get any speed difference on a K8
(Opteron 246 @ 2 GHz) between a POV-Ray 3.6.1 binary that I used for my study*
built with icce 8.1 and the same binary patched with Mark Mackey's perl script
that removes the test for the "GenuineIntel" CPUID string.
	Did you use a different patch, and could you provide benchmark results for
an unpatched binary as well?

(*) the k8-icce-8.1-ip-axW binary, for which the raw results are not reported

	- NC

Post a reply to this message

I think I used the same patch. Although the reason I used it is because the
-xP option would give a fatal error (although -axP worked fine) prior to
patching. Running the unpatched compiler with -axP would make the program
run the generic code path (equivalent to compiling with -xW).

The -xP option supposedly utilizes sse3 and other optimizations, yet the
compiled program is still slower than with the default -xW. Anyone with an
EM64T cpu want to try this out?

-John

Nicolas Calimet <pov### [at] freefr> wrote:
> > - Patched icc to allow optimized code to run on non-Intel processors
>
>  Doing some quick tests, I don't seem to get any speed difference on a K8
> (Opteron 246 @ 2 GHz) between a POV-Ray 3.6.1 binary that I used for my study*
> built with icce 8.1 and the same binary patched with Mark Mackey's perl script
> that removes the test for the "GenuineIntel" CPUID string.
>  Did you use a different patch, and could you provide benchmark results for
> an unpatched binary as well?
>
> (*) the k8-icce-8.1-ip-axW binary, for which the raw results are not reported
>
>  - NC

Post a reply to this message

> Although the reason I used it is because the
> -xP option would give a fatal error (although -axP worked fine) prior to
> patching.

	But that's expected: -xP will emit SSE3 instructions that are not
supported by the k8; therefore the program aborts.

	Now, I don't understand why applying this patch would change the
situation since, in principle, the binary does not contain any sse2/x87
path (unlike when using -axP).  In fact I just tried to patch a binary
produced on a k8 using -xP and the resulting binary does not work either,
producing the same error message at startup.
	Maybe you did use another patch?

	- NC

Post a reply to this message

I got the patch from http://www.swallowtail.org/naughty-intel.html

I think the reason the -xP binary doesn't work on your Opteron is because it
might be the Sledgehammer core, which doesn't have sse3 support (Venus core
does though). My Athlon64 is a Venice core, which does include sse3
support.

-John

Nicolas Calimet <pov### [at] freefr> wrote:
> > Although the reason I used it is because the
> > -xP option would give a fatal error (although -axP worked fine) prior to
> > patching.
>
>  But that's expected: -xP will emit SSE3 instructions that are not
> supported by the k8; therefore the program aborts.
>
>  Now, I don't understand why applying this patch would change the
> situation since, in principle, the binary does not contain any sse2/x87
> path (unlike when using -axP).  In fact I just tried to patch a binary
> produced on a k8 using -xP and the resulting binary does not work either,
> producing the same error message at startup.
>  Maybe you did use another patch?
>
>  - NC

Post a reply to this message

> I got the patch from http://www.swallowtail.org/naughty-intel.html

	Ok, same here.

> My Athlon64 is a Venice core, which does include sse3
> support.

	Ah, right.  So the small slowdown you see from -xW to -xP should be
due to the use of SSE3 indeed.  I suppose it's because of microarchitecture
differences between Intel's and AMD's implementations of SSE3 that makes
icc produce slower code here.
	In any case you'd better stick with gcc on the k8  :-)

	- NC

Post a reply to this message

Well, this is interesting. Here are the results for patched vs. unpatched
icc:

povray-icc-axw-patched, CXXFLAGS="-O3 -ip -axW"
Total Time:    0 hours 21 minutes 39 seconds (1299 seconds)

povray-icc-axw-unpatched, CXXFLAGS="-O3 -ip -axW"
Total Time:    0 hours 35 minutes 13 seconds (2113 seconds)

So, boys and girls, please use gcc to compile povray if you don't have an
Intel processor.

Post a reply to this message