Linked by ebasconp on Fri 10th Jun 2011 22:22 UTC
Permalink for comment 477006
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2011-01-28
"Maybe GCC should have been able to optimize one of the len comparisons away, but really it's (deliberately?) stupid code imo and there will always be these cases where the compiler fails to grasp 'the bigger picture'."
Stupid code? Sure it was a trivial example, but that was deliberate. You'll have to take my word that GCC has the same shortcomings on more complex code from real programs.
Even if you want to blame the programmer here, a seasoned programmer will have no reasonable way of knowing if GCC has optimized the loop correctly without looking at the assembly output. Do we really want to go down the route of saying programmers need to check up on GCC's assembly output?
Should students be taught to avoid legal C constructs which give the GCC optimizer a hard time?
"Secondly it seems obvious that gcc doesn't choose to use vectorization since it has no idea of how many integers are to be added, and depending on that it could very well be less efficient to use vectorization"
I have no idea why GCC chose not to use SSE, but the result is still that the assembly language programmer would be able to beat it.
"(I seriously doubt ICC would do so either with this snippet)"
I wish someone could test this for us, Intel boasts very aggressive SSE optimization.