Lambda the Ultimate

Step a little closer and ask that again...

Yeah, but C++ apps are SO BLAZINGLY FAST!

I think that C++ will have a place in the world so long as people are writing software for embedded systems. The main problem with embedded systems is that you have to program for a cheaper, slower CPU with less RAM. Rarely do you have the luxury of a 3GHz Pentium 4 running with 1GB of RAM.

Off the top of my head, I can recall only one company developing such things, Merlin, but alas, their server seems to be down. They were trying to compile Self to FPGA's. I also read some people discussing embedded Forth applications, though I can't remember where.

...for applications where security matters and performance is not at a premium. On the other hand, if you're writing physics simulations, mathematical or statistical software, or any other of a variety of similar applications, C++ is a nice alternative to C or FORTRAN that allows you to pay only for what you use in terms of abstraction and dynamicity, and allows some degree of compiler interaction via templates. And since it also is fairly easy to interface with Perl, Python, Octave, and most Lisps, you aren't forced to use it inappropriately. IMHO it's a good language for the domain.

This "C++ is unsafe" refrain is a lot like the complaint that "Lisp is too slow" -- both reflect using a good tool in the wrong situation.

If you want raw speed why not use C? Come to think of it, whynot use assembly?

Because C++ is just as fast as C (in fact, there are cases were C++ is FASTER than C), but coding and takes less time, and is easier and less error prone to boot.

Hand-coding assembly is a whole different realm of development. It's fine if you're prepared to spend huge amounts of time to do things that would take only a few minutes in C/C++. It's almost pointless though; the fact is that modern compilers, with full optimizations turned on, will approach or equal the speed of hand-coded assembly.

I think if my only choice is writing a "sufficiently smart compiler", I'll just use the tools I have now -- I need the results in the next month or so, not five years from now ;). On the other hand, Lisp compilers have had since the '60's, and while CMUCL/SBCL generates pretty good code, even with all sorts of declarations and careful coding, it can't reliably match or beat C/++. Ocaml may be a better comparison language, but I don't have enough experience with it to say.

modern compilers, with full optimizations turned on
How much of the "SO BLAZINGLY FAST!" is an implementation issue rather than a language issue?

Would starting from a simple consistent language give more scope for compiler optimization?

2. One of the nice things about LtU is that we realize that deciding which language to use right now for a project is not the same as reaching a conclusion as regards PL technology.

I would say (guess?) that C++ is unique among high level languages in that it lets you "give hints" to the compiler for improving performance.

For example, the keywords const, volatile, switch/case, inline, register and union, are useful for generating fast or small code. Generally, these keywords indicate to the compiler what can and cannot be done to improve performance.

Also, I think that C++, when used appropriately - defensive programming, modules and interfaces, STL, etc - can be a much safer language than you make it out to be. Indeed, done right, the extra safety can be achieved without sacrificing performance.

The Oberon-2 compiler I've used provides these as inline compiler options - they aren't part of the (extremely brief) language definition.

there's a pretty famous study (in lisp circles ;o) saying that lisp is on average faster than c++, but that the very best c++ code beats the very best lisp code: http://www.flownet.com/gat/papers/lisp-java.pdf (but i guess that was fairly early c++).

also, see http://home.comcast.net/~bc19191/blog/040308.html

- 'constant' is an attribute you can sepcify when decalring an object.

- inline is requested using as (standard) prgama statement.

- unions and such can be created by using representation clauses.

etc.

But I think that overall language design is more important. For example, Ada tries to be very careful about introducing aliasing, in order to make optimizations easier, among other reasons.

This really impressed me, since it showed that Lisp can be tortured into giving bare-metal performance. This is really what interests me -- not that the compiler can give me this performance automatically (though it would be nice...), but that the language can, when necessary, allow it. Maybe next project I'll give Lisp another go. This is one reason I've never been a fan of Java, btw. Not only does it provide essentially no added abstraction facilities over modern C++, but the language design itself prevents this sort of targeted optimization. Instead, you have to rely on an absolutely brilliant JIT to fold runtime constants, eliminate bounds checks, etc. It can happen, but it's hard to predict.

lisp is on average faster than c++, but that the very best c++ code beats the very best lisp code

Well, of course I only produce the very best C++ code! I am, of course, among the vast majority of people who think they are above average ;).

No, it won't! You trade speed for safeness. (checks)

A C++ program without /GS /RTCs /RTCc /RTCu will run faster than one where these checks are expected in the implementation of the language (unless you have some option of turning them off).

By the way does anybody know if somebody took a language implementation with lots of runtime checks and compared what improvement in speed can be obtained by removing them?

I personally can live with 9% less speed if I know my running code is being checked for all kinds of possible mishaps.

And we were all so foolish we though you can do checks in zero time. Of course we are. Only C++ programmers undestand language design. So thanks for educating us.

Give me a break. Go read some papers on static analysis, examine some language the provide both speed and safety by allowing the programmer to eliminate those checks that can be safely eliminated (e.g., Ada), and then come back.

"Lisp is slow (NOT!)" references Almabench where we see a marked difference in the performance of Intel C++ and GNU g++. (Note: other benchmarks tell a different story.)

My Oberon-2 compiler provides complete control over the performance of runtime checks.

My Clean (a functional language) compiler provides a way to turn-off runtime index and stack checks (and tune stack and heap size).

improvement in speed
As with any other performance measurement, that would depend on exactly what we were doing.

It does not! The standard (I'm looking at footnote 89 in the C9X standard, but I believe that C89 says the same thing) explicitly states that you can't take the address of a symbol declared as register, whether explicitly or implicitly, and this is regardless of whether or not the symbol is actually stored in a machine register.

It follows from this constraint that a symbol declared as register cannot be an alias for some other symbol. This is a very useful property, and modern C++ compilers may or may not use this information in alias analysis.

What you mean to say is that compilers don't use the hint for register allocation, which is true.

Does that mean that I have to wait 1 hour for the program to compile instead of running it instantly? I am afraid there is no free lunch. Either you check or you don't. And if you do, you do either at compile time or at runtime.

Of course the best would be to be able to enable or disable certain checks and choose whether they happen at compile time or runtime. But who is the masochist that will implement all these options in the compiler? And who makes sure that the programmer makes sane choices about these options? The annoyed programmer will probably disable all checks just to finally make his program compile/run. Which self respecting C hacker uses lint anymore? :)

Now you can start bashing C++ implementators for being too lazy to implement more checks (static and runtime) :-)

Nestor

Ehud: there's no reason to think more advanced languages can't be just as fast (if not faster) if enough resources are spent on building industrial strength compilers.

Right. That myth about C/C++ must go. That's why I keep harping on researchers to build industrial-strength compilers. They can leverage an IL to relieve some of the work involved. Then we can make the right language choice, even on embedded platforms.

Now here's something new to warm Ehud's heart, a comparison of C, C++, Ada, and Java.

The comparison is based on the Ada requirements documents (the steelman), so it's arguably not really fair on the other languages.

With that said, I think the narrow focus on safety vs. speed misses out on the source of C++'s speed. Yes, run-time checks have an impact, but I think the real key is that C & C++ give the programmer explicit control over all the major implementation mechanisms of the language. To name a few, the programmer controls: method calls (virtual/polymorphic or static), inlining (mostly), mutability/immutability, memory management, and perhaps most importantly the exact layout of data structures. Using the cache well can give you an order of magnitude improvement in performance these days.

Since the programmer is in charge, the compiler *doesn't* have to be particularly smart to allow fast code -- C++ only really needs a few simple local optimizations to fly.

Perhaps the biggest win of C++ is that you pay minimal costs for using abstractions. For instance, overhead moving from a raw array of ints to a vector<int> can be arbitrarily small. Contrast that situation with Java, where current VMs can do well on straight-line code involving arrays of basic data types (a lot of the cheesy microbenchmarks look more like FORTRAN than Java), but as soon as you actually *use* the object-oriented facilities of the language, performance goes to pieces.

I look forward to the day when I no longer desire to use C++ -- when some safer and more expressive language has erased the speed gap, or when the expressiveness win totally overwhelmes the runtime loss. I'm sure that many LtU'ers are actively hastening the arrival of that day, but C++-bashing won't help (there are good reasons so many of us are still stuck on it).

I'm not convinced that compiler quality is the issue. C++/C with Classes was winning mindshare with performance long before anybody implemented any exotic optimizations for it. And research language implementations are often the work of compiler geeks -- I'd vote for some ML or Scheme or Haskell gurus over a random vendor's C++ team any day.

Efficient execution, without any particularly exotic compiler tricks, was a major design principle for the entire C/C with Classes/C++ lineage. The languages only include those mechanisms which are efficient (and simple to implement) on common hardware. They bend the programmer's thought to the machine, rather than the other way around.

Many of the more advanced (I assume we're talking in terms of expressiveness, elegance, etc.) languages which we love don't provide those mechanisms: stack or static allocation, manual memory management, unboxed data, mandatory static typing, closed-worldness, and so on.

I'm sure it's been said before: Uniformly high level of abstraction, simple compilation, fast execution -- Pick any two.

I agree. What can help is to learn from languages and projects that target these issues head oh. There are C variants that are safer, and there are languages that are similar to C++ but provide a safe type system (i.e., Ada).

It would be nice if we could take the various explanations and conjectures raised in this thread and test them. I am not aware of good resources for this sort of data. If you are, please share.