Marc, Could you put together a patch that addresses these issues and post it to review board?
Thanks, Ali On Mar 2, 2012, at 1:03 AM, Steve Reinhardt wrote: > Thanks Marc, this is great information. > >> question: Should NO_HTML default to true instead of False? >> > > Seems reasonable to me. > > >>> question: Is it necessary to call makeEnv for all 4 binaries when a >> single >>> compile only generates a single binary? >> > > I don't see why. Note that it is possible for a single scons invocation to > generate multiple binaries, e.g., you can say: > scons build/ALPHA/gem5.debug build/ALPHA/gem5.opt > (and the regressions certainly take advantage of this, as do I > occasionally). > So we do sometimes need to make multiple makeEnv calls, but we should be > able to figure out which ones are needed and only do the ones that are > necessary for that invocation. > > >>> question: Should the decider be configured to default to MD5-timestamp? >> >> Should the implicit-cache option be the default behavior? >> > > These both seem reasonable to me too. I'm interested to see if there are > any other objections. The scons man page mentions the caveats of these > optimizations, but they seem pretty minor: > > Decider(*function*)*env*.Decider(*function*)Specifies that all up-to-date > decisions for targets built through this construction environment will be > handled by the specified *function*. The *function* can be one of the > following strings that specify the type of decision function to be > performed: > > *[...]**MD5-timestamp*Specifies that a target shall be considered out of > date and rebuilt if the dependency's content has changed sine the last time > the target was built, except that dependencies with a timestamp that > matches the last time the target was rebuilt will be assumed to be > up-to-date and *not* rebuilt. This provides behavior very similar to the * > MD5* behavior of always checksumming file contents, with an optimization of > not checking the contents of files whose timestamps haven't changed. The > drawback is that SCons will *not* detect if a file's content has changed > but its timestamp is the same, as might happen in an automated script that > runs a build, updates a file, and runs the build again, all within a single > second. > > --implicit-cacheCache implicit dependencies. This causes *scons* to use the > implicit (scanned) dependencies from the last time it was run instead of > scanning the files for implicit dependencies. This can significantly speed > up SCons, but with the following limitations:*scons* will not detect > changes to implicit dependency search paths (e.g. *CPPPATH*, *LIBPATH*) > that would ordinarily cause different versions of same-named files to be > used.*scons* will miss changes in the implicit dependencies in cases where > a new implicit dependency is added earlier in the implicit dependency > search path (e.g. *CPPPATH*,*LIBPATH*) than a current implicit dependency > with the same name. > >>> question: Can anything else be done to speed up the gem5 build? >> > > I don't know, but this seems like a good start... thanks again! > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
