On Fri, Jun 06, 2008 at 09:24:24AM +0200, Fabian Groffen wrote:
On 06-06-2008 09:12:39 +0200, Stefan Manegold wrote:
It would make sense to me if the nightly tarballs, which include the superballs all compile with strict, optimize and assert being *disabled* by default, for a sane code distribution.
Please note that for some compiler issues to catch, one has to use -O2 (--enable optimize?), however doing that makes the binary hard to debug, which results in a natural inconvenience here...
Even without --enable-optimize the configure default (not our choice, but that of the makers of configure!) (at least for gcc, not the most rare compiler) is "-g -O2", hence, the default does not omit "-O2".
"-g -O2" is an autoconf default, used if you don't set CFLAGS, which is pretty much sane for a normal installation. If you want more, because you understand more (risk assessment, etc.) you can tweak your CFLAGS to suit your needs, e.g. "-march=native -pipe -O3" and way beyond that. That's how the autotools world works.
I know and agree. In addition, for know compilers and platforms, we provide an "agressive" setting that is tested and found working not only fast(?) but also correctly(!) via the --enable-optimize switch such that uses do not have to spend their time on finding these settings themselves, but still benefit from their gains in performance.
Moreover, there is the issue of performance experiments/comparisons in case the default is not --enable-optimize .
There is a difference between "user distribution" and "micro-detail-performance-experiment-hackery usage". The latter should be setup by someone who knows what he/she is actually doing.
Well, my view and intension has been and still is a bit more detailed, consisting of even three scenarios: 1) "developers debugging 'distribution'" This is the (unpackaged?) CVS code base without --enable-optimize, but with --enable-strict and --enable-assert as default. Maybe, we [cs]ould even consider making --endable-debug the default to get rid of the "-O2" with gcc to improve gdb-debuggability. 2) "users production distribution" Ready-to-use for users with all (save) perfoamce benefits, but no (default) need to debug the code line by line (let's face it: which *user* does understand out code in details?). This is (a) the source tarball(s) with defaults --disable-strict --disable-assert --disable-debug --enable-optimize (I don't consider --enable-optimize a "hack" but a well-tested setting for know compiles and scenarios, and hence want users to benefit from it) and (b) the binary packages compiled with the same defaults. "Power users" that need to debug the code should know how to use configure with explicit --disable-optimize --enable-debug --enable-assert. 3) "Performance geeks" Take any of the above defaults and use the available knobs (configre switches, CFLAGS settings, etc.) to tune to your desire/needs. We might want to look into our configure files, though, to check whether the way how we modify the CFALGS (overwrite, append, prepend) is convenient and/or correct or could be imporoved for both purposes. Suggestions and help are welcome. Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |