Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

Rust fell into the same trap that killed many, many gamedev companies:

Performance matters. Even more than features.

It depends what kind of performance. The only performance they are "lacking" seems to be compilation speed (an annoyance, but they're working on it) and compilation memory usage (rarely a problem, considering we also have C++, Java and C# around :) ).

The performance of the compiled code is great, and the performance of the compiler is something they have identified as a major issue to fix, and are working to solve it.

So did the now-dead game companies.

Performance is like money: it's easy to squander and hard to acquire.

So...which game companies?

Really? I'm pretty sure for most game companies, shipping is king and everything else is secondary.

Also, have you seen gameplay footage of in-development titles, particularly older ones before the days of Unity and UE4? Usually they're choppy as hell because the engine is under development at the same time as the game, and devs prioritize getting a golden but slow codepath working first so that the artists have something to go off of, and all the optimizations are shoved in to recover framerate in the months right before release.

> Performance is like money: it's easy to squander and hard to acquire.

In this case, there were several decisions to not care about performance right now in order to emphasize correctness and shipping faster, while making sure there are no technical obstacles to making compilation faster in the future. The main time sink in Rust compilation is that all the abstractions in the Rust code get compiled into the initial bytecode representation passed to the LLVM side, and they are only reduced there, instead of cutting down on the hierarchies on the Rust side. This costs performance in several places -- the creation of all the bytecode, the copying of it, and then LLVM parsing it all in. The upside of doing it this way is that it makes the Rust-specific compiler much simpler and easier to implement, and that the optimizations that remove the towers of abstraction on the LLVM side are extremely well tested.

As Rust matures, optimizations that reduce the complexity of the created initial LLVM bytecode can be, and probably will be done on the Rust side.

You are equating two non-comparable things, Rust the language and gamedev companies using an abstract concept (performance). It could be a lede for an opinion piece or an essay, but it isn't an argument.

Is that still true? PUBG is probably the worst-optimized game ever written, barely getting 60fps on a setup that can run Overwatch at 200+ fps. And yet, it's the most-played game on Steam.

As someone who plays PUBG, I think it's in spite of performance not for irrelevance of performance.

Are you implying that Rust isn't performant?

If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.

Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.

So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters.

Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.

Python is slow as fuck.

All the heavy API and computation libraries are wrappers are C binaries that are optimized to death.

A fast edit-compile-run cycle makes development a lot more efficient in my experience.

Right, definitely! But in that case, it's really incremental build time that's the important thing. Not that overall/first build time isn't important too, but in general I'd rather see my incremental build go down by 80% than my first build go down by 20%, and I think this is reflected in where the Rust team has historically applied their perf efforts, eg: https://blog.rust-lang.org/2016/09/08/incremental.html

(Appreciating as well that most incremental build gains come from avoiding unnecessary work, so they're as much the domain of the build system as they are of the compiler.)

What languages do you come from? What is fast compilation for you?

The compilation phase can take hours in C++. Up to a day when compiling huge projects will all the optimization flags.

Live that for some time and it will quickly prove you that you were wrong. Compilation time matters.

Fast compilation: less than a second (feels like not waiting at all)

Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time)

To have fast compilation even with big projects is hard. Go, C, and D are usually fast. Scala is usually slow.

I care about development builds primarily. The edit-compile-test loop must be really really fast. Optimization flags are irrelevant, because if performance matters you often must have them enabled for development as well.

This is off topic a bit, but there is a solution for this:

> Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time)

See the thread here: https://askubuntu.com/questions/409611/desktop-notification-...

TL;DR install undistract-me, add 2 lines to bashrc, and you will get a desktop popup when a command that takes longer than 10 seconds to complete is finished.

Fedora does this by default on install and I have found it so handy. Kick off a compile etc, then just browse HN/reddit til I get the popup.

Yes, this helps a little. As a fish user, I had to write more than two lines [0] though. A second monitor is detrimental, because the notification is too far away sometimes.

[0] https://github.com/qznc/dot/blob/master/config/fish/config.f...

I don’t think people are saying compilation doesn’t matter. Certainly, I would consider C++ to be a language that is at the high performance end of the spectrum. High performance languages, high level languages like C++, Rust, Ada, Haskell, Ocaml, And Swift have relatively long compile times but I would classify them as languages suitable for applications requiring high performance. Go is an interesting exception in that it produces pretty high performance results without long compile times.

But you do have a point. Things are so much better now than when I started programming 50 years ago. Machines and languages are so much better. Programming is a dream compared to back then.

Right, but the problem is that - in the OpenBSD world - it's a price that's paid much more than once. Sure, that binary might be run millions of times, or it might be run only tens or hundreds or thousands of times before an update comes around. And that's just for one platform; OpenBSD supports lots of platforms, both 32-bit and 64-bit, and all of them are expected to be fully usable for (among other things) developing OpenBSD (which includes, you know, actually compiling OpenBSD).

To rephrase that a bit: OpenBSD is designed to be a system where any user on any platform can contribute to OpenBSD using the tools included in OpenBSD's default install. Deviations from that will almost certainly receive a cold reception at best.

Reply on news.ycombinator.com