POV-Ray : Newsgroups : povray.general : It's that time again: icc vs. gcc Server Time
29 Jul 2024 16:33:32 EDT (-0400)
  It's that time again: icc vs. gcc (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: It's that time again: icc vs. gcc
Date: 25 Jun 2011 18:51:51
Message: <4e066687$1@news.povray.org>
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

From: Warp
Subject: Re: It's that time again: icc vs. gcc
Date: 26 Jun 2011 07:12:23
Message: <4e071417@news.povray.org>
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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 27 Jun 2011 00:20:01
Message: <web.4e0804a4be614b62dcff099d0@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Am 24.06.2011 07:13, schrieb jhu:
> > SharkD<pos### [at] gmailcom>  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

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>
On 27.06.11 06:18, jhu wrote:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 24.06.2011 07:13, schrieb jhu:
>>> SharkD<pos### [at] gmailcom>   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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 27 Jun 2011 11:40:00
Message: <web.4e08a3e3be614b62f4bdd9650@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> 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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 28 Jun 2011 18:55:01
Message: <web.4e0a5b24be614b62f4bdd9650@news.povray.org>
Warp <war### [at] tagpovrayorg> 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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 29 Jun 2011 02:55:01
Message: <web.4e0acb45be614b62f4bdd9650@news.povray.org>
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

From: Warp
Subject: Re: It's that time again: icc vs. gcc
Date: 29 Jun 2011 15:45:02
Message: <4e0b80be@news.povray.org>
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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 29 Jun 2011 20:15:01
Message: <web.4e0bbfaabe614b62f4bdd9650@news.povray.org>
Warp <war### [at] tagpovrayorg> 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

From: jhu
Subject: Re: It's that time again: icc vs. gcc
Date: 1 Jul 2011 20:20:01
Message: <web.4e0e6304be614b62f4bdd9650@news.povray.org>
Thorsten Froehlich <tho### [at] trfde> 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

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.