icpc compiler

[Daniel Shawul]

What is wrong with the intel compiler ? First it generates a lot of useless warnings that I had to turn off to keep it quiet. And then one of my files took about 40 minutes to compile. With gcc it compiles in a matter of seconds! I thought something was broken in my code when it got stuck but it actually finished it when I came back from lunch. Is this expected behaviour ?

[jdart]

Sure sounds like a bug. I think it's slower than gcc but it should not be that much slower.

--Jon

[Daniel Shawul]

I may have a bug because turning of section of code from that file makes the compilation go faster. But note that I have been using the code in other computers for some time and also even the one I am using right now did ok with that compile which finished after 40 minutes. Shouldn't I get a warning/error if I have a bug? I will try reducing optimization level next. It gets stuck in a message passing section of the code.

Code: Select all

../../field/field.h(886): remark #981: operands are evaluated in unspecified order
                        MP::irecieve(&recvbuf[b.buffer_index],b.f->size(),b.to,MP::FIELD,&request[rcount]);
                        ^
          detected during:
            instantiation of "void exchange_ghost(T *) [with T=Tensor]" at line 835
            instantiation of "void updateExplicitBCs&#40;const MeshField<T, E> &, bool, bool&#41; &#91;with T=Tensor, E=CELL&#93;" at line 259 of "../../solvers/solve.cpp"
            instantiation of "void SolveT&#40;const MeshMatrix<T> &) &#91;with type=Tensor&#93;" at line 278 of "../../solvers/solve.cpp"

[jdart]

I meant, possibly the icc optimizer has a bug. I know they have fixed things in the past that caused bad compilation performance.

[Daniel Shawul]

That could be the case indeed. I have tracked down what is making it take so long to compile. The culprit is a section of code where icpc does vector optimization on loops and I have some no so elegant code with a "goto" and other tests there. Turning that off makes it compile quick. But I am not so sure of it yet ...

[Gian-Carlo Pascutto]

It (still) miscompiles Deep Sjeng when multi-file IPO is enabled.

And it crashes instantly when compiling the cluster version. Not even in my code, it seems to break on Boost::Thread or Boost::Asio.

I'm sure it's great on benchmarks, though.

[Daniel Shawul]

It (still) miscompiles Deep Sjeng when multi-file IPO is enabled.

And it crashes instantly when compiling the cluster version. Not even in my code, it seems to break on Boost::Thread or Boost::Asio.

I'm sure it's great on benchmarks, though.

That is good to know. I was not able to find any obvious fault in my code so far. I didn't even want to use it if the wrapper compiler mpiCC didn't force me to use it. I guess if I really don't have any bugs, I will have to find a way to replace icpc compiler with gcc.

[jdart]

Icc works fine for me - in fact it is able to compile Arasan with PGO, which gcc has never been able to do. But I have found that runtime performance is no better than gcc 4.6 with -O3. YMMV though.

--jon

[Gian-Carlo Pascutto]

Thanks. I'm tempted to try to get GCC to make a 64-bit Windows compile then.

I also reported the bugs to Intel, wonder if anything will come of that.

[rvida]

Icc works fine for me - in fact it is able to compile Arasan with PGO, which gcc has never been able to do. But I have found that runtime performance is no better than gcc 4.6 with -O3. YMMV though.

Same conclusion with Critter:

ICC 32 bit = 1127 knps
GCC 32 bit = 1110 knps

ICC 64 bit = 1763 knps
GCC 64bit = 1777 knps