This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!

On 8/31/06, Kenneth Zadeck <> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]