“Fiercely resist any further broadening of the scope of the C UB problem”

Re:“Fiercely resist any further broadening of the scope of t... by mwcampbell on Thursday April 14, 2016 @12:28PM (#11498060)

But why do we always want more, more, more? If gcc -O2 without whole-program optimization was good enough to encode MP3 faster than real-time on a 366 MHz Pentium laptop in 1999, then surely it's good enough now, with all the increases in processor performance since then. If that level of compiler optimization isn't good enough now, then maybe that means we programmers are doing something wrong. At some point, better optimization in a compiler probably isn't worth what you give up to get it, in terms of reliability and comprehensibility.

Edit: All the responses are right. Feel free to downvote this ill-considered comment into oblivion, now that I can't take it back.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by chrisseaton on Thursday April 14, 2016 @12:42PM (#11498218)

> If gcc -O2 without whole-program optimization was good enough to encode MP3 faster than real-time on a 366 MHz Pentium laptop in 1999, then surely it's good enough now

This is patently a ludicrous argument. How can the speed of encoding an MP3 be used as a proxy for countless other applications of computers?

Programs that are slower than they need to be waste real energy and other industrial resources.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by haberman on Thursday April 14, 2016 @12:36PM (#11498169)

People in 1999 weren't running huge neural nets and beating the world champion in Go.

There are millions of computers in data centers around the world. They are working on problems that someone thought it was worthwhile enough to pay for. If C compilers emit code that is slower, that means buying and maintaining a lot more computers, using more energy, producing more greenhouse gas, etc.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by dragontamer on Thursday April 14, 2016 @12:41PM (#11498212)

> People in 1999 weren't running huge neural nets and beating the world champion in Go.

Which was mostly GPU code, so it was either CUDA or OpenCL btw. Not actually C.

People do need to realize that the fastest, massively parallel supercomputers are in fact written in CUDA / OpenCL. And the most powerful supercomputers are mostly being used to display 3d-models of a sword-wielder fighting a guy with guns.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by haberman on Thursday April 14, 2016 @12:45PM (#11498246)

Fair enough. But some very significant fraction of the hardware and energy spent on data centers today is on CPUs.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by colin_mccabe on Friday April 15, 2016 @12:19AM (#11502116)

I don't think this is an "ill-considered comment" at all.

Daniel J. Bernstein made the same comment in his slides about "the slow death of the optimizing compiler"[ https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf ]. Basically, a lot of programs are I/O bound. Those that aren't are often dominated by a tiny amount of super-hot spots that can be optimized by hand via assembly language. Most code is "freezing cold" -- it's hardly worth optimizing. C compilers are giving up safety and getting very little in return, except shiny new compiler benchmarks.

[ Parent | on HN ]

Re:“Fiercely resist any further broadening of the scope of t... by pcwalton on Thursday April 14, 2016 @12:57PM (#11498373)

Yes, you don't need the performance for listening to MP3s. MP3 decoding is nowhere near the outer limit of CPU performance you rely on every day.

Just to stay within the domain of codecs, YouTube would not be a nice experience on a 366 MHz Pentium laptop with primitive compiler optimizations.

[ Parent | on HN ]