Hi folks. As a result of this CL: https://gem5-review.googlesource.com/c/public/gem5/+/40621
I've been looking at the size of the build directory, how long builds take, and partial linking, aka a potential step in our build where we link together some .o files into a larger .o, and then eventually link all those .o files into the final binary. You can get most of the details in the comment thread on that CL, but let me first talk about partial linking. I had originally implemented that because I was under the impression that the time it takes to link scales super linearly (which I think is actually true), and that by doing smaller links first, the scaling would work out where the total time spent linking would go down, especially since the smaller links could be done in parallel. Measurements have shown that that is *not* the case, and the intermediate object files take up a lot of space. Since there is really no benefit to partial linking, the implementation in gcc at least has been plagued with bugs, and it has a significant cost in disk space and build process complexity, I think we should get rid of it. Next, I looked at trying to reduce build directory size since, as Jason pointed out, if you have a slow disk (network storage?) then that can be a major bottleneck. One trick I implemented was to enable a feature of gcc and clang where they can compress the debug information throughout the build. This significantly reduces the build directory size (guestimate by 1/3-1/2?). My computer is fairly new, has a pretty fast NVME SSD, and tons of RAM for disk cache, and so the dominant factor for me seems to be the compression time, and while the disk footprint is GBs lower, the build time is still a good bit longer with this approach. If I was trying to shove a few GB less over a network then I think this might be reversed. I think this mechanism should be optional, especially since it's complexity cost is low on the scons side. Just a quick note about choice of linker. With the compression turned on, gnu's ld seems to be the fastest, with gold and lld (clang's linker) trailing by 10-20% total build time. This may change with the compression turned off, but (to my surprise), these alternative linkers don't seem to help, at least on my machine. Finally, *more than half* of the build directory's size is taken up by the python/_m5 directory where the pybind11 bindings for the params structs live. The opportunity for improvement here is huge, although somewhat out of our hands. It sounds like Ciro is working with upstream to hopefully give us some alternatives here, but this is definitely the next thing to look at as far as bringing down build directory size bloat. Gabe
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
