Silently overrides DEBUG and OPTIMISE options

Comments (11)

1. 

   Erik Schnetter

   • removed comment

   The option list describes machine properties. The decision whether to have a production, a debug, or a profiling build is independent of this, and these concepts should not be mixed.

   Initially, simfactory's option lists did not select debug/optimisation choices, but this made it impossible to use these option lists outside simfactory without modifying them. Therefore the simfactory option lists now do make a choice, which is the same as the default in Cactus -- namely optimise, enable OpenMP, disable debug statements, and do not profile. However, these settings are not meant to be modified in the option lists themselves.

   Instead, simfactory offers command line options (e.g. --debug, --profile, etc.) to choose these settings when a new configuration is created, and remembers these in a properties.ini file in the configuration. These also modify the default configuration name ("sim", "sim-debug", "sim-profile", etc.)

   This allows using the same option list for both debug and optimised builds. Previously, simfactory would contain multiple option lists for every machine, one for each build choice, which obviously lead to much duplication.

   • 2011-08-17T22:12:26+00:00
2. 

   Roland Haas

   • removed comment

   It might still be nice to offer the possibility to change the default settings for a given machine. Eg. I am very unlikely to every want a non-debug configuration to run on eg. my laptop (or my workstation for that matter) since all I ever do there is debugging. So not having debugging symbol because I forget a repetitive command line parameter would be annoying (eg. if gdb finally catches the segfault that I have been debugging for two days only to find that there are no source code line information).

   Python simfactory allows me to overwrite machine database entries in my local *.ini file, does it? Can I use this to change the default values or is this still overwritten by simfactories command line parameter.

   • 2011-08-17T22:40:34+00:00
3. 

   Barry Wardell reporter

   • removed comment

   In principal, I agree that having --debug, --optimise and --profile is a nice feature. However, I think the current implementation is worse than not having those options at all. The problems I have with it are:

   1. It '''silently''' overwrites the options inside the build command. 2. Because the default for --debug is False, if I don't give any --debug or --optimise options it silently changes my optionlist to DEBUG="no" and OPTIMISE="yes". 3. OPTIMISE is set based on the --debug option being False, so --optimise is essentially useless. 4. The only way to find out about the --debug, etc. options is to read the source code for sim-build. 5. It unconditionally overrides the CACHELINE_BYTES and CACHE_SIZE options, making it impossible to use any values other than those in the mdb for the machine. 6. As Roland mentioned, it is not possible to enable debug by default on a machine (correct me if I'm wrong on this).

   I think 1, 2 and 5 would be OK if the OptionLists were considered an internal implementation detail in SimFactory. In that case, it setting any of these overridden options in a SimFactory OptionList would be an error. This is not the case because, as you say, it is desirable to use a SimFactory OptionList without SimFactory (Why? Shouldn't you use the final optionlist after being processed by SimFactory?). Having these options in the OptionLists indicates that it is possible to change them. I think we should choose between these two, unless someone has a better suggestion?

   I think 3 is just wrong, but necessary because optimise and debug probably use conflicting settings. The attached patch is my suggested fix. It first checks the --optimize setting and then only if debug is enabled does it disable optimisation (with a warning).

   4 is a common annoyance with an obvious (but time consuming) solution.

   • 2011-08-18T01:46:15+00:00
4. 

   Roland Haas

   • removed comment

   Replying to [comment:3 barry.wardell]:

   SimFactory OptionList without SimFactory (Why? Shouldn't you use the final optionlist after being processed by SimFactory?). Having these options in

   Possibly because of people like me (and eg. Bruno Mundim from RIT), who are reluctant to use simfactory (because of its learning curve, its different directory layout which necessiates rewriting our postprocessing scripts, inertia, ...) :-)

   I think 3 is just wrong, but necessary because optimise and debug probably use conflicting settings.

   It is perfectly fine to have both -O3 and -g3 in CFLAGS. Both gcc and Intel will compile with these settings. In the Intel case attaching a debugger afterwards is often not very useful admittedly since icc seems to optimize the parameters passed to functions but with gcc it usually works fine. In fact I almost always compile with -g3 and -O3 so that any core dumps are useful.

   4 is a common annoyance with an obvious (but time consuming) solution.

   Preferrably these things would be documented :-). One issue that makes me reluctant to use simfactory is simply its size. If I start looking at its source code I have to dig several level down (or up) to go from where the error string (that I might see) was used to where the error was triggered. Clearly writing documentation (and keeping it up to date) is a large timesink with no obvious benefit to the author.

   • 2011-08-18T07:35:04+00:00
5. 

   Erik Schnetter

   • removed comment

   The option --debug is not about debugging symbols. As you say, there is almost never a reason to run without them, since the don't slow down the code and don't increase memory usage; the only reason to disable them would be if they cause an internal compiler error. What --debug does is enable additional debug statements in the code which perform self-tests and thus lead to a slower execution. Such tests could include checking for integer overflow, checking array bounds in Fortran, etc. What you instead may want to use in your case is --no-optimise, which disables optimisation (without adding these debug statements); this still lets you debug, but runs faster.

   Cactus outputs all its configuration settings when it configures, such as "Setting DEBUG to 'yes'". The options --debug, --optimise etc. should be documented, as they are prominent features.

   Yes, simfactory overwrites certain settings. Simfactory assumes that the MDB entries are correct, and thus propagates these settings, such as the cache size. The option list and the MDB really belong together and form a unit; it is an "implementation detail" that the option lists are stored in a different file and with a different format.

   In general, --debug and --optimise do not conflict. It is just that these don't make sense together, because --debug enables somewhat expensive additional self-checks, and --optimise tries to improve execution speed, so these goals conflict. In practice, many compilers segfault when these two are given together. To protect new users, the default for --optimise depends on the setting for --debug. It seems that the current implementation in simfactory doesn't quite do that, as it unconditionally sets --optimise when --debug is set. (--optimise isn't quite useless, because you can still specify --no-optimise.)

   Enabling --debug by default on a particular machine goes a bit against the idea of simfactory, which is to make things independent on particular machines. I envisioned that you have probably two configurations, one for debugging and one for production, and these configurations would both potentially exist on multiple machines. This allows you e.g. to take a debug session from your laptop and move on to a larger workstation if you run out of memory; for this to work reliably, the configuration settings (source tree, thorn list, etc.) need to be independent of the machine on which one is running. This is the working model that "sim sync" enables. That is, you would choose two configuration names (maybe "sim-debug" and "sim") for these two purposes, and sync/build these on several systems. To build the debug configuration, you say "sim build --debug", and "sim build" to build the production simulation; as described in <https://docs.einsteintoolkit.org/et-docs/Simulation_Factory_Advanced_Tutorial>.

   Your second patch is fine, please apply.

   • 2011-08-18T07:38:43+00:00
6. 

   Barry Wardell reporter

   • removed comment

   I think there is a bit of confusion about exactly what the problem is so I'll clear it up. The problem is not with the presence of debug symbols. As was mentioned, these are always included independent of debug and optimise being enabled. The problem is that by default SimFactory enables optimisation (-O2 on the machine I was using) so that many things are optimised away, making debugging much more difficult.

   The main thing I wanted to achieve was to disable optimisation (-O0). In principal this should be achieved using --no-optimise. The problem is that the current code ignores this option completely, making --optimise and --no-optimise completely useless. This is what my second patch fixes (I will commit this). However, even when this is fixed, the effect of --no-optimise is to not enable optimisation. Note that this is not the same as disabling optimisation as it relies on the compiler's default optimisation level, which I think is typically -O2. So the patch is only part of the solution and is essentially useless for solving my original problem.

   The real solution to my original problem would be to run with --debug. This explicitly disables optimisation, although as Erik mentioned this enables lots of extra debug code too. In my case this wouldn't be a problem - the bug is sufficiently difficult to track down that any extra information at the cost of speed is helpful.

   The conflict I was referring to between --debug and --optimise (and DEBUG=yes and OPTIMISE=yes) is that debug explicitly disables optimisation (-O0) while optimise explicitly enables it (-O2). I'm not sure what a compiler does when it is given both of these, but I'm sure it can't be a good idea. I think --debug does the correct thing in that it sets.

   I discovered that there is some documentation for --debug. It's available by running 'sim --help'. However, this documentation says "Build Cactus with debug symbols", which is wrong.

   The issues I mentioned so far can basically be considered to be bugs in SimFactory. The remaining problem is that optionlists are '''silently''' modified when building. Even worse, the fact that we set DEBUG and OPTIMISE in the optionlists suggests that it is possible to change these settings in the optionlist. This is what leads to confusing behaviour. Someone who is used to Cactus optionlists has no reason to expect DEBUG to have not been enabled and will be very confused by the result.

   Note that I don't have any problem with these things being only controlled by SimFactory's --debug, etc. In fact itt seems quite useful to me. The problem is having apparently two ways to do it, one of which people are used to and which doesn't work, without warning.

   • 2011-08-19T03:29:52+00:00
7. 

   Ian Hinder

   • removed comment

   However, even when this is fixed, the effect of --no-optimise is to not enable optimisation. Note that this is not the same as disabling optimisation as it relies on the compiler's default optimisation level, which I think is typically -O2.

   I added *_NO_OPTIMISE_FLAGS for precisely this reason (http://cactuscode.org/documentation/usersguide/UsersGuidech6.html#x9-19000B2.1). Cactus/make/configure.in sets these to default to -O0. So if you have OPTIMISE=no, you should get -O0. If this is not working, this is a bug in Cactus.

   • 2011-08-19T04:07:52+00:00
8. 

   Barry Wardell reporter

   • removed comment

   Replying to [comment:7 hinder]:

   > However, even when this is fixed, the effect of --no-optimise is to not enable optimisation. Note that this is not the same as disabling optimisation as it relies on the compiler's default optimisation level, which I think is typically -O2.

   I added *_NO_OPTIMISE_FLAGS for precisely this reason (http://cactuscode.org/documentation/usersguide/UsersGuidech6.html#x9-19000B2.1). Cactus/make/configure.in sets these to default to -O0. So if you have OPTIMISE=no, you should get -O0. If this is not working, this is a bug in Cactus.

   I hadn't realised this. In that case, --no-optimise would have been sufficient for my purpose. I have now committed the patch to make --optimise work as it should.

   • 2011-08-24T14:34:55+00:00
9. 

   Erik Schnetter

   • removed comment

   Has this issue been resolved?

   • 2012-06-15T15:25:00+00:00
10. 

    Roland Haas

    • edited description
    • changed status to resolved

    This has been applied as git hash 3c6c443 "Don't ignore --optimise and print a message because optimisation is being disabled for debug builds." of simfactory2

    A quick check confirms that indeed --no-optimise works as expected, setting OPTIMISE=no in config-info.

    • 2019-09-20T18:07:51+00:00
11. 

    Roland Haas

    • changed status to closed

    • 2019-09-20T18:08:00+00:00
12. Log in to comment