Suggestion for a new GCC compiler option
Dear Marc (and other Gambiteers): I just ran an experiment where I added every combination of 0, 1, and 2 options from the following list to the standard options for Gambit on x86-64 Linux and the development (4.5.0) gcc compiler, and measured the speed of the direct and inverse FFT transforms used in bignum multiplication: (define compiler-options '("-fthread-jumps" "-falign-functions" "-falign-jumps" "-falign-loops" "-falign-labels" "-fcaller-saves" "-fcrossjumping" "-fcse-follow-jumps" "-fcse-skip-blocks" "-fdelete-null-pointer-checks" "-fexpensive-optimizations" "-fgcse" "-fgcse-lm" "-fgcse-sm" "-fgcse-las" "-findirect-inlining" "-foptimize-sibling-calls" "-fpeephole2" "-fregmove" "-freorder-blocks" "-freorder-functions" "-frerun-cse-after-loop" "-fsched-interblock" "-fsched-spec" "-fschedule-insns" ;; "-fschedule-insns2" ; always on ;; "-fstrict-aliasing" ; always off ;; "-fstrict-overflow" ; always off, since -fwrapv is on "-ftree-switch-conversion" "-ftree-pre" "-finline-functions" "-funswitch-loops" "-fpredictive-commoning" "-fgcse-after-reload" "-ftree-vectorize")) What I found was that "-fschedule-insns" significantly improved the code, it ran in 1.264 seconds instead of 1.444 seconds. Note that - fschedule-insns2 is already added to the command line. (For what it's worth, the two options -ftree-pre and -fgcse generated the worst code, when both those options were added the ffts ran in 1.552 seconds.) This options is added at optimization level "-O2" on all architectures with "large" register sets, and I believe that even if it's specified on the command line, it is turned off for i386 (usual Intel x86) code (but this should be checked). So I'm asking that people might run the benchmark suite on various architectures after configuring gambit with, e.g., ./configure CC="gcc -fschedule-insns" --enable-single-host and compare the result to those without adding -fschedule-insns to the command line. I suspect that for both ppc(64) and x86-64 there could be noticeable speedup, but I'm not sure what will happen with arm or some of the other architectures that Gambit might run on. Brad
Afficher les réponses par date
Hallo, On 8/25/09, Bradley Lucier <lucier@math.purdue.edu> wrote:
So I'm asking that people might run the benchmark suite on various architectures after configuring gambit with, e.g.,
./configure CC="gcc -fschedule-insns" --enable-single-host
and compare the result to those without adding -fschedule-insns to the command line. I suspect that for both ppc(64) and x86-64 there could be noticeable speedup, but I'm not sure what will happen with arm or some of the other architectures that Gambit might run on.
I did not recompile Gambit-C but built a module of mine with and without this option. This module implements searching in game trees and uses only fixnum arithmetic. I did got better execution times with this option. This is on SPARC with GCC 2.95 (!!!) and: -Wno-unused -O1 -fschedule-insns -fschedule-insns2 -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -shared Cheers, -- -alex http://www.ventonegro.org/
On Tue, 2009-08-25 at 13:58 +0000, Alex Queiroz wrote:
On 8/25/09, Bradley Lucier <lucier@math.purdue.edu> wrote:
So I'm asking that people might run the benchmark suite on various architectures after configuring gambit with, e.g.,
./configure CC="gcc -fschedule-insns" --enable-single-host
and compare the result to those without adding -fschedule-insns to the command line. I suspect that for both ppc(64) and x86-64 there could be noticeable speedup, but I'm not sure what will happen with arm or some of the other architectures that Gambit might run on.
I did not recompile Gambit-C but built a module of mine with and without this option. This module implements searching in game trees and uses only fixnum arithmetic. I did got better execution times with this option. This is on SPARC with GCC 2.95 (!!!) and:
-Wno-unused -O1 -fschedule-insns -fschedule-insns2 -fno-strict-aliasing -fomit-frame-pointer -fPIC -fno-common -shared
Thank you for testing it. Unfortunately, trying to build 4.5.1 with these options results in a gcc error compiling os_base.c; I've reported this at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164 It seems to affect the 4.2, 4.3, 4.4, and current development series gcc. Not so good. So I guess we wait a bit. Brad
Hi Bradley 2009/8/25 Bradley Lucier <lucier@math.purdue.edu>:
I just ran an experiment where I added every combination of 0, 1, and 2 options from the following list to the standard options for Gambit on x86-64 Linux and the development (4.5.0) gcc compiler, and measured the speed of the direct and inverse FFT transforms used in bignum multiplication:
It just reminded me of something I can't remember seeing on this very list: acovea. It's genetic algorithms to find the best compiler options… It's almost at least 5 years old but since Gambit is a program that we compile often, it may be worth it. More informations at http://www.coyotegulch.com/products/acovea/index.html P! -- Français, English, 日本語, 한국어
participants (3)
-
Adrien Piérard -
Alex Queiroz -
Bradley Lucier