llvm dev - Apr 2014 - [LLVMdev] RFC: Binary format for instrumentation based profiling data

On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <evan.cheng at apple.com>
wrote:
> I agree the top priority should always be "getting it right”. But I
can’t
> agree with this thinking completely. This has to be balanced with
> pragmatism. If we completely disregard the practical concerns of commercial
> use, it makes LLVM hostile towards an important group of users.

Clearly, I can't argue with that. =] We benefit from it as well. And I
don't think I'm arguing against a pragmatic approach in this case,
although
I'm sorry if it comes off that way.

Just so we're on the same page, the only real question in my mind is: can
we make breaking changes as we iterate on the design.

What I would like to do is figure out the right design first,
incrementally, trying one format, and seeing how it does, but potentially
with backwards incompatible changes. Once we have the experience and know
what the right format is, *then* we should consider pragmatic concerns such
as how to structure support for reading legacy formats, or formats outside
of the control of the project. I think if we start off with a format that
we can't change because of external reasons (whatever they may be), it will
be much harder to incrementally get to the right design. Does that seem
reasonable (and hopefully help explain the concrete suggestion I'm making)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/59277e03/attachment.html>

On 04/19/14 02:47 AM, Chandler Carruth wrote:
>
> On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <evan.cheng at apple.com 
> <mailto:evan.cheng at apple.com>> wrote:
>
>     I agree the top priority should always be "getting it right”. But
>     I can’t agree with this thinking completely. This has to be
>     balanced with pragmatism. If we completely disregard the practical
>     concerns of commercial use, it makes LLVM hostile towards an
>     important group of users.
>
>
> Clearly, I can't argue with that. =] We benefit from it as well. And I 
> don't think I'm arguing against a pragmatic approach in this case, 
> although I'm sorry if it comes off that way.
>
> Just so we're on the same page, the only real question in my mind is: 
> can we make breaking changes as we iterate on the design.
>
> What I would like to do is figure out the right design first, 
> incrementally, trying one format, and seeing how it does, but 
> potentially with backwards incompatible changes. Once we have the 
> experience and know what the right format is, *then* we should 
> consider pragmatic concerns such as how to structure support for 
> reading legacy formats, or formats outside of the control of the 
> project. I think if we start off with a format that we can't change 
> because of external reasons (whatever they may be), it will be much 
> harder to incrementally get to the right design. Does that seem 
> reasonable (and hopefully help explain the concrete suggestion I'm 
> making)?
Why can't we have our cake and eat it too?

Off the cuff and flame away
------------
What's wrong with a soft policy like - Feel free to do an incremental 
improvement which breaks a change and then if someone else wants to 
contribute a patch that allows the old format/behavior - that's up to 
them (patches welcome). Both changes would be accepted and allows the 
parallel paths - (putting the burden of maintenance for backward 
compatibility on those stakeholders). Wouldn't this solve the problem 
Right Now(tm)?

I don't mean this as an attack
It's very depressing to see passionate Apple vs Google people not be 
able to come to middle ground very quickly

On Fri, Apr 18, 2014 at 12:58 PM, "C. Bergström"
<cbergstrom at pathscale.com>wrote:
> On 04/19/14 02:47 AM, Chandler Carruth wrote:
>
>
>> On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <evan.cheng at
apple.com<mailto:
>> evan.cheng at apple.com>> wrote:
>>
>>     I agree the top priority should always be "getting it right”.
But
>>     I can’t agree with this thinking completely. This has to be
>>     balanced with pragmatism. If we completely disregard the practical
>>     concerns of commercial use, it makes LLVM hostile towards an
>>     important group of users.
>>
>>
>> Clearly, I can't argue with that. =] We benefit from it as well.
And I
>> don't think I'm arguing against a pragmatic approach in this
case, although
>> I'm sorry if it comes off that way.
>>
>> Just so we're on the same page, the only real question in my mind
is: can
>> we make breaking changes as we iterate on the design.
>>
>> What I would like to do is figure out the right design first,
>> incrementally, trying one format, and seeing how it does, but
potentially
>> with backwards incompatible changes. Once we have the experience and
know
>> what the right format is, *then* we should consider pragmatic concerns
such
>> as how to structure support for reading legacy formats, or formats
outside
>> of the control of the project. I think if we start off with a format
that
>> we can't change because of external reasons (whatever they may be),
it will
>> be much harder to incrementally get to the right design. Does that seem
>> reasonable (and hopefully help explain the concrete suggestion I'm
making)?
>>
> Why can't we have our cake and eat it too?
>
> Off the cuff and flame away
> ------------
> What's wrong with a soft policy like - Feel free to do an incremental
> improvement which breaks a change and then if someone else wants to
> contribute a patch that allows the old format/behavior - that's up to
them
> (patches welcome). Both changes would be accepted and allows the parallel
> paths - (putting the burden of maintenance for backward compatibility on
> those stakeholders). Wouldn't this solve the problem Right Now(tm)?
>
I think its important that there remain incentives for the contributors to
address design feedback that comes up in review essentially. Making it
"patches welcome" right away, removes that incentive IMO, and would be
a
shame. Sometimes, its unavoidable, but I think the project is better when
we hold that line.

As an example, when we wanted to contribute the AST matchers to Clang, is
was really useful that it was entirely on us to address all of the
(excellent) design review from Doug. It may not have mattered for our use
cases, but it mattered that the not-quite-right solution didn't just sit
rotting in mainline waiting for someone to take up the challenge of making
it the right solution.

The pragmatic tradeoff here is to do it incrementally, so you don't have to
leap to the right solution before the first patch lands. And I don't think
there has been any pushback against that in this thread.

> I don't mean this as an attack
> It's very depressing to see passionate Apple vs Google people not be
able
> to come to middle ground very quickly
>
=] I think we're actually pretty close, and the discussion continues to be
polite, and non-circular, so I'm not depressed yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/4fc93b13/attachment.html>

On Apr 18, 2014, at 12:47 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> 
> On Fri, Apr 18, 2014 at 12:22 PM, Evan Cheng <evan.cheng at
apple.com> wrote:
> I agree the top priority should always be "getting it right”. But I
can’t agree with this thinking completely. This has to be balanced with
pragmatism. If we completely disregard the practical concerns of commercial use,
it makes LLVM hostile towards an important group of users.
> 
> Clearly, I can't argue with that. =] We benefit from it as well. And I
don't think I'm arguing against a pragmatic approach in this case,
although I'm sorry if it comes off that way.
I didn’t think that’s what you were suggesting. But I wanted to make sure we are
on the same page. Sometimes I felt like the arguments in these threads are
starting to take on a “religious” tone. I really don’t want to see that happen.
> 
> Just so we're on the same page, the only real question in my mind is:
can we make breaking changes as we iterate on the design.
> 
> What I would like to do is figure out the right design first,
incrementally, trying one format, and seeing how it does, but potentially with
backwards incompatible changes. Once we have the experience and know what the
right format is, *then* we should consider pragmatic concerns such as how to
structure support for reading legacy formats, or formats outside of the control
of the project. I think if we start off with a format that we can't change
because of external reasons (whatever they may be), it will be much harder to
incrementally get to the right design. Does that seem reasonable (and hopefully
help explain the concrete suggestion I'm making)?

Yes and no. I agree that we should try to get the design right. We should not be
afraid to make changes to drop technical debts even if it’s inconvenient. In
this specific discussion, I obviously agree we should come up with a method to
support non-mainline formats. However, I don’t think it’s always possible to
come up with the a design that’s 100% perfect. And the only way we can get real
world feedback is to get it out there so people can use it. I fear we are
straying a little too far from iterative approach that LLVM has always
encouraged.

Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140418/7a1017e6/attachment.html>