On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote: > Kenneth Zadeck wrote: > >> Even if we decide that we are going to process all of the functions in >> one file at one time, we still have to have access to the functions that >> are going to be inlined into the function being compiled. Getting at >> those functions that are going to be inlined is where the double the i/o >> arguement comes from. > > I understand -- but it's natural to expect that those functions will > be clumped together. In a gigantic program, I expect there are going > to be clumps of tightly connected object files, with relatively few > connections between the clumps. So, you're likely to get good cache > behavior for any per-object-file specific data that you need to access. > I just do not know. I assume that you are right, that there is some clumping. But I am just no sure.
I just want to point out that this argument (okay cache locality) was used as a reason the massive amount of open/seek/close behavior by Subversion's FSFS filesystem is "a-ok". It turns out not to be in practice, for a few reasons: First, the syscall overhead ends up being pretty bad. Probably not as bad in LTO as in Subversion (for obvious reasons), but you shouldn't discount it. Second, and more importantly, on a network file system, the open/seek/read calls to get at the cached data are going to be RPC calls. --Dan
