[LLVMdev] C as used/implemented in practice: analysis of responses (original) (raw)
Sean Silva chisophugis at gmail.com
Wed Jul 1 15:20:20 PDT 2015
- Previous message: [LLVMdev] C as used/implemented in practice: analysis of responses
- Next message: [LLVMdev] C as used/implemented in practice: analysis of responses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [LLVMdev] C as used/implemented in practice: analysis of responses
- Next message: [LLVMdev] C as used/implemented in practice: analysis of responses
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]