Herb Sutter - Why C++? [now known as rapidcoder's dumb ass comparison with java]

[1vRz3TCk]

Herb Sutter - Why C++?
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

[moorecm]

The GC thread should listen to how managed code at the heart of an OS results in Windows Vista.

[chrisname]

Or SharpOS.

[rapidcoder]

Windows Vista is not any slower than Windows XP or Windows 7, and there is no managed code in the kernel of it. I don't know where you get that crazy ideas from.

Microsoft did some managed OS called Singularity and they claim it is 20-30% faster than native, because all the security is done by managed runtime and not in hardware.

[chrisname]

According to Wikipedia they're still working on it (and have been since 2003).

[1vRz3TCk]

rapidcoder wrote:

Windows Vista is not any slower than Windows XP or Windows 7, and there is no managed code in the kernel of it. I don't know where you get that crazy ideas from.

0_o

[assumes rapidcoder did not watch the video and/or has misinterpreted what moorecm said]

[rapidcoder]

According to Wikipedia they're still working on it (and have been since 2003).

Because this is a research project.

Anyway, all these "C++ renaissance" talks look to me like they are desperately trying to save their jobs. C++ is continuously losing popularity and they simply realized it. Most Android an iOS apps are *not* C++, just face it. Most business software is *not* C++. Most Linux apps are not C++ either. Probably most Windows Phone apps won't be either.

I've recently talked to a friend working on Google infrastructure and he says, they are slowly, but constantly rewriting their old code from C++ to Java. Most database software is I/O bounded - C++ doesn't present *any* advantage over Java for I/O bounded applications, especially that Java has much better support for multicore programming. The only software that brings them lots of $$$$ is also pure Java. Amazon, Facebook, Twitter, LinkedIn - all of them use Java at their cores (even for the low level database stuff).

[chrisname]

I only said they're still working on it because you said "Microsoft did ...", which implied that they were done with it.

I think managed languages will be the future; though I prefer C# over Java.

[Cubbi]

Java has much better support for multicore programming
From what I remember Java's multicore support was very crude (total ordering when completely uncalled for), although I haven't looked into it in a while. With all this Java praise, I am actually curious: will/can Java get anything that could rival the C++11/C11 release-consume memory order? (that's when a store acts as a release fence only on the memory locations that carry a data dependency, instead of releasing everything) I was impressed by it, apparently some OS kernel devs pushed for it to get standardized -- and since I've done that in the past, I can appreciate the idea, although today I'm stuck with dumb intel-compatible hardware where it makes no difference.

[rapidcoder]

From what I remember Java's multicore support was very crude (total ordering when completely uncalled for), although I haven't looked into it in a while

From what I remember, (at that time) C++'s multicore support was nonexistent, although I haven't looked into it in a while.
All you got was a dead slow posix threads library.

With all this Java praise, I am actually curious: will/can Java get anything that could rival the C++11/C11 release-consume memory order? (that's when a store acts as a release fence only on the memory locations that carry a data dependency, instead of releasing everything)

This is left to the JVM. JVM is free to make atomic operations as efficient as possible, without breaking the consistency.
And I'm actually curious, when C++ gets standard and efficient support for: actors, blocking queues, lockless concurrent containers, parallell collections, scheduled executors, persistent immutable collections, lock coarsening and lock elision and lot more things that are required for efficient coding of multithreaded applications. Threads and locking is so.... 1990s.

[hamsterman]

45 minutes of a man saying that C++ is fast. More compelling than one could expect..

On a more serious note, when he gets to 'why', he seems to talk about optimizing by hand. It somehow feels as if that is a C thing and C++ is more about using comfortable hidden mechanisms and hoping that it all turns out okay. I don't really know much about what's important in optimisation, thus "feels".

[LB]

Do people not realise that Java could just as easily be compiled into machine code as C++ could be converted to bytecode and be read by a virtual machine? Sure, the application and usage of languages is a problem, but arguing over core languages in this fashion to me seems...meaningless. I would argue over implementation rather than the language itself, because to me, the implementation is where is matters. Core language problems are an entirely different boat.

[chrisname]

L B wrote:

Java could just as easily be compiled into machine code

It can, see also: gcj

L B wrote:

C++ could be converted to bytecode and be read by a virtual machine

In can, see also: C++/CLI

[LB]

Thus I prove my point ;)

[chrisname]

Agreed, although Java people seem to dislike gcj and I think C++/CLI is horrible.

[hamsterman]

Can you do as many _trivial optimizations in Java as C++? I assume not, which is where the difference comes from.

Although I wonder why hand optimized code is faster than what a compiler normally generates. Don't see why it could not be the other way. Maybe we need higher level languages?

[Catfish]

Not to bash C++ or derail the thread, but those trivial hand-optimizations always bothered me as being out of place. With C++11, that tradition is carried onward with "move semantics", the double reference things that look like an and.

Now, is there a reason why can't the compiler do these things automagically? Maybe const gets in the way? Or is it that people like to feel in complete control over such things?

(As for the Sutter video, I haven't finished watching it yet.)

Edit: text layout.

[rapidcoder]

Agreed, although Java people seem to dislike gcj

Because it doesn't really work. Whenever I checked, it was broken. Albeit, it is slower than Oracle's VM.

For good native Java compiler, look at Excelsior JET. It is just as good as GCC 4.x (C++) or sometimes even better:
http://www.stefankrause.net/wp/?p=9. All is about runtime implementation, not the language.

Now, is there a reason why can't the compiler do these things automagically? Maybe const gets in the way? Or is it that people like to feel in complete control over such things?

Because C++ is a low level language and therefore very complex to automatically optimise at higher level. It gives lots of freedom to a programmer, but at the expense of taking away that freedom from the runtime / compiler. Therefore, most benchmarks comparing C++ performance to Java performance are comparing hand made C++ optimisations to compiler made Java optimisations. However, if you tried to write an elegant and straightforward C++ code using e.g. STL and Boost, without resorting to lowlevel code obfuscating optimisations and compared *that* to equivalent, elegant Java or Scala code, I'm sure in many of the cases Java / Scala would beat C++ by a wide margin.

[Cubbi]

rapidcoder wrote:

if you tried to write an elegant and straightforward C++ code using e.g. STL and Boost, without resorting to lowlevel code obfuscating optimisations and compared *that* to equivalent, elegant Java or Scala code, I'm sure in many of the cases Java / Scala would beat C++ by a wide margin.

I am sure of the opposite, there's no way Java can beat C++ templates at producing efficient code. Give an example. It may approach it, with a particularly smart compiler, but it's always starting from the disadvantageous position. The C++ std::sort() beats C's std::qsort() in the usual cases for the same reason.

rapidcoder wrote:

It gives lots of freedom to a programmer, but at the expense of taking away that freedom from the runtime / compiler.

My experience has been the opposite: C++ compilers have more freedom. They are even allowed code transformations that change visible I/O in some cases, not to mention free reordering of subexpressions. Java's evaluation rules are rigid. Again, give an example.

[rapidcoder]

I am sure of the opposite, there's no way Java can beat C++ templates at producing efficient code. Give an example. It may approach it, with a particularly smart compiler, but it's always starting from the disadvantageous position. The C++ std::sort() beats C's std::qsort() in the usual cases for the same reason

C++ templates are known for code-bloat and wasting code cache. It is a double-edge sword. Little templated code = great performance. Too much templated code = poor performance, huge executables and long compile times. You have to be a very advanced programmer to write both fast and readable templated code. Put some sharedptrs here and there, and all your top-performance is gone.

Java theoretically is able to do the same optimisations as C++ templates (= code specialization and call site code inlining), except it can be smarter about not blowing out the L1 cache, because it can specialize just the hotspots (usually loops), not the whole classes / functions. Currently, it is not implemented fully, though. These optimisations will be fully supported probably at some time in Java 7 or Java 8, as part of invokedynamic feature [1]; I don't know if they finished doing them yet. Anyway, currently, even on Java 6, the Collections.sort works just as fast as C++ std::sort (within a 5% measurement error margin), and 10x faster than C's qsort. So wrong example.

But let's modify the example slightly. Put the sort comparison function in a dynamically loaded module. Now all your performance advantage of templates breaks apart. Java perfectly inlines such call, even if it is virtual and accross module boundary. C++ doesn't. C++ is good for monolithic software. But where modularity comes into play (e.g. dynamically loaded extensions or plugins) or heavy OOP with lots of inheritance and virtual calls, it stands no chance.

Anyway, templates are usually a means of code optimisation, because most programmers can't use them. Most programmers by "readable code" uderstands pure OOP code, using virtual calls, and no templates (except maybe using standard STL containers and std::string). Google and Mozilla forbid most of STL and Boost for stability and performance reasons. So let's do another excercise: write that sort method using pure OOP (just like in Java) and your sorting performance drops even below that of C's qsort.

So to conclude: Java optimizes pure OOP code better than C++. On the other hand C++ templates are (currently) optimised heavier than what Java can do and sometimes, to some degree, they can still deliver performance advantage over pure OOP equivalent. But most of programmers have no problems writing pure OOP code, while only very few can grasp templates and use them *efficiently*.

[1] http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fwww.wiki.jvmlangsummit.com%2Fimages%2F3%2F3e%2F2011_Nutter.pdf&ei=C1EIT7qTHo7QsgbKkbiBDw&usg=AFQjCNFa0gKkdkFGq9I5pkQwO_kiP1X6hQ&sig2=TtuzKeaW1RAw8nG0f6iX0A