You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quoting from my forum posting:
http://ai-contest.com/forum/viewtopic.php?f=18&t=700&start=0
It's also worth noting that -funroll-loops is an undesirable optimization for
two reasons:
* GCC has a wickedly advanced loop optimizer. It will unroll loops when it's
able to determine that faster or smaller code will be produced; it rarely
misses a chance since 4.3. Forcing loop unrolling basically guarantees that
slower code will be generated, probably in the fast inner loops we're all
counting on to be zippy.
* In the context of C90, without the use of the 'restrict' keyword, GCC will
not be able to determine that the iterations of loops over pointers to objects
are distinct, that the loop can be sanely unrolled. GCC will, as a result,
produce unrolled loops with large amounts of load/store instructions where none
would be needed if 'restrict' were judiciously used.
More sane optimization flags would be -fwhopr if the contest machine is using
4.5 and, certainly, -mtune=native. Depending on the contest CPU cache sizes,
-Os is a better fit than -O3 for object file compilation. The link -O2 combined
with -fwhopr would be perfectly reasonable.
I will shortly submit a patch to fix this issue.
Original issue reported on code.google.com by brian%tr...@gtempaccount.com on 29 Sep 2010 at 12:19
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
brian%tr...@gtempaccount.com
on 29 Sep 2010 at 12:19The text was updated successfully, but these errors were encountered: