Christoph Hormann wrote:
> gRRosminet wrote:
> 
>>
>> I have downloaded the official binary for linux and ran the benchmark.
>>
>> Official : 45 minutes 08 seconds ( 2708 seconds )
>> gcc pentium4 optimized : 36 minutes 43 seconds ( 2203 seconds )
>> ICC pentium4 optimized : 33 minutes 01 seconds ( 1981 seconds )
>>
>> ratios (official / optimized) :
>> Official : 1
>> gcc pentium4 optimized : 1.229
>> icc pentium4 optimized : 1.367
> 
> 
> My test results look quite different:
> 
> official 3.5:              2394s
> 3.6 RC1 (gcc 3.4):         2292s
> 3.6, optimized* (gcc 3.4): 2274s
> 
> *) -march=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow
> 
> And before someone asks: profiling based optimization also does not 
> change much about this (i tested this some time ago).
> 
> The most likely explanation for your results to me seems the pentium 4 
> being particularly bad at running code not specifically optimized for 
> its design.
> 
> Christoph
> 



Could you try it with an optimized version of 3.5 ?
The first time I tried to compile an optimized version of povray, it was 
on an Athlon Thunderbird and I get very good results on a personal scene 
(wich didn't use so many functionnalities as the benchmark one)


for my pentium 4, an other explanation could be that the sse2 
instruction are really better on floating point than sse.
In your case, you limit yourself at using SSE instruction whereas Athlon 
processors have an excelent fpu unit. you should replace -mfpmath=sse by 
-mfpmath=sse,387

Here is the GCC man page about this option :
sse,387

Cela double effectivement le nombre de registres disponibles et




Thierry


P.S. : please don't tell me that P4 is a bad processor : I know it but I 
don't want to hear about it ! ;-P

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Note: You cannot compare 3.5 and 3.6 benchmark results as anti-aliasing
> changed a bit and a photons change makes those much faster.  As such, only
> the two 3.6 results you posted can be compared.

That obviously depends on the purpose of your comparison.  If you want 
to know if your scenes render faster with the new version the comparison 
of 3.5 and 3.6 benchmark results does make sense.  Of course you will 
have to keep in mind that the speed difference might mostly be due to 
the use of photons.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

gRRosminet wrote:
> 
> Could you try it with an optimized version of 3.5 ?

No time for that at the moment but i don't see any reason why processor 
specific optimization should work so much better there.

> for my pentium 4, an other explanation could be that the sse2 
> instruction are really better on floating point than sse.
> In your case, you limit yourself at using SSE instruction whereas Athlon 
> processors have an excelent fpu unit. you should replace -mfpmath=sse by 
> -mfpmath=sse,387

Does not change that much: 2197s

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> sse,387

> Cela double effectivement le nombre de registres disponibles et


> 

	And from the english man page:

sse,387
   Attempt to utilize both instruction sets at once.  This effec-
   tively double the amount of available registers and on chips
   with separate execution units for 387 and SSE the execution
   resources too.  Use this option with care, as it is still
   experimental, because the gcc register allocator does not model
   separate functional units well.

	:-)

	BTW, I realized that my statement about povray not being able
to use SSE/SSE2/similar instructions seems plain wrong, as I thought
those were (still) limited to single-precision arithmetics.
	My bad.
	So it's seems they could be actually quite valuable, and
I will consider them in the new configure script for 3.6.  Thanks
for pointing this out.

	- NC

Post a reply to this message