Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

"We are heading back to the days of 640k barrier or the old C-64 days. It was amazing how efficient programs were and the genius of the software engineers."

I think software is already getting there, since we've been dealing with slowing returns for a while. The previous generation of languages like Python, Perl, Ruby, etc. traded convenience for performance and waited for hardware to catch up. It was a good trade in many cases at the time, but as we collectively learned more about the design space I think it has become clear that it is not an intrinsic trade; it is possible to get a more convenient language that we had in the 80s or 90s without trading away performance.

LuaJIT was an early example of this, but the flood gates are opening now. Go is not architected to the nth degree for speed, but it's a language that's only slightly slower than C, and in my experience, only slightly slower to develop in than Python (possible with a crossover point as the program size grows where Go is simply faster). Rust ought to be a lot easier to work with than C++ once you learn it, and I expect it to reach near-optimal speeds, possibly even beating C/C++ in practice as it will be more feasible to perform some aggressive optimizations for multithreading. And I've noticed a lot of the other little bubbling languages that may become languages of the future, like Nimrod, have the same sort of focus in them, "how can we get these convenient features without a 20-100x speed penalty"?

Then, once you have these languages, I'm noticing that in many cases while bindings exist, entire stacks are being rewritten to be simpler and faster. Go has its own webserver. Dollars-to-donuts Rust will too in another couple of years. I suspect this is actually part of the trend; rather than binding to older, huge frameworks and code written without much concern for latency issues, etc, more code is going to start being rewritten to care more about those things. Between mobile pressing us on one end and desktop speed advancement stalling out on the other, there's increasing motivation to write faster code where it matters, without necessarily having to use C or C++.

I'm not saying paradise is incoming, but I get the impression that we're seeing more care about performance manifesting in real languages and code than we used to.

Pretty much every competitor I've ever seen for C/C++ has always made the same claim: with X optimization that C/C++ can't do, we can eventually meet or beat C/C++.

It's never actually came true in the general case. ever

You're thinking of the previous generation that I was referring to. "We can create languages that do whatever we want, but Sufficiently Smart Compilers will make it as fast as C!" This has become a joke. Justifiably.

The new generation that I'm referring to is more like "Well, that didn't work. Let's design nicer languages, but think about performance impacts up front this time." Go is pretty fast now, for instance... not C-fast, but not Python-slow or Javascript-slow; it's closer to C than those, even on a log scale. Lua-JIT is an early example, where I believe the design of Lua was fundamentally based on what could be done quickly, rather than what could be done nicely. You can still have nicer languages that incorporate our years of progress since the 80s/90s, but if you think about performance from day 1, they can also run pretty quickly, too. They may not be quite as nice as the scripting languages, but then, we also know ways of making up for that too, so in the balance I like them better even so.

(And A: Yes, Javascript is still slow, even after all the browser work. It's just "not as slow as it used to be"; consider, if Javascript was so fast, how does asm.js post such improvements over it? Answer: JS is still slow. And asm.js is still about 2x slower than C, last I knew, after all. B: I no longer believe "languages aren't slow, only implementations are", as, proof-by-construction, the last 10-15 years produced plenty of languages that appear to be, yes, fundamentally slow. Those who wish to argue may produce your choice of general-C-speed compiler or interpreter for Javascript, Python, Perl, or Ruby. After I-can't-even-guess how much effort has been put into speeding these up, I say I'm allowed to draw conclusions.)

No I'm not, those new-fangled compilers with that fancy ass "think about performance up front" language doesn't have the umpteen years and billions of dollars worth of research put into it the way C++ has.

If you want all the advantages of C++ compilers, you can write a backend for the language's compiler that generates C++. If the language is actually performance-focused, there shouldn't be any semantic mismatch in doing so; for example, every Rust type should be able to be translated 1:1 to a (much more syntax-laden) C++ type.

The new-generation languages (of which Go is a bad example; Rust and Nimrod, and now Swift, are much better ones) don't attempt to get the computer to do the kind of magic at runtime (garbage collection, type reflection) that made previous-gen languages so slow.

Instead, these NGLs start with the assumption of C/C++ runtime semantics, and then, through extra work done at compile time (e.g. type inference, ownership-tracking) clear away as much implied/redundant/unneeded syntax as possible.

> If you want all the advantages of C++ compilers, you can write a backend for the language's compiler that generates C++.

Well it sounds as if it's as simple as being able to take advantage of optimizations to meet or beat C++.

good luck with that.

Also, FYI: Nimrod is garbage collected, which goes counter against your reasoning.

It's much simpler than that. It actually makes writing a compiler easier as you have higher level abstractions to work compared to generating machine code. There are many languages that compile to C which should prove to you that it can be done. I don't see why targeting C++ would be any different and I'm sure there are languages already out there that do.

You can compile any language down to C or C++, but that doesn't mean that it will run as fast as well-optimized C/C++.

The moment you include dynamic dispatch, auto-conversion to big integers, or one of a zillion of other high-level features without also introducing ways for the programmer to indicate how the compiler should implement them, you give up being just as fast as C/C++.

Yes, the difference may be small, and spending time on improving your compiler can make it smaller and smaller, but for any 'real world program', it won't be zero.

The same is true for C vs assembly, but there, the difference mostly _is_ small because C has none of those high-level features.

Also, few people have the skills and the time to wrote well-optimized C/C++.

bam, nailed that shit, especially the point about performance costs inherent in a feature set rather than in a language.

I just didn't want to continue a conversation with someone who thinks adjusting the age old "optimizations will eventually make it as fast" to be "compiling to C/C++ as an optimization will eventually make it as fast" was somehow going to magically make it come true.

It's the same old argument reskinned, and as you pointed out, the feature set has a lot to do with it.

I said nothing about "compiling to C/C++ as an optimization." I said targeting C++'s semantics (i.e. having only features C++ already has) makes a language fast.

https://news.ycombinator.com/item?id=7921511 > If you want all the advantages of C++ compilers, you can write a backend for the language's compiler that generates C++.

investment in C++ compiler technology has been shared in form of llvm with rust and other languages.

LLVM is not a C++ compiler, CLANG is a C++ compiler frontend that uses LLVM as it's backend.

Significant difference there.

Go is already fast enough, I can implement parallel systems where the limiting factors are hardware-architectural. It's hard to efficiently use all of the available parallel computing power. Erlang does the best job of it now, but there is certainly room to wrest even more performance out of the same number of transistors. Multiple cores pretending to be "the" CPU stinks.

Fortran

Be careful using LuaJIT as a representative example for anything. Not every language implementation can be written by a human super-optimizer like Mike Pall!

But yeah, people have a better idea now of what features need to be built into a language to get good performance, and Rust shows off many of them.

Finally, nostalgia for the old days often includes a failure to remember the many limitations of software back then.

LuaJIT was an early example of this, but the flood gates are opening now.

Smalltalk was an early example, but the community made the wrong mindshare choices and it never lost the "slow" reputation. Java still experiences some of the same dynamic.

> Dollars-to-donuts Rust will too in another couple of years.

I believe the project to follow is "Teepee", which is being developed by the person who wrote the quick-and-dirty "rust-http".

Reply on news.ycombinator.com