llvm dev - Jul 2015 - [LLVMdev] C as used/implemented in practice: analysis of responses

On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com>
wrote:
> Why do you say spin?
You're dismissing all use-cases other than this very narrow one I'd
(with my own spin) characterise as "Do What I Mean, I Can't Be
Bothered To Get My Code Right". Fair enough, you're arguing in favour
of a point; but it's not one I agree with.

Tim.

I am arguing in favor of a point, and I understand you disagree with it,
but I don't think I'm dismissing any use cases except a very small
performance increment. Furthermore, the compiler would still be free to
perform such optimisations where it can prove they won't break the program.
That's not all cases, to be sure, but at least we would then be back to the
normal scenario where over the years as the compiler gets smarter, things
get better, as opposed to monkey's paw optimisations which cause a smarter
compiler to make things worse.

On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at
gmail.com>
> wrote:
> > Why do you say spin?
>
> You're dismissing all use-cases other than this very narrow one I'd
> (with my own spin) characterise as "Do What I Mean, I Can't Be
> Bothered To Get My Code Right". Fair enough, you're arguing in
favour
> of a point; but it's not one I agree with.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/b69d9912/attachment.html>

----- Original Message -----
> From: "Russell Wallace" <russell.wallace at gmail.com>
> To: "Tim Northover" <t.p.northover at gmail.com>
> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvmdev at
cs.uiuc.edu
> Sent: Wednesday, July 1, 2015 2:22:24 PM
> Subject: Re: [LLVMdev] C as used/implemented in practice: analysis of
responses
> 
> 
> I am arguing in favor of a point, and I understand you disagree with
> it, but I don't think I'm dismissing any use cases except a very
> small performance increment.
You seem to be implying that these optimizations only yield small performance
improvements. To be sure, most optimizations yield only small (or no)
improvement to most programs. But this is simply because there are a large
number of optimizations (LLVM has millions of lines of code, and a significant
number of them are dedicated to code optimization). Furthermore, most user code
is not in hot regions, and thus does not matter for performance. Thus, the
number of optimizations that matter to hot code regions in any particular
program is often (although not always) limited. However, there is wide variety
in hot code, and essentially all of these optimizations were implemented because
they yielded a significant improvement to someone's hot code region (or were
a closely-related case).

 -Hal
> Furthermore, the compiler would still
> be free to perform such optimisations where it can prove they won't
> break the program. That's not all cases, to be sure, but at least we
> would then be back to the normal scenario where over the years as
> the compiler gets smarter, things get better, as opposed to monkey's
> paw optimisations which cause a smarter compiler to make things
> worse.
> 
> 
> 
> On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <
> t.p.northover at gmail.com > wrote:
> 
> 
> On 1 July 2015 at 11:34, Russell Wallace < russell.wallace at gmail.com
> > wrote:
> > Why do you say spin?
> 
> You're dismissing all use-cases other than this very narrow one I'd
> (with my own spin) characterise as "Do What I Mean, I Can't Be
> Bothered To Get My Code Right". Fair enough, you're arguing in
favour
> of a point; but it's not one I agree with.
> 
> Tim.
> 
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Wed, Jul 1, 2015 at 12:22 PM, Russell Wallace <russell.wallace at
gmail.com>
wrote:
> I am arguing in favor of a point, and I understand you disagree with it,
> but I don't think I'm dismissing any use cases except a very small
> performance increment.
>
I'm sure Google has numbers about how much electricity/server cost they
save for X% performance improvement.
I'm sure Apple has numbers about how much money they make with X% improved
battery life.
I'm not convinced that the cost of some of these bugs is actually larger
than the benefit of faster programs. Nor am I convinced about the inverse.
I'm just pointing out that pointing to a "bad bug" caused by a
certain
optimization without comparing the cost of the bug to the benefit of the
optimization is basically meaningless. You'll need to quantify "very
small
performance improvement" and put it in context of the bugs you're
talking
about.

> Furthermore, the compiler would still be free to perform such
> optimisations where it can prove they won't break the program.
>
"won't break the program" is very hard to know...

-- Sean Silva

> That's not all cases, to be sure, but at least we would then be back to
> the normal scenario where over the years as the compiler gets smarter,
> things get better, as opposed to monkey's paw optimisations which cause
a
> smarter compiler to make things worse.
>
> On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <t.p.northover at
gmail.com>
> wrote:
>
>> On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at
gmail.com>
>> wrote:
>> > Why do you say spin?
>>
>> You're dismissing all use-cases other than this very narrow one
I'd
>> (with my own spin) characterise as "Do What I Mean, I Can't Be
>> Bothered To Get My Code Right". Fair enough, you're arguing in
favour
>> of a point; but it's not one I agree with.
>>
>> Tim.
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/b4922acd/attachment.html>

We already perform optimizations only when the compiler can prove they won’t
break the program.
The only difference between that and what you suggest is in the definition of
“won’t break the program”. We define it as “won’t break the program with respect
to the semantics implied by the C/C++ spec”.

You want to redefine it, by specifying a new abstract machine, which is more
conservative than standard C/C++. The proper way to do that would, I believe, be
to work towards setting up a working group within the relevant committees, and
come up with a uniformly accepted definition for this abstract machine, which
could then be implemented (assuming there is, indeed, wide enough agreement in
the implementer community – something that does not look at all likely) by
next-generation compilers.

Point is – I think you’re barking up the wrong tree.
This isn’t an llvm-dev issue, it’s a standards committee issue.

Michael

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Russell Wallace
Sent: Wednesday, July 01, 2015 22:22
To: Tim Northover
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] C as used/implemented in practice: analysis of responses

I am arguing in favor of a point, and I understand you disagree with it, but I
don't think I'm dismissing any use cases except a very small performance
increment. Furthermore, the compiler would still be free to perform such
optimisations where it can prove they won't break the program. That's
not all cases, to be sure, but at least we would then be back to the normal
scenario where over the years as the compiler gets smarter, things get better,
as opposed to monkey's paw optimisations which cause a smarter compiler to
make things worse.

On Wed, Jul 1, 2015 at 7:53 PM, Tim Northover <t.p.northover at
gmail.com<mailto:t.p.northover at gmail.com>> wrote:
On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at
gmail.com<mailto:russell.wallace at gmail.com>>
wrote:
> Why do you say spin?
You're dismissing all use-cases other than this very narrow one I'd
(with my own spin) characterise as "Do What I Mean, I Can't Be
Bothered To Get My Code Right". Fair enough, you're arguing in favour
of a point; but it's not one I agree with.

Tim.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/0de0e8fa/attachment.html>