Hi Andreas, Are you volunteering to port all our scons scripts to makefiles? ;-)
Steve On Fri, Mar 2, 2012 at 12:26 AM, Andreas Hansson <[email protected]>wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
