On the question of how to reduce the build time...switch to gmake. I look forward to the benchmark results :)
http://www.electric-cloud.com/blog/2010/08/11/the-last-word-on-scons-performance/ Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: 02 March 2012 07:04 To: gem5 Developer List Cc: [email protected] Subject: Re: [gem5-dev] reducing build times 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 -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
