5 ms·
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 enou
by noelwelsh 9y ago
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.)
- arghwhat 9y agoCompiling 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".
- noelwelsh 9y agoTry using Scala :) Is that minutes for every compile, or for an (infrequent) full compile?
- pdpi 9y agoNot 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.
- iClaudiusX 9y agoNot 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).
- threatofrain 9y agoI 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.
- DC-3 9y agoLanguage 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.
- comex 9y agoI 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]
- leetcrew 9y agoi would be in heaven if my projects at work compiled in mere minutes.
- Someone 9y agoIf you’re compiling C++, chances are clang isn’t the one to blame. C++ can be inherently slow to compile, depending on the project.
- arghwhat 9y agoIt'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).
- ComputerGuru 9y agoA 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.
- adrianN 9y agoIn languages like C++ it also takes good program design, with some extra indirections.
- arghwhat 9y agoNo, 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...
- notriddle 9y agoBecause 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-improvements https://dave.cheney.net/2016/11/19/go-1-8-toolchain-improvem...
- arghwhat 9y agoNeither 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?
- carussell 9y ago> 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.
- eikenberry 9y agoBut 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.