Rust managed to make some of these high level abstractions compile to fast machine code almost every time. Its quite refreshing to go from Linq/Streams etc to Rust iterators.

So does C++ iterators for that matter but they are not so pleasant to actually write.

It's true. Rust's approach to passing lambdas to iterators usually gives the compiler good info to inline. Some of my exercise programs when learning Rust exceeded fairly straightforward C implementation too, possibly due to stronger guarantees around aliasing.

>See https://blog.codinghorror.com/on-managed-code-performance-ag.... for example (alas, it appears some of the original source blogs are gone)

They are there... it's just the recent migration at MSDN blogs broke a lot of links. Basically it looks like Rico doesn't blog anymore (no longer at Microsoft) so his blog is archived and links to it work, but Raymond Chen's blog is active and was moved en masse to new links.

The links from Rico Mariani's blog (https://blogs.msdn.microsoft.com/ricom/2005/05/10/performanc...) are here:

Raymond Chen's posts:

https://devblogs.microsoft.com/oldnewthing/20050509-30/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050510-55/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050511-46/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050513-26/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050516-30/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050518-42/?p=35...

https://devblogs.microsoft.com/oldnewthing/20050519-00/?p=35...

But isn't the point that sufficiently smart compilers are supposed to compile to faster than C?

Are you being facetious? :) "Sufficiently smart compiler" - http://wiki.c2.com/?SufficientlySmartCompiler

Don't get me wrong, I like C - especially on small problems. I don't get the feeling that I'm creating something flexible with C, though, it's very much bespoke and tailored. I get involved in micromanagement of fine details. This is OK for a small problem, but extremely aggravating for a big problem. As soon as I want higher level abstractions, and start building structs of function pointers and whatnot, I just shake my head - I'd rather write a parser and corresponding text generator than manually compile that into C.

C++ has been hobbled by the concept of a sufficiently smart compiler. It's so afraid of introducing abstractions that aren't cost-free, it tries to make them all optional, and the resulting explosion in feature combination means some combinations don't work well together, and then every big C++ project has to decide which set of features they'll adopt, and which ones they won't.

Give me the freedom to think closer to the problem, and even if the abstractions have some costs, and even if the compilers aren't quite sufficiently smart, the chances are I'll come up with algorithm improvements that meet speed and space requirements and let me move on to the next problem much sooner. Agility trumps hyper-optimization.

According to some people, the problem is the data. C is a nice language for dealing with plain data.

Just today I rewrote my own streams abstraction, because libc sucks and I want to support my own printf style functions and my own custom streams (for example dynamically memory allocating streams. fopencookie() is not portable). I think that streams are one of the most abstract and most useful abstractions. It went pretty good. Making a few vtables explicitly in a few places is not that terrible.

That has been the dream for a long time. When Java introduced JIT (Hotspot?) a lot of people claimed that Java was faster than C. Lately people are telling me that JavaScript "can" run faster than C. Usually they present some well written code in their favorite language and then compare it to horribly written C. Usually I tell them that most likely the runtime of their language is written in C so you can always do as well in C.

> Usually I tell them that most likely the runtime of their language is written in C so you can always do as well in C.

The point is that with a JIT the runtime is executing as little as possible, with the rest being dynamically optimized machine code. So this isn’t really a fair thing to say…

I've never seen in practice any jit do better than hand tuned AOT compiled code.

I've seen lambdas and virtuals inlined dynamically. AOT would need to be statically typed and instantiated all the way to do the same thing.

I could create a sample program that would be hard to make as fast in C or C++, with the constraint that the code needs to be dynamically loaded at runtime.

In practice, it's easier to modify a more dynamic program and be sure you're not breaking much. Highly tuned C tends to bake in assumptions about memory lifetime, layouts, call graph, etc. The flexibility to modify is what gives you the ability to target higher level improvements in a shorter amount of time.

Given any concrete implementation, after it's been designed in a more dynamic language, you can convert it to something fast in something like C. But starting from C is probably not a great idea. And not everything can be written multiple times economically.

E.g. the .net GC was prototyped in Lisp, and initially converted to C++ with a translator.

I have, try to make an AOT compiler remove dynamic dispatch across shared libraries and convert it into either direct calls or even inline them.

It's rare, but it can happen occasionally. A just-in-time compiler has access to tracing and profiling that a ahead-of-time compiler may not, which means that it can do things like inline a virtual method call that is actually monomorphic at runtime.

“occasionally”

That’s the keyword here.

I was responding to a comment that had the word "never" in it.