3 ms·

> What I would like to see is more of an attitude change among high level language designers and their communities. The reason a language like C makes obvious

> What I would like to see is more of an attitude change among high level language designers and their communities. The reason a language like C makes obvious code fast is because C has very little expressive power. The lack of power strongly encourages the programmer to think imperatively and code at a very low level. Apply this to an extremely trivial problem (mere addition - does it get any simpler?), and of course you end up with fast code. The lesson doesn't generalize. The lack of expressive power means higher level abstractions are clumsy to write, refactoring is more expensive, and recomposing your program with e.g. a caching layer is much harder. See https://blog.codinghorror.com/on-managed-code-performance-again/ https://blog.codinghorror.com/on-managed-code-performance-ag... for example (alas, it appears some of the original source blogs are gone) - Raymond Chen wrote a dictionary in C++, Rico Mariani implemented it in C# and and got great performance with the obvious solution.

tedunangst 8y ago
But isn't the point that sufficiently smart compilers are supposed to compile to faster than C?
- barrkel 8y ago
  Are you being facetious? :) "Sufficiently smart compiler" - http://wiki.c2.com/?SufficientlySmartCompiler 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.
  - jstimpfle 8y ago
    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.
- maxxxxx 8y ago
  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.
  - saagarjha 8y ago
    > 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…
    - gameswithgo 8y ago
      I've never seen in practice any jit do better than hand tuned AOT compiled code.
      - saagarjha 8y ago
        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.
        maxxxxx 8y ago
        “occasionally” That’s the keyword here.
        saagarjha 8y ago
        I was responding to a comment that had the word "never" in it.
      - 8y ago
kingaillas 8y ago
>See https://blog.codinghorror.com/on-managed-code-performance-ag.. 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/performance-quiz-6-chineseenglish-dictionary-reader/ https://blogs.msdn.microsoft.com/ricom/2005/05/10/performanc...) are here: Raymond Chen's posts: https://devblogs.microsoft.com/oldnewthing/20050509-30/?p=35683 https://devblogs.microsoft.com/oldnewthing/20050509-30/?p=35... https://devblogs.microsoft.com/oldnewthing/20050510-55/?p=35673 https://devblogs.microsoft.com/oldnewthing/20050510-55/?p=35... https://devblogs.microsoft.com/oldnewthing/20050511-46/?p=35663 https://devblogs.microsoft.com/oldnewthing/20050511-46/?p=35... https://devblogs.microsoft.com/oldnewthing/20050513-26/?p=35643 https://devblogs.microsoft.com/oldnewthing/20050513-26/?p=35... https://devblogs.microsoft.com/oldnewthing/20050516-30/?p=35633 https://devblogs.microsoft.com/oldnewthing/20050516-30/?p=35... https://devblogs.microsoft.com/oldnewthing/20050518-42/?p=35613 https://devblogs.microsoft.com/oldnewthing/20050518-42/?p=35... https://devblogs.microsoft.com/oldnewthing/20050519-00/?p=35603 https://devblogs.microsoft.com/oldnewthing/20050519-00/?p=35...
gameswithgo 8y ago
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.
- barrkel 8y ago
  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.

tedunangst 8y ago

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

barrkel 8y ago
Are you being facetious? :) "Sufficiently smart compiler" - http://wiki.c2.com/?SufficientlySmartCompiler 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.
- jstimpfle 8y ago
  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.
maxxxxx 8y ago
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.
- saagarjha 8y ago
  > 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…
  - gameswithgo 8y ago
    I've never seen in practice any jit do better than hand tuned AOT compiled code.
    - saagarjha 8y ago
      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.
      - maxxxxx 8y ago
        “occasionally” That’s the keyword here.
        saagarjha 8y ago
        I was responding to a comment that had the word "never" in it.
    - 8y ago

kingaillas 8y ago

>See https://blog.codinghorror.com/on-managed-code-performance-ag.. 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/performance-quiz-6-chineseenglish-dictionary-reader/ https://blogs.msdn.microsoft.com/ricom/2005/05/10/performanc...) are here: Raymond Chen's posts: https://devblogs.microsoft.com/oldnewthing/20050509-30/?p=35683 https://devblogs.microsoft.com/oldnewthing/20050509-30/?p=35... https://devblogs.microsoft.com/oldnewthing/20050510-55/?p=35673 https://devblogs.microsoft.com/oldnewthing/20050510-55/?p=35... https://devblogs.microsoft.com/oldnewthing/20050511-46/?p=35663 https://devblogs.microsoft.com/oldnewthing/20050511-46/?p=35... https://devblogs.microsoft.com/oldnewthing/20050513-26/?p=35643 https://devblogs.microsoft.com/oldnewthing/20050513-26/?p=35... https://devblogs.microsoft.com/oldnewthing/20050516-30/?p=35633 https://devblogs.microsoft.com/oldnewthing/20050516-30/?p=35... https://devblogs.microsoft.com/oldnewthing/20050518-42/?p=35613 https://devblogs.microsoft.com/oldnewthing/20050518-42/?p=35... https://devblogs.microsoft.com/oldnewthing/20050519-00/?p=35603 https://devblogs.microsoft.com/oldnewthing/20050519-00/?p=35...

gameswithgo 8y ago

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.

barrkel 8y ago
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.