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

71–80 of 91 posts

Re: C++ at Google: Here Be Dragons

#71

Post by pbiggar »

DanielRibeiro wrote: post #43
irons wrote: 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.

LLVM isn't really a JIT, and I've never heard of people using it as one for C++. (Also, those that tried to use it as a JIT had lots of problems, like Unladen Swallow).

Re: C++ at Google: Here Be Dragons

#72

Post by pbiggar »

chancho wrote: post #45
DanielRibeiro wrote: post #43

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?

One nice thing JITs can do that AOT compilers can't is on-stack replacement. That's where you recompile a particular function at run-time based on new information. This allows you do speculative optimizations.

For example, you might see that branch X is always taken. So you assume that X will always be true, and add a guard just in case which triggers a recompilation. You reoptimized the function on the basis of your new (speculative) information about X. This could improve register allocation, allow you remove lots of code (other branches maybe), inline functions, etc.

Java JITs have been known to inline hundreds of functions deep with this.

Re: C++ at Google: Here Be Dragons

#73

Post by olavk »

swannodette wrote: post #28
profquail wrote: post #21

Earlier quoted context omitted.

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

Those in favor of only static typing and those in favor of only dynamic typing are living in the past. Any interesting evolution in programming languages will allow developers to program with and without types / contracts from the same language.

In Mascara (my own project) you can start out with dynamically typed JavaScript, but then gradually add type annotation as appropriate to provide stronger verification. It can be done using structural types without changing the runtime semantics, and further by rewriting to use classes and nominal typing.

I think this provides a useful upgrade path, because type verification is a hassle with small projects, but becomes increasingly valuable (IMHO) as the program grows.

The problem with current languages is that you have to decide upfront if you want a language optimized for quick development or strong verification. But often in the real world, programs start out as quick prototypes, and then grow into large applications.

Re: C++ at Google: Here Be Dragons

#74

Post by zoul »

nradov wrote: post #27
michaelcampbell wrote: post #25

Earlier quoted context omitted.

I hear you, but I think the rest of the world is actually polarizing to some degree. Perhaps I'm just fickle or a language whore, but I love both the dynamism and freedom of Ruby (et. al.) and the "protect me from doing stupid $#@!" of Scala (et. al.) Although honestly, I don't know that I'd want a language that supported both, if even such a thing were possible. I do see a lot of people getting all hung up on one si…

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 might be interested in the type system of Perl 6:

    subset Filename of Str where { $_ ~~ :f };
Here you define the Filename type as a string that represents an existing path. This particular example is a horrendous hack of course, but the tool looks very interesting. Not sure if this can be used for performance tuning in existing P6 implementations.

Re: C++ at Google: Here Be Dragons

#75

Post by rjh29 »

zoul wrote: post #74
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 might be interested in the type system of Perl 6: subset Filename of Str where { $_ ~~ :f }; Here you define the Filename type as a string that represents an existing path. This particular example is a horrendous hack of course, but the tool looks very interesting. Not sure if this can be used for performance tuning in existing P6 implementations.

That's a horrible hack indeed :)

Perl 6 does have 'gradual typing' though. You can define a variant:

  my $foo;
or a typed variable:

  my Int $foo;
or a subtype with arbitrary restrictions

  subset OneToTen of Int where { 1
Or... (http://rosettacode.org/wiki/Define_a_primitive_data_type#Per...)

  subset Prime of Int where { $^n > 1 and $^n %% none 2 .. sqrt $^n };
Perl 6 scares me.

Re: C++ at Google: Here Be Dragons

#76

Post by axman6 »

spitfire wrote: post #50
cageface wrote: post #35

Earlier quoted context omitted.

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.

I seem to remember there was a pretty interesting web framework written in Ada, Adaweb I think?

Anyway, Ada has some other amazingly cool features. The concurrency primitives it offers are very cool, lets you make some much stronger guarantees about the interactions between threads than any other language I've seen. For example, you can define rendezvous sections, which if memory serves, are pieces of code that are guaranteed to only be run once both threads participating in the rendezvous and neither thread can leave the section until both are ready.

Re: C++ at Google: Here Be Dragons

#77

Post by wisty »

tedunangst wrote: post #20
jrockway wrote: post #7

Earlier quoted context omitted.

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

And Linus's feelings about that relationship are...?

Pragmatic, I would guess.

"Quite frankly, I'd like there to be more competition in the open source compiler game, and that might cause some upheavals, but on the whole, gcc actually does a pretty damn good job."

http://kerneltrap.org/Linux/Volatile_Performance

Re: C++ at Google: Here Be Dragons

#78

Post by regularfry »

profquail wrote: post #21
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 .

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

After a few years of fence-sitting doing a lot of ruby, I find myself... still sitting on the fence. My next project will probably be in erlang and haskell, for what it's worth.

Re: C++ at Google: Here Be Dragons

#79

Post by adestefan »

roel_v wrote: post #66
jrockway wrote: post #7

Earlier quoted context omitted.

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?

The biggest one is (was?) the use of GNU variable length arrays. The GNU extension has different syntax than C99's variable length arrays. There are also instances of __attributes__ on platform specific code.

Re: C++ at Google: Here Be Dragons

#80

Post by lolcraft »

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 .

C++'s typing is fairly weak. Most of the errors shown in the article were weaknesses of the type system. Now Haskell, or even Java...
Post reply on HN