Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Marko Karppinen <[EMAIL PROTECTED]> writes: > At least the --fast-math part causes problems, seeing that PostgreSQL > actually checks for the __FAST_MATH__ macro to make sure that it isn't > turned on. There might be other problems with Apple's flags, but I > think that the __FAST_MATH__ check should be altered. Removing the check is not acceptable --- we spent far too much time fighting bug reports that turned out to trace to -ffast-math. See for example http://archives.postgresql.org/pgsql-bugs/2002-09/msg00169.php > As you know, setting --fast-math in GCC is the equivalent of setting > -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, > -ffinite-math-only and -fno-signaling-nans. I suspect that -funsafe-math-optimizations is the only one of those that really affects the datetime code, but I would be quite worried about the side-effects of any of them on the float8 arithmetic routines. Also I think the behavior of -ffast-math has changed over time; in the gcc 2.95.3 manual I see none of the above and only the description `-ffast-math' This option allows GCC to violate some ANSI or IEEE rules and/or specifications in the interest of optimizing code for speed. For example, it allows the compiler to assume arguments to the `sqrt' function are non-negative numbers and that no floating-point values are NaNs. Since we certainly do use NaNs, it would be very bad to allow -ffast-math in gcc 2.95. gcc 3.2 has some but not all of the sub-flags you list above, so apparently the behavior changed again as of gcc 3.3. This means that relaxing the check would require (a) finding out which of the sub-flags break our code and which don't; (b) finding out how the answer to (a) has varied with gcc release; and (c) finding out how we can test whether a given sub-flag is set --- are there #defines for each of them in gcc 3? This does not sound real practical to me... > This would allow people to use CFLAGS="-fast" on their G5s, beat some > Xeon speed records, and not worry about esoteric IEEE math standards. In the words of the sage, "I can make this code *arbitrarily* fast ... if it doesn't have to give the right answer." Those "esoteric" standards make the difference between printing 5:00:00 and printing 4:59:60. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Bruce Momjian writes: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. Looking at the template files, I see > these have no optimization set: > freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/template/freebsd.diff?r1=1.10&r2=1.11 -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
On 8.10.2003, at 21:31, Bruce Momjian wrote: Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: darwin Regarding Darwin optimizations, Apple has introduced a "-fast" flag in their GCC 3.3 version that they recommend when compiling code for their new G5 systems. Because of this, I foresee a lot of people defining CFLAGS="-fast" on their systems. This is problematic for PostgreSQL, however, since the -fast flag is the equivalent of: -O3 -falign-loops-max-skip=15 -falign-jumps-max-skip=15 -falign-loops=16 -falign-jumps=16 -falign-functions=16 -malign-natural -ffast-math -fstrict-aliasing -frelax-aliasing -fgcse-mem-alias -funroll-loops -floop-transpose -floop-to-memset -finline-floor -mcpu=G5 -mpowerpc64 -mpowerpc-gpopt -mtune=G5 -fsched-interblock -fload-after-store --param max-gcse-passes=3 -fno-gcse-sm -fgcse-loop-depth -funit-at-a-time -fcallgraph-inlining -fdisable-typechecking-for-spec At least the --fast-math part causes problems, seeing that PostgreSQL actually checks for the __FAST_MATH__ macro to make sure that it isn't turned on. There might be other problems with Apple's flags, but I think that the __FAST_MATH__ check should be altered. As you know, setting --fast-math in GCC is the equivalent of setting -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -ffinite-math-only and -fno-signaling-nans. What really should be done, I think, is adding the opposites of these flags (-fmath-errno, -fno-unsafe-math-optimizations, -ftrapping_math, -fno-finite-math-only and -fsignaling-nans) to the command line if __FAST_MATH__ is detected. This would allow people to use CFLAGS="-fast" on their G5s, beat some Xeon speed records, and not worry about esoteric IEEE math standards. What do you guys think? GCC sets __FAST_MATH__ even if you counter a -ffast-math with the negating flags above. This means that it is not currently possible to use the -fast flag when compiling PostgreSQL at all. Instead, you have to go through all the flags Apple is setting and only pass on those that don't break pg. mk ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Marko Karppinen writes: > GCC sets __FAST_MATH__ even if you counter a -ffast-math with the > negating flags above. This means that it is not currently possible to > use the -fast flag when compiling PostgreSQL at all. Instead, you have > to go through all the flags Apple is setting and only pass on those > that don't break pg. That sounds perfectly reasonable to me. Why should we develop elaborate workarounds for compiler flags that are known to create broken code? I also want to point out that I'm getting kind of tired of developing more and more workarounds for sloppy Apple engineering. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Done as you suggested. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, patch attached and applied. It centralizes the optimization > > defaults into configure.in, rather than having CFLAGS= in the template > > files. > > I think there's a problem here: > > > + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc > > + if test x"$CFLAGS" = x""; then > > + CFLAGS="-O" > > + fi > > if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then > > CFLAGS="$CFLAGS -g" > > fi > > since this will cause "configure --enable-debug" to default to selecting > CFLAGS="-O -g" for non-gcc compilers. On a lot of compilers that > combination does not work, and will generate tons of useless warnings. > I think it might be better to do > > if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then > CFLAGS="$CFLAGS -g" > + else > + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc > + if test x"$CFLAGS" = x""; then > + CFLAGS="-O" > + fi > fi > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, patch attached and applied. It centralizes the optimization > defaults into configure.in, rather than having CFLAGS= in the template > files. I think there's a problem here: > + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc > + if test x"$CFLAGS" = x""; then > + CFLAGS="-O" > + fi > if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then > CFLAGS="$CFLAGS -g" > fi since this will cause "configure --enable-debug" to default to selecting CFLAGS="-O -g" for non-gcc compilers. On a lot of compilers that combination does not work, and will generate tons of useless warnings. I think it might be better to do if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then CFLAGS="$CFLAGS -g" + else + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc + if test x"$CFLAGS" = x""; then + CFLAGS="-O" + fi fi regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
On Wed, Oct 08, 2003 at 02:31:29PM -0400, Bruce Momjian wrote: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. Looking at the template files, I see > these have no optimization set: I think gcc _used_ to generate bad code on SPARC if you set any optimisation. We tested it on Sol7 with gcc 2.95 more than a year ago, and tried various settings. -O2 worked, but other items were really bad. Some of them would pass regression but cause strange behaviour, random coredumps, &c. A little digging demonstrated that anything beyond -O2 just didn't work for gcc at the time. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: > >> Well, this is really embarassing. I can't imagine why we would not set > >> at least -O on all platforms. > > I believe that autoconf will automatically select -O2 (when CFLAGS isn't > already set) *if* it's chosen gcc. It won't select anything for vendor > ccs. > > > Can we get these optimizations enabled in time for the next 7.4 beta? > > I think it's too late in the beta cycle to add optimization flags except > for platforms we can get specific success results for. (Solaris is > probably okay for instance.) The risk of breaking things seems too > high. OK, patch attached and applied. It centralizes the optimization defaults into configure.in, rather than having CFLAGS= in the template files. It used -O2 for gcc (generated automatically by autoconf), and -O for non-gcc, unless the template overrides it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: configure === RCS file: /cvsroot/pgsql-server/configure,v retrieving revision 1.302 diff -c -c -r1.302 configure *** configure 3 Oct 2003 03:08:14 - 1.302 --- configure 9 Oct 2003 03:16:44 - *** *** 2393,2398 --- 2393,2402 if test "$ac_env_CFLAGS_set" = set; then CFLAGS=$ac_env_CFLAGS_value fi + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc + if test x"$CFLAGS" = x""; then + CFLAGS="-O" + fi if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then CFLAGS="$CFLAGS -g" fi Index: configure.in === RCS file: /cvsroot/pgsql-server/configure.in,v retrieving revision 1.293 diff -c -c -r1.293 configure.in *** configure.in3 Oct 2003 03:08:14 - 1.293 --- configure.in9 Oct 2003 03:16:46 - *** *** 238,243 --- 238,247 if test "$ac_env_CFLAGS_set" = set; then CFLAGS=$ac_env_CFLAGS_value fi + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc + if test x"$CFLAGS" = x""; then + CFLAGS="-O" + fi if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then CFLAGS="$CFLAGS -g" fi Index: src/template/beos === RCS file: /cvsroot/pgsql-server/src/template/beos,v retrieving revision 1.6 diff -c -c -r1.6 beos *** src/template/beos 21 Oct 2000 22:36:13 - 1.6 --- src/template/beos 9 Oct 2003 03:16:51 - *** *** 1 - CFLAGS='-O2' --- 0 Index: src/template/bsdi === RCS file: /cvsroot/pgsql-server/src/template/bsdi,v retrieving revision 1.16 diff -c -c -r1.16 bsdi *** src/template/bsdi 27 Sep 2003 16:24:44 - 1.16 --- src/template/bsdi 9 Oct 2003 03:16:51 - *** *** 5,13 esac case $host_os in ! bsdi2.0 | bsdi2.1 | bsdi3*) ! CC=gcc2 ! ;; esac THREAD_SUPPORT=yes --- 5,11 esac case $host_os in ! bsdi2.0 | bsdi2.1 | bsdi3*) CC=gcc2;; esac THREAD_SUPPORT=yes Index: src/template/cygwin === RCS file: /cvsroot/pgsql-server/src/template/cygwin,v retrieving revision 1.2 diff -c -c -r1.2 cygwin *** src/template/cygwin 9 Oct 2003 02:37:09 - 1.2 --- src/template/cygwin 9 Oct 2003 03:16:51 - *** *** 1,2 - CFLAGS='-O2' SRCH_LIB='/usr/local/lib' --- 1 Index: src/template/dgux === RCS file: /cvsroot/pgsql-server/src/template/dgux,v retrieving revision 1.10 diff -c -c -r1.10 dgux *** src/template/dgux 21 Oct 2000 22:36:13 - 1.10 --- src/template/dgux 9 Oct 2003 03:16:51 - *** *** 1 - CFLAGS= --- 0 Index: src/template/freebsd === RCS file: /cvsroot/pgsql-server/src/template/freebsd,v retrieving revision 1.23 diff -c -c -r1.23 freebsd *** src/template/freebsd27 Sep 2003 16:24:44 - 1.23 --- src/template/freebsd9 Oct 2003 03:16:51 - *** *** 1,17 - CFLAGS='-pipe' - case $host_cpu in ! alpha*) CFLAGS="$CFLAGS -O" ;; esac THREAD_SUPPORT=yes NEED_REENTRANT_FUNCS=yes THREAD_CPPFLAGS="-D_THREAD_SAFE" case $host_os in ! freebsd2*|freebsd3*|freebsd4*) ! THREAD_LIBS="-pthread" ! ;; ! *) ! THREAD_LIBS="-lc_r" ! ;; esac --- 1,11 case $host_cpu in ! alpha*) CFLAGS="-
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/template/freebsd.diff?r1=1.10&r2=1.11 When I used to build pgsql on freebsd/alpha, I would get heaps of GCC warnings saying 'optimisations for the alpha are broken'. I can't remember if that meant anything more than just -O or not though. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, this is really embarassing. I can't imagine why we would not set > > at least -O on all platforms. Looking at the template files, I see > > these have no optimization set: > > > freebsd (non-alpha) > > I'm wondering what that had in mind: > > http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/template/freebsd.diff?r1=1.10&r2=1.11 I was wondering that myself. I think the idea was that we already do -O2 in configure if it is gcc, so why do it in the template files. What is killing us is the CFLAGS= lines in the configuration files. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
On Wed, 8 Oct 2003, Neil Conway wrote: > ISTM the most legitimate reason for not enabling compilater > optimizations on a given compiler/OS/architecture combination is might > cause compiler errors / bad code generation. > > Can we get these optimizations enabled in time for the next 7.4 beta? It > might also be good to add an item in the release notes about it. > > -Neil > I just ran make check for sun with gcc -O2 and suncc -fast and both passed. We'll need other arguments to suncc to supress some warnings, etc. (-fast generates a warning for every file compiled telling you it will only run on ultrasparc machines) -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
