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,
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!