Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ at Google: Here Be Dragons

blog.llvm.org

Post reply on HN
Print view View original

61–70 of 91 posts

Re: C++ at Google: Here Be Dragons

#61

Post by SoftwareMaven »

lurker19 wrote: post #49
timr wrote: 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.

I think the Go* language is proof they are trying to solve some of C++'s problems without giving up speed.

It would be an amazing research project to take a couple different, large Google C++ programs and port them to Haskel and Erlang to see how they compre.

* Why does it have to be such a common word for it's name? Just means it's name, for all practical purposes, is "Go Language".

Re: C++ at Google: Here Be Dragons

#62

Post by stephen_g »

ANH wrote: post #37
wmobit wrote: 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.

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.

It depends on the code - while GCC, being more mature, is typically better at most optimisations, there are a few cases where Clang produces code that is a fair bit faster.

Over time, as Clang gets more mature, it will become more and more on par (or better) than GCC.

Re: C++ at Google: Here Be Dragons

#63

Post by chandlerc »

lurker19 wrote: post #51
chandlerc wrote: post #36

Earlier quoted context omitted.

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and t…

When is assigning a pointer to be boolean false intentional and correct?

Most of the cases we ran into were metaprogramming techniques which test whether an expression is a valid null pointer constants. These got innocently applied to 'false' and trigger the warning needlessly.

Re: C++ at Google: Here Be Dragons

#64

Post by Confusion »

swannodette wrote: post #31
nradov wrote: post #27

Earlier quoted context omitted.

Why can't we have a language that supports both? I would love to have a language with a scalable type system where I could hack out a quick small prototype with dynamic typing first, and then perhaps layer on static types later where necessary to improve reliability and performance as the program evolves. For example, I would like to be able to declare a variable in all of the following different ways. a value a numb…

You can support both. You should take look at Typed Racket, Racket w/ Contracts, Erlang Dialyzer, and Qi/Shen. Frankly the Lisp contingent is way ahead on this kind of thinking (would of course love to hear about others). I'm interested in developing such systems for Clojure and have actively researching something considerably more powerful than Chambers/Chen predicate dispatch.

Qi/Shen is a fusion of Haskell and Lisp, heavily inspired by Haskell. The Lisp contingent is not 'way ahead': they are simply assimilating useful bits of their strongly typed functional cousin languages.

Re: C++ at Google: Here Be Dragons

#65

Post by roel_v »

stephen_g wrote: post #60
SwellJoe wrote: post #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…

"Having this capability in the compiler is pretty cool and brings C/C++ a small step closer to working in higher level languages" C++0x is another (much bigger, in my opinion) step that makes C++ a lot easier to program. It's not quite as easy as higher level languages, but far closer than before, and the performance gains over most other languages make it worth using.

I agree. Lately I've been writing substantial amounts of 'higher level' code again, and I find myself writing many checks for the types of variables (as members or arguments), return values, contents of containers, in situations where one may make inadvertent conversions etc. I'm thinking that much of the time I spend on that would have cost me less time if I could have just specified them in the code and the compiler/runtime would check them for me, like in C++.

Of course writing unit tests helps too, but in C++ the compiler catches these things easily. And I haven't had the desire to use a variant in years so the advantages of having a 'variable' that can be of any type is quite minimal, imo. The auto keyword in C++0x will make a large portion of the tedious parts of strong typing in C++ go away, too.

IMO thinks like type hinting in PHP are absolutely steps in the right direction. There is room for both 'scripting' and 'compiled' languages, but good support for indicating and checking the expected or required types in scripting languages helps tremendously in proactively validating programs.

Re: C++ at Google: Here Be Dragons

#66

Post by roel_v »

jrockway wrote: post #7
matthavener wrote: post #3

I wonder if this is an indication that google is moving to clang for compiling (and not just diagnostic tools). If that's true, maybe this is another nail in the coffin for gcc? I see apple and google behind llvm/clang, who's behind gcc? Nobody?

who's behind gcc? Nobody? I hear there's this kernel called Linux that depends heavily on GCC.

But why would the kernel depend on gcc? Are there so many gcc-isms in there that would be hard to replicate on other compilers?

Re: C++ at Google: Here Be Dragons

#67

Post by roel_v »

ANH wrote: post #44
MBlume wrote: post #39

Earlier quoted context omitted.

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

Read carefully and you'll see I was not.

May be but your post was ambiguous wrt its implications. Defensive writing would have had you writing it more carefully about what you meant.

Re: C++ at Google: Here Be Dragons

#68

Post by roel_v »

chandlerc wrote: post #36
archangel_one wrote: post #30

The article implies to me that the third bug (passing 0.5 to sleep() ) is not caught by gcc. Does anyone know if this is the case? It doesn't seem excessively hard to produce a warning about shortening like that - the first two seem more subtle, but that one less so. I don't have gcc on this machine to check it, but VC++ certainly does emit a warning for that kind of thing.

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and t…

Isn't the real bug in the example where the bool was assigned to the pointer that a pointer was used where it should have been a reference?

Re: C++ at Google: Here Be Dragons

#70

Post by ori_b »

jonhohle wrote: post #59
DanielRibeiro wrote: post #47

Earlier quoted context omitted.

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

The Polymorphic Inline Caching paper refers to AOT compiling with runtime hints. In the case of non-dynamic languages like C and C++ that clang generally targets, are there other examples of where JIT would make things possible that are not possible in AOT?

Profile guided optimizations that are relevant for the specific invocation of the program. Loop optimization based on invocation parameters for that specific run of the program. Hard-coding in the jump target address for calling functions from dynamically loaded libraries (can't do that AOT, because if the library is replaced, the symbol offsets change).

Optimizing for the specific processor you're running on, as opposed to being forced to compile for a lowest common denominator.

A whole bunch of other small things like that.

Post reply on HN