Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
Permalink for comment 460204
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
More News »
Sponsored Links



Member since:
2011-01-28
"What could the reason be then, why does an open-source compiler fare so poorly against a commercial one?"
Without looking at the assembly, it's just speculation on my part.
I've read that GCC is rather ignorant of code & data locality and cpu cache lines; therefor binary code placement is arbitrary rather than optimal. In theory, this could make a huge difference.
Function inlining is usually good, but only until the cache lines are full, further inlining is detrimental. This may be a weakness for GCC.
The compilers inject prefetch hints into the code, maybe GCC predicts the branches less accurately at compile time?
GLIBC is notoriously bloated. I don't know if intel links in it's own streamlined c library? That might make a difference.
As for compilation time, ICC has an "unfair" advantage. If GCC had been compiled under ICC, then GCC itself might perform much better - though I'm not sure the GCC folks would want to admit to that.