Hacker News Reader

Comment by derefr | Hacker News Reader

C++ is the only language I'm aware of where every extension made to the language is careful to only affect compilation time/complexity, while preserving the speed and operational semantics of the code at runtime. This makes it perfect for some domains, e.g. console game development, where the speeds required are only attainable by dicking around with pointers in C, but people want to use better abstractions than C is capable of. So no, continuing to add those extensions is not wasted effort; we'll still be learning and using them long into the future.

View on HN

This is thing that annoys me about C++'s illusion of control: unless you have / take full responsibility over the compiler and standard library, the "control" that C++ gives you is actually an abnegation of choice which leaves you to reinvent the world if you want specific features. What if you want something like Smalltalk / Lisp images? Runtime code generation and optimization of virtual method calls? Precise garbage collection? C++ leaves you on your own if you want these things in your final executable, and you have to work very hard - to the point of implementing a DSL, or writing / modifying your own C++ compiler - if you do want them.

"What if you want something like Smalltalk / Lisp images? Runtime code generation and optimization of virtual method calls? Precise garbage collection?"

What is the point of controlling all of those things? The GP was talking about speed - how are GC, JIT and images related to this?

Precise GC, JIT and images all give you more speed.

Precise GC is asymptotically more efficient than manual allocation; you need to use other approaches, like arenas, to get back that lost time, but they are not always applicable or easy to introduce.

Optimizing virtual method calls at runtime (e.g. monomorphic or polymorphic inline caches) is rather awkward without JIT. Similarly, C++ templates cannot be instantiated at runtime, meaning less efficient, more general and indirected code needs to be used instead.

Images optimize startup hugely: they completely remove the need for any initialization not directly related to acquiring external resources. For example, this is one of the biggest reasons Chrome is so quick to start up - it uses freeze-dried heaps in V8 (its Javascript engine).

Ok, but:

1. GC is fast at the cost of using more memory, which it turn slows the entire app down. 2. JIT can do all those optimizations, but how many of them are done in practice? How fast is the software compared to a binary compiled in C or C++? 3. Can be useful, but the only software that I've seen having trouble with startup times in the first place is written in .NET and Java :)

I guess that what I'm getting at is that C++ code is still faster than e.g .NET code even if C# has GC and JIT. In the end that's all that matter, not whether you can do optimization X.

.NET code is C++ code. The CLR is written in C++. In many ways this kind of argument is pointless, because it's really about a way of creating a piece of software, than particular to any one language. But some languages make life really hard here - in C++, you need to build a runtime.

I'll assert that memory is not normally a constraint in most situations that need to scale (i.e. not constrained clients), these days. (Though I will say I have noticed that Firefox 4 is significantly slower than FF 3 when switching tabs, and I believe it's because of memory reduction optimizations they've put in because of everybody moaning about bloat. I'd prefer it use more memory and less CPU.)

JIT optimizations like PICs? For over 20 years. The benefits are magnified in languages that make many operations virtual, so you see it in things like Smalltalk (very long time), Javascript (Chrome's V8) and Java JVMs (methods virtual by default so it's a win).

Re slow startup - you're deluding yourself if you think there isn't much software that doesn't have startup time issues. I need only restart any machine I have to know how slow initialization is; with HDD transfer rates in excess of 100MB/sec, there's no good reason for it to take more than 10 seconds or so when no hardware has changed. You're simply not aware of how much faster things could be if startup were faster because you're used to how slow everything is. You just know you can't e.g. fork utility X more than 200 times a second in a script, but don't realize it might be 10 or 100 times faster with a different approach.

That C++ doesn't impose, but does permit these runtime features is what allows it to adapt to such a wide variety of constrained environments. Baking those features into the language can certainly be much cleaner, at the cost of versatility.

We need system level languages and C++ currently stands alone in its combination of powerful abstractions, low level control, and ecosystem size, though it certainly has competition in these aspects individually.

I don't doubt that a language could be everything C++ is and much cleaner too, but that is a big challenge that relatively few language designers want to take on.

C++ takes a very simplistic view of runtime performance, however. Generics are implemented using templates; which instantiates the code for every type you use. Naively, this preserves the performance of simply writing the same code for each type (which is what you did before templates). However, that might not be the best performing way to implement generics at runtime.

(Edit: Small change to make meaning clearer)

Huh? Templates in C++ are pay-for-what-you-use; only those instantiations required by your code are generated.

Note also the ability to extern templates added in C++0x, which allow you to collapse common instantiations to a single object file.

How do those features impact runtime performance?

One example of templates affecting runtime performance is poor use of the instruction cache due to code duplication in every instantiation of a template.

If you are instantiating equivalent functions (sorting foo* vs sorting bar* ) then the linker will merge their binaries -no dupes there. If you are generating different functions (sorting foo vs foo* ) then you are asking for different functions -no dupes there either. If you want to keep everything down to one function, qsort() didn't disappear when they added std::sort() and it is pretty close to what a dynamic language sort would do under the hood.

Some linkers do what you describe. Not all.

I believe this is called Identical COMDAT Folding in VC++

C++0B maybe?

Reply on news.ycombinator.com