This is the mail archive of the gcc@gcc.gnu.org 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 <zadeck@naturalbridge.com> 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


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