 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17/12/2011 10:13, jhu nous fit lire :
> "jhu" <nomail@nomail> wrote:
>> Interesting...
>>
>> I was about to start over recompiling boost 1.47 and was in the middle of
>> reinstalling it before I realized icc wasn't compiling most of it. So I went
>> back and tried compiling povray 3.7 again, and now it works! I have absolutely
>> no idea how that happened.
>
> Hmm... icc binaries are slower than gcc binaries on this processor. Well, that
> really wasn't worthwhile, or at least until I get an Intel processor...
Well, any measurement would still be interesting (to me at least).
(could you give both time of gcc & icc for your processor ?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
> Le 17/12/2011 10:13, jhu nous fit lire :
> > "jhu" <nomail@nomail> wrote:
> >> Interesting...
> >>
> >> I was about to start over recompiling boost 1.47 and was in the middle of
> >> reinstalling it before I realized icc wasn't compiling most of it. So I went
> >> back and tried compiling povray 3.7 again, and now it works! I have absolutely
> >> no idea how that happened.
> >
> > Hmm... icc binaries are slower than gcc binaries on this processor. Well, that
> > really wasn't worthwhile, or at least until I get an Intel processor...
>
> Well, any measurement would still be interesting (to me at least).
> (could you give both time of gcc & icc for your processor ?)
Overall fastest time:
FreeBSD 8.2, gcc 4.6, -march=barcelona
Trace Time: 0 hours 3 minutes 10 seconds (190.466 seconds)
using 6 thread(s) with 1113.568 CPU-seconds total
Linux results:
Debian 7.0, gcc 4.6.1, -march=barcelona -mfpmath=both
Trace Time: 0 hours 3 minutes 17 seconds (197.996 seconds)
using 6 thread(s) with 1181.504 CPU-seconds total
Debian 7.0, icc 12.1, -march=pentium4 -mtune=core2 -msse3
Trace Time: 0 hours 3 minutes 24 seconds (204.107 seconds)
using 6 thread(s) with 1221.253 CPU-seconds total
For icc, I couldn't even use -march=core2, otherwise configure wouldn't work. It
must throw in instructions no supported by the AMD processor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jhu" wrote:
> Hmm... icc binaries are slower than gcc binaries on this processor. Well, that
> really wasn't worthwhile, or at least until I get an Intel processor...
I was also surprised that gcc POV-Ray (3.7 beta) binaries consistently
outperformed (by a little bit) those compiled with icc, even on a machine with
Intel processors and using an FPU-intensive 3D fractal object for the test
scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"waggy" <hon### [at] handbasketorg> wrote:
> I was also surprised that gcc POV-Ray (3.7 beta) binaries consistently
> outperformed (by a little bit) those compiled with icc, even on a machine with
> Intel processors and using an FPU-intensive 3D fractal object for the test
> scene.
Interesting. What kind of processor?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jhu" wrote:
> "waggy" wrote:
>
> > I was also surprised that gcc POV-Ray (3.7 beta) binaries consistently
> > outperformed (by a little bit) those compiled with icc, even on a machine with
> > Intel processors and using an FPU-intensive 3D fractal object for the test
> > scene.
>
> Interesting. What kind of processor?
Two-socket boards, Intel(R) Xeon(R) CPU E5345 @ 2.33GHz; no hyper-threading, so
eight cores total.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.12.2011 18:47, schrieb jhu:
> For icc, I couldn't even use -march=core2, otherwise configure wouldn't work. It
> must throw in instructions no supported by the AMD processor.
Not really surprising when you tell an Intel compiler to generate code
for a specific Intel architecture, is it? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
