Hacker News Reader

Comment by saagarjha | Hacker News Reader

Also see the Tiny C Compiler, which was born out of this project and now is a pretty-full featured C compiler in its own right: https://bellard.org/tcc/. It has a couple pretty interesting features by virtue of its small size, such as being able to "interpret" C code as well as generating executables in-memory so they're portable across platforms without a lot of work.

View on HN

And it is fast. I clocked it at over 200K lines/sec. Swift, on a typical project, will do around 20. Not K, just lines/sec.

Of course the C code was a lot simpler, but still...

I would like to know how you were able to investigate that.

Hit compile, count the seconds until complete?

Wait, what? 50 milliseconds per line of code? How is that even possible?

Not 50 milliseconds, 5 microseconds. Something like 10,000 cycles, or a few hundred to a thousand cycles per byte of source code (depending on average line length).

"around 20. Not K, just lines/sec"

Sorry for the misunderstanding. Inefficiencies on that level just aren't very surprising to me anymore.

It is heavily dependent on the type of code you write. For example, ternary operators can take several hundreds of milliseconds or even entire seconds each to compile while an equivalent if statement is orders of magnitude faster[1]. Anything with type inference also tends to compile very slowly.

[1] https://bugs.swift.org/browse/SR-1577

Makes you wonder, right?

Of course, there are (still) pathological cases where a single line of code will abort because it runs out of time.

   > cat too-complex.swift
   let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]

For me, this aborts after about a minute and a half:

   > time swiftc too-complex.swift 
   too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions
   let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~

   real	1m35.094s
   user	1m16.698s
   sys	0m5.141s

That appears to be some sort of exponential in type inference. Other similar ones have been fixed.

The ternary expressions mentioned elsewhere also appear to be problematic, and in general, there's little time bombs all over just waiting to go off.

The rate I mentioned earlier was taken from a CocoaHeads talk by someone who built a caching mechanism for Carthage, because their Swift framework(s) of around 20KLOC were taking ages to compile.

So it's a real-world example, not something made up.

> That appears to be some sort of exponential in type inference.

If I recall, it's in the implicit conversions, not strictly the type inference.

Swift, on a typical project, will do around 20. Not K, just lines/sec.

To compare a historical compiler with your Swift numbers: In 1989, Turbo C compiled 16K lines per minute on a ho-hum machine. The computers today, 30 years later, are more than 60x faster, so one would expect compilation speeds exceeding 16k per second of swift code. Turbo Pascal compiled about twice as fast as Turbo C at the time.

Delphi (Turbo Pascal's successor) today does a million in four seconds, or about 250k / sec.

https://youtu.be/Yq2mNUzcpE0?t=146

That's four orders of magnitude greater than 20 loc/sec.

60x faster? Today's computers are closer to 1000x faster.

That was my point.

There are 60 seconds in a minute.

> Swift, on a typical project, will do around 20. Not K, just lines/sec.

Wow, how common is this in practice? That sounds broken.

Development is still going strong.

This is the active code repository of TCC: http://repo.or.cz/w/tinycc.git

Yup! I maintain a (very rough and in-progress) fork of that code for supporting iOS: https://github.com/saagarjha/tinycc

Sounds cool! What parts is it supposed to support?

- Mach-O binaries?

- ARM?

- Objective-C?

- ?

Just ARM for now, and support for certain memory protection restrictions that iOS imposes. Honestly, I really didn't do much other than tweak the Makefile, modifying a call to mprotect, and rearrange some deallocation code. TCC doesn't support Mach-O yet, and that's not something that I have enough expertise to support, so all execution is done by JITing an ELF binary in memory as it's done on macOS.

Neat project!

Is it just for fun, or could it be 'useful'? iOS categorically prohibits JIT, right?

It’s just for fun right now, but I have an idea for something that uses this that’s currently blocked by a stupid, unrelated issue. And yes, iOS generally prohibits JIT, but there are certain circumstances under which you can perform it (you need a certain entitlement). There’s no way that I’m aware to get an app through App Store review with this functionality, though.

Indeed. If it were possible, Firefox would have done it.

Cool! With CocoaPods building everything from source, a fast compiler would be a godsend for most iOS shops, even for just debug builds.

It should be pretty easy to add Objective-C and C++ support, right? ( ͡° ͜ʖ ͡°)

Reply on news.ycombinator.com