Live data from Hacker News

C++ at Google: Here Be Dragons

blog.llvm.org

41–50 of 91 posts

Re: C++ at Google: Here Be Dragons

#41
post #39
post #37

Earlier quoted context omitted.

I've seen this "10-20% slower" meme several times, but I've also read several accounts of 10-20% faster runtime performance. All I know for sure is I compiled my codebase with Clang for the first time yesterday and the compilation time was absurdly short. I thought the compiler was broken. And it enables excellent tools like clang_complete for Vim code completion.

Woah, let's not conflate compilation -speed with runtime -speed...

The parent was not intimating what you inferred.

Re: C++ at Google: Here Be Dragons

#42
I haven't worked in C (or C++) heavily in about 6 years, since I shut down my prior company and stopped working on Squid or having to look at kernel code. But, these errors are simply beautiful, and make me have vague longings to work on C projects again (I'm sure I'll get over those longings soon).

These are the kinds of mistakes I made all the time when working in C, and the kind of thing that made coding extremely tedious...it feels like magic when the compiler catches them with such clear and concise warnings. For whatever reason, I didn't use lint very much back then, as I guess I always assumed I knew what I was doing and that the compiler would catch mistakes. Having this capability in the compiler is pretty cool and brings C/C++ a small step closer to working in higher level languages, is what I think I'm trying to say here.

Re: C++ at Google: Here Be Dragons

#43
post #8
post #6

Earlier quoted context omitted.

Google has said before they didn't use Clang and LLVM because of performance issues. GCC is far from dead, and probably never will. Clang generated code is still typically 10-20% slower than GCC. Lots of companies work on GCC, including Google, Intel, AMD, IBM, Red Hat and others.

Apple's been pushing developers toward LLVM for several years, and is bound to make it an app store requirement at some point. I've observed no such 10-20% slowdown on iOS, which is more CPU-constrained than most realms. Typically, LLVM-generated code is equivalent to or faster than gcc. Sometimes it's much faster.

People forget that AOT can only get you so far. JIT not only has all the info the AOT mechanism has, but also has real runtime fact based data, and can do wonders with it.

Re: C++ at Google: Here Be Dragons

#44
post #39
post #37

Earlier quoted context omitted.

I've seen this "10-20% slower" meme several times, but I've also read several accounts of 10-20% faster runtime performance. All I know for sure is I compiled my codebase with Clang for the first time yesterday and the compilation time was absurdly short. I thought the compiler was broken. And it enables excellent tools like clang_complete for Vim code completion.

Woah, let's not conflate compilation -speed with runtime -speed...

Read carefully and you'll see I was not.

Re: C++ at Google: Here Be Dragons

#45
post #8

Earlier quoted context omitted.

Apple's been pushing developers toward LLVM for several years, and is bound to make it an app store requirement at some point. I've observed no such 10-20% slowdown on iOS, which is more CPU-constrained than most realms. Typically, LLVM-generated code is equivalent to or faster than gcc. Sometimes it's much faster.

People forget that AOT can only get you so far. JIT not only has all the info the AOT mechanism has, but also has real runtime fact based data, and can do wonders with it.

For the sake of argument:

What is an example of an optimization that a JIT compiler can make that a AOT compiler cannot?

If the developer is able to profile the application on typical end-user workloads, don't profile-guided optimizations provide the same benefit as JIT runtime profiling?

Why can't an AOT compiler just consider every path a "hot" path?

Last but not least: Got any benchmarks?

Re: C++ at Google: Here Be Dragons

#46

Earlier quoted context omitted.

I would expect many of these tools to catch these types of bugs. The challenging thing for us has been to catch only bugs, and to catch them very fast during normal compilation. A lot of the static analyses we've looked into (and I'm hoping for more detailed blog posts about that in the future) find plenty of bugs, but also find lots of non-bugs. Combine that with being too slow to run during the normal build, and yo…

These sort of articles (and the attendant comments about false positives) always scream out for Ada to me. It's a language designed by a calm, careful thinker back in the 80's for life critical programs. It has everything Java and C++ have except the vast number of undefined states and it's designed for static analysis. By designed I mean, there are formal verifiers and the NSA has used it in a test security system.…

Admittedly I only programmed in Ada for a few months, but I found it to be an unbearably tedious language. The verbosity is monstrous--- the type system is inexpressive; it feels primitive. Nothing is inferred, everything is repeated. Ugh, I would rather code exclusively in C++ templates than touch Ada again.

Re: C++ at Google: Here Be Dragons

#47
post #45

Earlier quoted context omitted.

People forget that AOT can only get you so far. JIT not only has all the info the AOT mechanism has, but also has real runtime fact based data, and can do wonders with it.

For the sake of argument: What is an example of an optimization that a JIT compiler can make that a AOT compiler cannot? If the developer is able to profile the application on typical end-user workloads, don't profile-guided optimizations provide the same benefit as JIT runtime profiling? Why can't an AOT compiler just consider every path a "hot" path? Last but not least: Got any benchmarks?

For one: JIT can do polymorphic inline caching (you can read more about from Google's senior vice president of operations Urs Hölzle[1]), while AOT can't.

Wikipedia gives a few more[2]: runtime profile-guided optimizations and pseudo-constant propagation

[1] http://research.google.com/pubs/author79.html

[2] http://en.wikipedia.org/wiki/AOT_compiler

Re: C++ at Google: Here Be Dragons

#48

Earlier quoted context omitted.

These sort of articles (and the attendant comments about false positives) always scream out for Ada to me. It's a language designed by a calm, careful thinker back in the 80's for life critical programs. It has everything Java and C++ have except the vast number of undefined states and it's designed for static analysis. By designed I mean, there are formal verifiers and the NSA has used it in a test security system.…

Admittedly I only programmed in Ada for a few months, but I found it to be an unbearably tedious language. The verbosity is monstrous--- the type system is inexpressive; it feels primitive. Nothing is inferred, everything is repeated. Ugh, I would rather code exclusively in C++ templates than touch Ada again.

I will freely admit that Ada is not appropriate for all uses. But for the sort of thing you'd want to use Ada for (life critical systems, critical infrastructure, control systems, etc) The explicit type system, explicit declaration, statically typed system is ideal. I particularly like the ability to declare down to the bit level how my data is stored. Very useful for working with low level hardware.

Take a look again, with an eye towards large scale long lived critical systems. You'll find that explicitness a feature, as is the very strict static typing.

Oh, and they got pointers right the first time.

EDIT: Forgot to mention the coolness of the type system - you can declare ranges and other type information and the compiler will hold that requirement strictly. for example type direction is range 0..359; Declares the obvious, but now you can have the compiler error if you assign a direction type with a value that might be outside that range. Even if you don't set that option you can always use the foo'valid attribute to check that foo is within bounds. This is used to check for stray cosmic radiation (seriously!).

Yes it seems like overkill. But when you come back to 20 year old code that's still running you'll smile.

Re: C++ at Google: Here Be Dragons

#49
post #16

To me, the most remarkable thing about this post is that when the rest of the world is falling in love with the "power" of weak typing systems, Google is going the other way .

Hrm? That blog post is all about Google is using Clang to dig themselves out of a hole they fell into by using C++ with its weak type system, and doesn't suggest they have plans to change languages.

Re: C++ at Google: Here Be Dragons

#50

Earlier quoted context omitted.

These sort of articles (and the attendant comments about false positives) always scream out for Ada to me. It's a language designed by a calm, careful thinker back in the 80's for life critical programs. It has everything Java and C++ have except the vast number of undefined states and it's designed for static analysis. By designed I mean, there are formal verifiers and the NSA has used it in a test security system.…

What kinds of libraries are available for Ada? Half the reason I use C++ is that half the code I need to write is already available in mature libraries.

Library support is aimed squarely at realtime life critical systems. You're more likely to find a library with some sort of safety certification than not. If you're expecting to use the latest web libraries or hadoop you'll be disappointed.

However, there is a small collection of oss Ada libraries out there.

Post reply on HN