Hacker News Reader

Comment by mikepurvis | Hacker News Reader

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.

View on HN

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.

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.

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.)

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.

Reply on news.ycombinator.com