[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Why clang needs to fork into itself?
From: Sean Silva <silvas () purdue ! edu>
Date: 2014-01-29 23:10:23
Message-ID: CAHnXoakyujRzLJVQOujh9ZuKLASLuHDU6KJhJDNLDTjhW+TQPQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Wed, Jan 29, 2014 at 3:26 PM, Alp Toker <alp@nuanti.com> wrote:
>
> On 29/01/2014 20:06, Sean Silva wrote:
>
>
>>
>>
>> On Tue, Jan 28, 2014 at 12:45 PM, Nico Weber <thakis@chromium.org<mailto=
:
>> thakis@chromium.org>> wrote:
>>
>> I believe there was a thread about not forking the driver a while
>> ago, but I'm unable to find it. As far as I remember, Chris
>> Lattner wanted to get rid of it for aesthetic reasons and to save
>> the milliseconds of overhead it adds (I think doing this has
>> originally been the plan, see the "fork/exec" section on
>> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-December/007211.html
>> ).
>> At the end, the decision was made to keep the subprocess for cc1,
>> but I don't remember all the reasons. I think crash reporting was
>> part of the discussion, but there was half a plan to keep that
>> feature with in-process crash reporting somehow.
>>
>> Maybe someone still has a copy of that thread in their inbox?
>> Keywords "lattner dgregor cc1 crash fork exec" or similar might
>> find it.
>>
>>
>> The thread you linked to predates my LLVM involvement, but I remember
>> another thread (long time ago) that I was involved in where basically it
>> was asked "is this a measurable slowdown?" (my me or someone else, I
>> forget) and nobody could provide real numbers supporting that it was a
>> measurable slowdown (even on Windows). Can't see to find the thread in m=
y
>> email though.
>>
>> Do we have real performance numbers demonstrating a slowdown at this
>> point?
>>
>
> Hi Sean,
>
> I have a patch now that pushes all self-invocations in-process without
> doing anything else clever such as reusing FileManager stat caches or
> in-memory object files (6 line diff, posted in another part of this threa=
d).
>
> Haven't had a chance to time it yet, but it doesn't look like an
> earth-shattering win on OS X (5 reruns of make check show around 2 second=
s
> saved from a 30 second run as a very early indication).
>
> On the other hand it's been fun to debug the driver with this setup and I
> suspect there'll be a bigger win on Windows.
>
> Another patch I'm cooking up just to see "what happens", is to use the
> IPCChannel facility recently added to LLVM to avoid the driver invocation
> itself.
>
What is this IPCChannel? I can't seem to find it.
-- Sean Silva
>
> Alp.
>
>
>
>> -- Sean Silva
>>
>>
>>
>> On Tue, Jan 28, 2014 at 7:19 AM, Rafael Esp=EDndola
>> <rafael.espindola@gmail.com <mailto:rafael.espindola@gmail.com>>
>>
>> wrote:
>>
>> On 27 January 2014 17:27, Reid Kleckner <rnk@google.com
>> <mailto:rnk@google.com>> wrote:
>> > As an alternative, on Windows we could rig up some kind of
>> SEH filter to do
>> > crash recovery. Then we could save the subprocess
>> invocation and speed
>> > things up.
>>
>> Breakpad is used by both chrome and firefox for this. If going
>> this
>> path, please make sure the same technique is used for all system=
s.
>>
>> Cheers,
>> Rafale
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev@cs.uiuc.edu <mailto:cfe-dev@cs.uiuc.edu>
>>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev@cs.uiuc.edu <mailto:cfe-dev@cs.uiuc.edu>
>>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
> --
> http://www.nuanti.com
> the browser experts
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, \
Jan 29, 2014 at 3:26 PM, Alp Toker <span dir="ltr"><<a \
href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> On 29/01/2014 20:06, Sean Silva wrote:<div \
class="im"><br> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
<br>
<br>
On Tue, Jan 28, 2014 at 12:45 PM, Nico Weber <<a href="mailto:thakis@chromium.org" \
target="_blank">thakis@chromium.org</a> <mailto:<a \
href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>>> \
wrote:<br>
<br>
I believe there was a thread about not forking the driver a while<br>
ago, but I'm unable to find it. As far as I remember, Chris<br>
Lattner wanted to get rid of it for aesthetic reasons and to save<br>
the milliseconds of overhead it adds (I think doing this has<br>
originally been the plan, see the "fork/exec" section on<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-December/007211.html" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/cfe-dev/2009-<u></u>December/007211.html</a>).<br>
At the end, the decision was made to keep the subprocess for cc1,<br>
but I don't remember all the reasons. I think crash reporting was<br>
part of the discussion, but there was half a plan to keep that<br>
feature with in-process crash reporting somehow.<br>
<br>
Maybe someone still has a copy of that thread in their inbox?<br>
Keywords "lattner dgregor cc1 crash fork exec" or similar might<br>
find it.<br>
<br>
<br>
The thread you linked to predates my LLVM involvement, but I remember another thread \
(long time ago) that I was involved in where basically it was asked "is this a \
measurable slowdown?" (my me or someone else, I forget) and nobody could provide \
real numbers supporting that it was a measurable slowdown (even on Windows). \
Can't see to find the thread in my email though.<br>
<br>
Do we have real performance numbers demonstrating a slowdown at this point?<br>
</blockquote>
<br></div>
Hi Sean,<br>
<br>
I have a patch now that pushes all self-invocations in-process without doing anything \
else clever such as reusing FileManager stat caches or in-memory object files (6 line \
diff, posted in another part of this thread).<br>
<br>
Haven't had a chance to time it yet, but it doesn't look like an \
earth-shattering win on OS X (5 reruns of make check show around 2 seconds saved from \
a 30 second run as a very early indication).<br> <br>
On the other hand it's been fun to debug the driver with this setup and I suspect \
there'll be a bigger win on Windows.<br> <br>
Another patch I'm cooking up just to see "what happens", is to use the \
IPCChannel facility recently added to LLVM to avoid the driver invocation \
itself.<br></blockquote><div><br></div><div>What is this IPCChannel? I can't seem \
to find it.</div> <div><br></div><div>-- Sean Silva</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
Alp.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im"> <br>
-- Sean Silva<br>
<br>
<br>
<br>
On Tue, Jan 28, 2014 at 7:19 AM, Rafael Espíndola<br></div>
<<a href="mailto:rafael.espindola@gmail.com" \
target="_blank">rafael.espindola@gmail.com</a> <mailto:<a \
href="mailto:rafael.espindola@gmail.com" \
target="_blank">rafael.espindola@<u></u>gmail.com</a>>><div class="im"> <br>
wrote:<br>
<br>
On 27 January 2014 17:27, Reid Kleckner <<a href="mailto:rnk@google.com" \
target="_blank">rnk@google.com</a><br></div><div class="im">
<mailto:<a href="mailto:rnk@google.com" \
target="_blank">rnk@google.com</a>>> wrote:<br>
> As an alternative, on Windows we could rig up some kind of<br>
SEH filter to do<br>
> crash recovery. Then we could save the subprocess<br>
invocation and speed<br>
> things up.<br>
<br>
Breakpad is used by both chrome and firefox for this. If going<br>
this<br>
path, please make sure the same technique is used for all systems.<br>
<br>
Cheers,<br>
Rafale<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br></div>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> \
<mailto:<a href="mailto:cfe-dev@cs.uiuc.edu" \
target="_blank">cfe-dev@cs.uiuc.edu</a>><div class="im"><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br> <br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br></div>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> \
<mailto:<a href="mailto:cfe-dev@cs.uiuc.edu" \
target="_blank">cfe-dev@cs.uiuc.edu</a>><div class="im"><br> <a \
href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br> <br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br> \
</div></blockquote> <br><div class="HOEnZb"><div class="h5">
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic