Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

The gold standard for compiler speed so far is TCC. (Fabrice Bellard)

It is not even super optimized (single thread, no fancy tricks) but it is so far unbeaten by a large margin. Of course I use Clang for releases, but the codegen of tcc is not even awful.

View on HN

I would rather vouch for Delphi, as a much more expressive, and safer language, while having blazing fast compile times.

True. Incremental compilation in Delphi is quite something else.

The Go compiler is also pretty fast.

I'd call it not terribly slow. IIRC it didn't hit 100k lines on an M2, while I saw over two million on my own compiler (I used multiple instances of tcc since I didn't want to deal with implementing debug info on mac)

What specifically are those 100k lines though? Golang code that, e. G., uses generics is significantly heavier than code that doesn't.

I don't remember, I grabbed a project that I can't remember the name of and compiled something else first to warm up the compiler then compile the project. I tried several times and it seemed to be consistently < 100K

Maybe typescript will catch up

It's being rewritten in Go so yes it will

The compiler might be rewritten in Go, but the Typescript and Go languages themselves are very different.

Go’s main objectives were fast builds and a simple language.

Typescript is tacked onto another language that doesn’t really care about TS with three decades of warts, cruft and hacks thrown together.

It's hard to say.

One the one hand the go type system is a joke compared to typescript so the typescript compiler has a much harder job of type checking. On the other hand once type checking is done typescript just needs to strip the types and it's done while go needs to optimize and generate assembly.

I thought DMD which compiles both C and D was the gold standard!?

> The gold standard for compiler speed so far is TCC.

I only wish it supported C23...

Any big projects that doesn't compile without C23 support?

Not yet AFAIK, but unlike the 'inbetween' versions since C99, C23 actually has a number of really useful features, so I expect that a couple of projects will start using C23 features. The main problem is as always MSVC, but then maybe its time to ditch MSVC support since Microsoft also seems to have abandondend it (not just the C compiler, but also the C++ compiler isn't seeing lots of updates since everybody working on Visual Studio seems to have been reassigned to work in the AI salt mines).

And Rust, as the official system programming language for Azure.

However there are several C++23 goodies on latest VC++, finally.

Also lets not forget Apple and Google no longer are that invested into clang, rather LLVM.

It is up for others to bring clang up to date regarding ISO.

Clang's support for C23 looks actually pretty good:

https://en.cppreference.com/w/c/compiler_support/23.html

(not sure how much Apple/Google even cared about the C frontend before though, but at least keeping the C frontend and stdlib uptodate by far doesn't require as much effort as C++).

Apple used to care before Swift, because Objective-C unlike C++, is a full superset from C.

Most of the work going into LLVM ecosystem is directly into LLVM tooling itself, clang was started by Apple, and Google picked up on it.

Nowadays they aren't as interested, given Swift, C++ on Apple platforms is mostly for MSL (C++14 baseline) and driver frameworks (also a C++ subset), Google went their own way after the ABI drama, and they care about what fits into their C++ style guide.

I know Intel is one of the companies that picked up some of the work, yet other compiler vendors that replaced their proprietary forks with clang don't seem that eager to contribute upstream, other than LLVM backends for their platforms.

Such is the wonders of Apache 2.0 license.

Ladybird.

Isn't that C++?

Yes. I once was thinking I should write a x86-64 codegen for my own compiler, but using tcc I was able to reach 3 million lines in a second (using multi-threading and multiple instances of tcc) so I called it a day. I never did check out if the linking was in parallel

There is no singular "gold standard".

vlang is really fast, recompiling itself entirely within a couple of seconds.

And Go's compiler is pretty fast for what it does too.

No one platform has a unique monopoly on build efficiency.

And also there are build caching tools and techniques that obviate the need for recompliation altogether.

> vlang is really fast, recompiling itself entirely within a couple of seconds.

Does V still just output C and use TCC under the hood?

Yes. [0]

https://github.com/vlang/v/blob/master/Makefile#L18

So in theory, I can make Nim do the same?

I use tcc with Nim all the time and it yields almost interpreted REPL-like code-iteration speed (like 100-500ms per compile-link - almost ENTER-see-results).

As a warning, you need to be sure --lineDir=off in your nim.cfg or config.nims (to side-step the infinite loop mentioned in https://github.com/nim-lang/Nim/pull/23488). You may also need to --tlsEmulation=on if you do threads and you may want to --passL=-lm.

tcc itself is quite fast. Faster for me than a Perl5 interpreter start-up for me (with both on trivial files). E.g., on an i7-1370P:

    tim "tcc -run /t/true.c" "/bin/perl</n"
    58.7 +- 1.3 μs  (AlreadySubtracted)Overhead
    437 +- 14 μs    tcc -run /t/true.c
    589 +- 10 μs    /bin/perl</n

{ EDIT: /n -> /dev/null and true.c is just "int main(int ac,char*av){return 0;}". }

Ah nice, I’ve been meaning to try TCC with Nim.

We are talking about compilation speed, not the harness that you could use around it.

I never tried vlang but I would say this is pretty niche, while C is a standard.

AFAIK tcc is unbeaten, and if we want to be serious about compilation speed comparison, I’d say tcc is a good baseline.

Vlang uses tcc though...

Build caching is nice until you have to disable it because it broke something somewhere. At which point it becomes very hard to turn it back on.

In other words, one needs to have absolute trust in such tools to be able to rely on them.

I've never had an issue with ccache and I've been using it forever. Are you using it over a networked filesystem or something like that for it to become confused about what needs recompiling?

V Lang is under appreciated. If you want to really see its simplicity and expressiveness, one look at its ORM will be enough. It is a thing of beauty:

https://modules.vlang.io/orm.html

There they go, making the same stupid mistakes as most other ORMs out there; by 1:1-mapping structs to tables as well as inventing their own SQL-dialect.

That is a valid point. There is no point in arriving at your own dialect of SQL to void using the standardised SQL.

A better path is to use the actual features of the programming language to provide a query interface; which can offer similar features in a type safe, well integrated fashion.

Reply on news.ycombinator.com