Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
Thread beginning with comment 460204
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 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.