Hacker News Reader

Comment by noelwelsh | Hacker News Reader

Right, but compilation performance is not a race in which you have to be first, but a minimum threshold that you must meet. Compilation just has to be fast enough that it doesn't annoy developers most of the time. Once you achieve that they'll mostly stop complaining. I believe Clang et al are fast enough.

(This is true for performance and optimisation is general: fast enough is good enough.)

View on HN

Compiling larger projects, I certainly do not feel that Clang et.al. are fast enough. It takes minutes to compile stuff at work with 32 Xeon threads powering through at full load.

Once it takes seconds, we can talk about "fast enough".

Try using Scala :)

Is that minutes for every compile, or for an (infrequent) full compile?

Not the commenter you're responding to, but at my previous place I dealt with compile times of around 20 minutes from scratch, and 1-2 minutes incremental using Clang/LLVM, on a 20ish physical core Xeon with 128ish gigs of RAM.

Ok, that is pretty slow.

Heavy use of templates does that to you :(.

Not to pick on you or the parent comment, but this is a such a common mistake that it's worth correcting.

"Clang" is a thing not a person, therefore it's appropriate to use et cetera, not et alii. The former is for things, the latter for people (usually limited to authors of academic papers).

I interpreted that as a deliberate and sassy way to write. It's as if I said with Python et al. eating its lunch, Clojure better light a fire under its own ass.

et al. refers to a group of authors working together, so I would say a phrase like "Python et al. eating its lunch" is simply wrong.

comex's research above would appear to disagree.

Language evolves. The original authors' intent was conveyed much better, in my view, by 'et. al.' then it would have been by 'etc.' given the shift in how that latter phrase is used.

I Googled it, and the results were about evenly split on whether "et al." primarily stands for "et alii" (masculine) or "et alia" (neuter). But they agree that it can stand for either of those, as well as "et aliae" (feminine). In Latin, neuter nouns don't generally refer to people, so whether neuter is supposedly the primary meaning or just an option, it seems to mandate that the phrase can be used for things. On the other hand, the converse isn't true: neuter nouns don't refer to people, but masculine and feminine nouns frequently refer to things. In fact, the neuter gender only accounts for a relatively small fraction of Latin nouns. Thus, even "et alii" or "et aliae" would often be the correct choice in Latin for lists of things, depending on the type of thing. (Of course, there's no Latin word for "compiler", so there's no way to say which would be most appropriate in this particular case, unless you refer to the Vatican's book of Latin neologisms or something.) The word itself just means "other", with nothing inherently limiting it to describing people. In English, substantive adjectives (adjectives without nouns) do tend to default to people unless a noun has been specified: thus it's natural to say "compilers including Clang, GCC, and others", but not just "Clang, GCC, and others". But Latin likes to use substantive adjectives much more liberally. Especially in the neuter, I'm pretty sure "alia" is perfectly good by itself where in English you'd need to say "other things".

Anyway, you could argue that the use of "et al." in English has a restriction that doesn't come from the original Latin. Many of the Google results I found do claim that there's a convention of using "etc." for things and "et al." for people, although that seems to conflict with the idea that "et al." primarily stands for "et alia". But they mostly don't claim that that convention is a hard rule. And I don't think it makes much sense to establish one, considering the original meaning.

[edit: reworded for clarity]

You may be right in terms of Latin, but now that both words are being used as English expressions, the original Latin can only be a guide, not a rule. In formal writing I'd try to get it "right" but informally if it doesn't make it harder to read, it's fine imho

i would be in heaven if my projects at work compiled in mere minutes.

If you’re compiling C++, chances are clang isn’t the one to blame. C++ can be inherently slow to compile, depending on the project.

It's mixed C/C++, and the codebase does not contain a lot of "heavy" features like templating and header-only implementations (I'm looking at you, boost).

A clean build may take minutes, but with a good build system like cmake or meson with a ninja backend, it should be a rare occurrence.

In languages like C++ it also takes good program design, with some extra indirections.

No, I'm talking about a normal incremental build (which usually touch many things—I don't usually get to only recompile a single unit). If the planets align, I can get an incremental build to take just 30 seconds or so, but that's rare enough that I might mark such an event in my calendar. And that's on a beast of a server.

With Go, on my laptop, 30 seconds is the time it takes to perform a complete, optimized build of a medium-sized application, all dependencies and the standard library from source.

It's always so... frustrating whenever I go from a Go project back to our large C/C++ mixed codebase...

Because Go doesn't do very much optimization. They've been fighting back performance regressions every time they try to improve the performance of the resulting binaries.

https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvem...

Neither does clang, gcc or rustc unless you explicitly tell it to. I was talking about a normal development session. Why would I make compilation time worse by making optimized builds?

> I believe Clang et al are fast enough.

This is a genuine case of survivorship bias in action.

I guarantee you that there are people not using Clang or writing, let's say, C++ because of slow compile times. You just never hear about how much they hate using them, because those people no longer are using them.

But that threshold isn't a constant across developers. Coming from the world of dynamic languages I still find Go's compiler to be annoyingly slow at times.

Reply on news.ycombinator.com