One thing to try maybe is Intel CC. Perhaps their linker is faster? or do they use ld? You're probably running into a I/O limitation on your laptop not a CPU problem.
Ali On Jun 9, 2008, at 2:02 PM, nathan binkert wrote: > Yeah, that makes sense. We don't really have subsystems with local > symbols. That said, is it faster to incremental link strip and then > finish the link? I'm just curious if there are any symbols that we > can automatically strip. > > Then again, I build debug most of the time and you wouldn't want to > strip that, so... > > Nate > > On Mon, Jun 9, 2008 at 10:50 AM, Ali Saidi <[EMAIL PROTECTED]> wrote: >> I've done some reading online and it doesn't appear that incremental >> linking will cut down on the link time much at all. Doing it in >> smaller chunks doesn't help if all the symbols end up being exported >> at the end. The two ways to speed it up are to (a) not include any >> debugging information (remove the -g flag) or (b) build various >> pieces as shared libraries and link them dynamically at runtime. (a) >> isn't probably useful for your purposes and (b) increases the >> difficultly of debugging the code substantially as well as requires >> various pieces of the simulator to be completely independent. Either >> way I doubt it's worth the effort. >> >> Ali >> >> >> On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: >> >>> Few comments. >>> 1) I like this idea. >>> 2) Linux explicitly exports symbols outside of an object. This >>> seems >>> like it would be a pain. >>> 3) Anonymous namespaces aren't obscure. Maybe there's a way to >>> remove >>> these with strip. >>> 4) It shouldn't be hard to get SCons to support this sort of thing. >>> >>> Nate >>> >>> On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black <[EMAIL PROTECTED]> >>> wrote: >>>> Is there some way we can make m5 link incrementally, or in >>>> other words >>>> link subsystems together independently and then as units with each >>>> other? The final linking step seems to take a long time with ld at >>>> 100% >>>> cpu usage. That makes sense when you consider it's linking a screen >>>> and >>>> a half of object files. Breaking things into smaller ".o"s that >>>> then get >>>> linked would help because a lot of the symbols would get resolved >>>> locally and wouldn't cause a search over the all the other object >>>> modules. Even better would be to restrict the set of symbols that >>>> get >>>> linked between subsystems so the search is over a smaller space as >>>> well, >>>> as apposed to just being done fewer times, but I don't know how we >>>> could >>>> do that without specializing to one set of tools or using obscure >>>> features like anonymous namespaces. Anonymous namespaces might not >>>> even >>>> help because they hide symbols by putting them in generated unique >>>> namespaces, but the linker probably doesn't know that and would go >>>> through them all the time anyway. This isn't broken perse, but >>>> since you >>>> have to link every time you build and I'm on a slower machine it's >>>> very >>>> annoying. >>>> >>>> Gabe >>>> _______________________________________________ >>>> m5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
