Sometimes Linus says some really flippant and funny things but gosh I couldn't agree more.. with one tiny nit.. Properly written Fortran and a good compiler is potentially as fast or faster than typical C version in HPC codes. (yes you may be able to get the c version faster, but it would take some effort.) Original Message From: Linus Torvalds via llvm-dev Sent: Sunday, February 28, 2016 23:13 To: Markus Trippelsdorf Reply To: Linus Torvalds Cc: linux-arch@xxxxxxxxxxxxxxx; gcc@xxxxxxxxxxx; Jade Alglave; parallel@xxxxxxxxxxxxxxxx; llvm-dev@xxxxxxxxxxxxxx; Will Deacon; Linux Kernel Mailing List; David Howells; Peter Zijlstra; Ramana Radhakrishnan; Luc Maranget; Andrew Morton; Paul McKenney; Ingo Molnar Subject: Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx> wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard C. > All these options also have a negative impact on the performance of the > generated code. They really don't. Have you ever seen code that cared about signed integer overflow? Yeah, getting it right can make the compiler generate an extra ALU instruction once in a blue moon, but trust me - you'll never notice. You *will* notice when you suddenly have a crash or a security issue due to bad code generation, though. The idiotic C alias rules aren't even worth discussing. They were a mistake. The kernel doesn't use some "C dialect pretty far from standard C". Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster. They don't speed up normal code either, they just introduce undefined behavior in a lot of code. And deleting NULL pointer checks because somebody made a mistake, and then turning that small mistake into a real and exploitable security hole? Not so smart either. The fact is, undefined compiler behavior is never a good idea. Not for serious projects. Performance doesn't come from occasional small and odd micro-optimizations. I care about performance a lot, and I actually look at generated code and do profiling etc. None of those three options have *ever* shown up as issues. But the incorrect code they generate? It has. Linus _______________________________________________ LLVM Developers mailing list llvm-dev@xxxxxxxxxxxxxx http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
