![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 25.06.2011 19:15, schrieb jhu:
>> As for running, I'd be most interested in behaviour regarding photons;
>> I've been experiencing problems there with icpc-compiled POV-Ray 3.7
>> ever since, but haven't managed to get any feedback about whether it's a
>> freak problem limited to my machine or a general issue.
>
> Okay. Do you want benchmark with resulting image or have me use it in general?
Thanks for your help. No benchmark needed, please just do some runs of
photons scenes (e.g. scenes/advanced/balcony and
scenes/advanced/optics), keeping your eyes peeled for sporadic (yet from
my experience frequent) crashes in particular.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
jhu <nomail@nomail> wrote:
> These are the fastest times I could muster for each compiler:
> gcc 4.4.5, -march=barcelona, -ffast-math -unroll-loops
> Total Time: 0 hours 13 minutes 40 seconds (820 seconds)
> Povray official binary
> Total Time: 0 hours 23 minutes 32 seconds (1412 seconds)
If you compile a generic 386 binary, but otherwise use the optimizations,
is there any improvement over the official binary?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> wrote:
> Am 24.06.2011 07:13, schrieb jhu:
> > SharkD<pos### [at] gmail com> wrote:
> >> Wow. And isn't the 3.7 binary a bit slower than 3.6?
> >>
> >> --
> >> http://isometricland.com
> >
> > I've not tested 3.7. I like doing other things on my computer while running
> > these things, so I used 3.6
>
> As you obviously have the icpc compiler suit installed, could you do me
> a favor and try compiling & running 3.7 nonetheless, and give some feedback?
>
> As for running, I'd be most interested in behaviour regarding photons;
> I've been experiencing problems there with icpc-compiled POV-Ray 3.7
> ever since, but haven't managed to get any feedback about whether it's a
> freak problem limited to my machine or a general issue.
Compiling with icc (icpc) gives an error (no error with gcc though):
make[3]: Entering directory `/home/jhu/temp/povray-3.7.0.RC3/source/backend'
icpc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source
-I../../source/base -I../../unix -I../../vfe -I../../vfe/unix -pthread
-I/usr/local/include -pipe -Wno-multichar -Wno-write-strings -s -O3 -ip -xHost
-pthread -MT fnpovfpu.o -MD -MP -MF .deps/fnpovfpu.Tpo -c -o fnpovfpu.o `test -f
'vm/fnpovfpu.cpp' || echo './'`vm/fnpovfpu.cpp
.../../source/base/image/colourspace.h(445): warning #1125: overloaded function
"pov_base::GammaCurve::IsNeutral" is hidden by
"pov_base::PowerLawGammaCurve::IsNeutral" -- virtual function override intended?
static bool IsNeutral(float gamma);
^
.../../source/base/image/colourspace.h(464): warning #1125: overloaded function
"pov_base::GammaCurve::IsNeutral" is hidden by
"pov_base::ScaledGammaCurve::IsNeutral" -- virtual function override intended?
static bool IsNeutral(float factor);
^
/usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is
undefined
return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL,
^
detected during:
instantiation of
"__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type
std::fpclassify(_Tp) [with _Tp=float]" at line 65 of
"/usr/local/include/boost/functional/hash/detail/hash_float.hpp"
instantiation of "size_t={unsigned long}
boost::hash_detail::float_hash_value(T) [with T=float]" at line 299 of
"/usr/local/include/boost/functional/hash/hash.hpp"
/usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is
undefined
return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL,
^
detected during:
instantiation of
"__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type
std::fpclassify(_Tp) [with _Tp=long double]" at line 65 of
"/usr/local/include/boost/functional/hash/detail/hash_float.hpp"
instantiation of "size_t={unsigned long}
boost::hash_detail::float_hash_value(T) [with T=long double]" at line 309 of
"/usr/local/include/boost/functional/hash/hash.hpp"
compilation aborted for vm/fnpovfpu.cpp (code 2)
make[3]: *** [fnpovfpu.o] Error 2
make[3]: Leaving directory `/home/jhu/temp/povray-3.7.0.RC3/source/backend'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jhu/temp/povray-3.7.0.RC3/source'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jhu/temp/povray-3.7.0.RC3'
make: *** [all] Error 2
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: It's that time again: icc vs. gcc
Date: 27 Jun 2011 11:21:37
Message: <4e08a001@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 27.06.11 06:18, jhu wrote:
> clipka<ano### [at] anonymous org> wrote:
>> Am 24.06.2011 07:13, schrieb jhu:
>>> SharkD<pos### [at] gmail com> wrote:
>>>> Wow. And isn't the 3.7 binary a bit slower than 3.6?
>>>>
>>>> --
>>>> http://isometricland.com
>>>
>>> I've not tested 3.7. I like doing other things on my computer while running
>>> these things, so I used 3.6
>>
>> As you obviously have the icpc compiler suit installed, could you do me
>> a favor and try compiling& running 3.7 nonetheless, and give some feedback?
>>
>> As for running, I'd be most interested in behaviour regarding photons;
>> I've been experiencing problems there with icpc-compiled POV-Ray 3.7
>> ever since, but haven't managed to get any feedback about whether it's a
>> freak problem limited to my machine or a general issue.
>
> Compiling with icc (icpc) gives an error (no error with gcc though):
>
> make[3]: Entering directory `/home/jhu/temp/povray-3.7.0.RC3/source/backend'
> icpc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source
> -I../../source/base -I../../unix -I../../vfe -I../../vfe/unix -pthread
> -I/usr/local/include -pipe -Wno-multichar -Wno-write-strings -s -O3 -ip -xHost
> -pthread -MT fnpovfpu.o -MD -MP -MF .deps/fnpovfpu.Tpo -c -o fnpovfpu.o `test -f
> 'vm/fnpovfpu.cpp' || echo './'`vm/fnpovfpu.cpp
> .../../source/base/image/colourspace.h(445): warning #1125: overloaded function
> "pov_base::GammaCurve::IsNeutral" is hidden by
> "pov_base::PowerLawGammaCurve::IsNeutral" -- virtual function override intended?
> static bool IsNeutral(float gamma);
> ^
>
> .../../source/base/image/colourspace.h(464): warning #1125: overloaded function
> "pov_base::GammaCurve::IsNeutral" is hidden by
> "pov_base::ScaledGammaCurve::IsNeutral" -- virtual function override intended?
> static bool IsNeutral(float factor);
> ^
>
> /usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is
> undefined
> return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL,
> ^
> detected during:
> instantiation of
> "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type
> std::fpclassify(_Tp) [with _Tp=float]" at line 65 of
> "/usr/local/include/boost/functional/hash/detail/hash_float.hpp"
> instantiation of "size_t={unsigned long}
> boost::hash_detail::float_hash_value(T) [with T=float]" at line 299 of
> "/usr/local/include/boost/functional/hash/hash.hpp"
>
> /usr/include/c++/4.4.5/cmath(500): error: identifier "__builtin_fpclassify" is
> undefined
> return __builtin_fpclassify(FP_NAN, FP_INFINITE, FP_NORMAL,
> ^
> detected during:
> instantiation of
> "__gnu_cxx::__enable_if<std::__is_arithmetic<_Tp>::__value, int>::__type
> std::fpclassify(_Tp) [with _Tp=long double]" at line 65 of
> "/usr/local/include/boost/functional/hash/detail/hash_float.hpp"
> instantiation of "size_t={unsigned long}
> boost::hash_detail::float_hash_value(T) [with T=long double]" at line 309 of
> "/usr/local/include/boost/functional/hash/hash.hpp"
Did you rebuild boost with icc first? This looks like boost is configured
for gcc, while the compiler is of course icc.
Thorsten
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
> Did you rebuild boost with icc first? This looks like boost is configured
> for gcc, while the compiler is of course icc.
>
> Thorsten
Ok, guess I'll try that next.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> If you compile a generic 386 binary, but otherwise use the optimizations,
> is there any improvement over the official binary?
>
> --
> - Warp
I'll have to test that one more thoroughly later. I've compiled a few i386
binaries (with -march=i386) on my netbook running Ubuntu, but I'm not entirely
sure the compiler isn't also throwing in SSE, SSE2, SSE3, and SSSE3 instructions
in there.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ok, here are some more benchmarks, compiled in a 32-bit Ubuntu 10 environment,
then run on 64-bit Debian 6.0 environment on the Athlon II x4. I went into all
of the Makefiles and edited out any references to any other -march and
-msse/-msse2 statements.
gcc 4.4.5, -march=i386 -ffast-math -funroll-loops
Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
Photon Time: 0 hours 0 minutes 24 seconds (24 seconds)
Render Time: 0 hours 18 minutes 57 seconds (1137 seconds)
Total Time: 0 hours 19 minutes 22 seconds (1162 seconds)
gcc 4.4.5, -march=i386
Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
Photon Time: 0 hours 0 minutes 26 seconds (26 seconds)
Render Time: 0 hours 20 minutes 44 seconds (1244 seconds)
Total Time: 0 hours 21 minutes 11 seconds (1271 seconds)
Povray official binary
Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
Photon Time: 0 hours 0 minutes 28 seconds (28 seconds)
Render Time: 0 hours 23 minutes 3 seconds (1383 seconds)
Total Time: 0 hours 23 minutes 32 seconds (1412 seconds)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
jhu <nomail@nomail> wrote:
> gcc 4.4.5, -march=i386 -ffast-math -funroll-loops
> Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
> Photon Time: 0 hours 0 minutes 24 seconds (24 seconds)
> Render Time: 0 hours 18 minutes 57 seconds (1137 seconds)
> Total Time: 0 hours 19 minutes 22 seconds (1162 seconds)
> gcc 4.4.5, -march=i386
> Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
> Photon Time: 0 hours 0 minutes 26 seconds (26 seconds)
> Render Time: 0 hours 20 minutes 44 seconds (1244 seconds)
> Total Time: 0 hours 21 minutes 11 seconds (1271 seconds)
> Povray official binary
> Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
> Photon Time: 0 hours 0 minutes 28 seconds (28 seconds)
> Render Time: 0 hours 23 minutes 3 seconds (1383 seconds)
> Total Time: 0 hours 23 minutes 32 seconds (1412 seconds)
Perhaps the official binary should be updated to a more optimized version.
(Perhaps the reason for the difference is that the official binary has been
compiled with an older version of gcc, and the newer versions optimize
better, even for the 386.)
It could also be considered if the official binary distribution could
offer several binaries, compiled for different CPUs. For example, there
could be an official binary that works even on a 386, one that requires
at least an SSE-supporting Pentium, and a third that requires a x86-64 CPU.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> wrote:
> Perhaps the official binary should be updated to a more optimized version.
> (Perhaps the reason for the difference is that the official binary has been
> compiled with an older version of gcc, and the newer versions optimize
> better, even for the 386.)
>
> It could also be considered if the official binary distribution could
> offer several binaries, compiled for different CPUs. For example, there
> could be an official binary that works even on a 386, one that requires
> at least an SSE-supporting Pentium, and a third that requires a x86-64 CPU.
>
> --
> - Warp
I was thinking the same thing about having different binaries for different
CPUs. OTOH, compiling 3.6 from source on Unix-like systems isn't really that
difficult. Perhaps we could also make a list of compiler options that produce
the fastest binary.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
> Did you rebuild boost with icc first? This looks like boost is configured
> for gcc, while the compiler is of course icc.
>
> Thorsten
Actually, it turns out it's a bug in icc 11.1's gcc compatibility. Intel has
since updated it to remove the bug, but I haven't gotten around to installing it
yet.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |