Delphi 2 can compile large .pas files at 1.2M lines per second

https://twitter.com/pervognsen/status/1265582295575982080

by luu • 6 years ago

199 200 6 years ago

twitter.com

oso2k4• 6 years ago

Not surprised [0]. Pascal was always very fast to compile, especially with Borland tools.

[0] https://prog21.dadgum.com/47.html

giancarlostoro• 6 years ago

Theres a video of this on YouTube it always fascinated me. I asked an old timer about it he said it was designed to be simple to compile and the compiler was in Assembly. Not sure how truthful this is would love to hear more about how and why its so fast. I would love to someday see FreePascal be just as fast. Its a shame Borland didnt try to make some sort of collaboration between them and FPC. I am sure FPC would welcome some sort of joint effort you help us we help you kinda deal.

pkaye2• 6 years ago

I think optimizations passes is what takes the most time in a compiler. Older compilers did a lot less.

andi999• 6 years ago

Well then at leastbwith -O0 should be similiar times achievable?

aninteger• 6 years ago

I think a very early Turbo Pascal was in assembly, but I would find that hard to believe of Delphi.

tpmx• 6 years ago

It isn't that much of a stretch to believe that they kept most of the compiler in assembly. The language itself didn't change that much from Borland/Turbo Pascal 6.0/7.0 to Delphi iirc.

Also, there was a source code leak about a decade ago of Turbo Pascal 6.0 that showed the compiler was still 100% x86 assembly. Just found it via Yandex - it was pretty hard to find with Google. (I only looked at the directory listings of the source code filenames just now, at some sourceforge-like site.)

jojobas• 6 years ago

Pascal compiles to some sort of bytecode doesn't it?

One would think it's an easier task than all the fancy x86 business?

oso2k4• 6 years ago

Early Pascals did. P-Code [0] it was called. I don't think it was really about easy of compilation. It was about ease of portability, at least early on.

[0] https://en.wikipedia.org/wiki/P-code_machine

FullyFunctional4• 6 years ago

It was and it was key to why Pascal became so successful. Porting the VM of the UCSD-p machine was so much easier than writing a new backend so Pascal spread like wildfire. I think I even saw a Commodore 64 port at some point.

FpUser• 6 years ago

Not compilers released by Borland/successors or Free Pascal. It is all native code.

ablekh• 6 years ago

Good old times ... Thank you for the nostalgic reminder.

sippingjippers• 6 years ago

Now let's compare performance after implementing 2 decades worth of missing program optimization techniques

(edit: downvotes? I'm sorry to ruin the romanticizing, but surely it should come as no surprise that these old compilers aren't fast due to black magic)

melling• 6 years ago

I only want that on a few of my builds.

Most days I could be happy with 1 second builds.

Considering that I don’t have a million lines of code, I think 100,000 lines of code a second should cover it.

Gibbon12• 6 years ago

My prat comment about C++ is the compiler writers are stuck in a trap. Because compiling C++ is slow they add optimizations to the compiler (also written in C++) to make the code faster. But that makes the compiler even slower. So they add even more optimizations to the compiler to make it run faster...

psykotic4• 6 years ago

For C compilers like gcc and clang it's comparing against -O0. Anyway, there are two issues with that long-term trend in compiler design from my perspective. The first is that the optimizing path is too slow and they don't offer an intermediate point on the Pareto frontier that reflects my trade-off preferences because too much of the slowness is architectural in origin. But the second and much worse problem is that the non-optimizing path is barely any faster. You can't make a fast non-optimizing or somewhat-optimizing compiler by taking the architecture of a heavyweight optimizing compiler and setting some internal flags and skipping a few passes. You need the fast compilation path to completely dictate the architecture from end to end, with the constraint of still supporting optimizing backends, and you need a development culture that treats the fast path's performance as inviolate and sacrosanct.

tomjen3• 6 years ago

I don't care about optimizations, I just want it to compile fast so that I can test if my new code solves the bug.

Before final release to QA, we can run the compiler over night on the CI and get a hyper-optimized build.

Or not, since it is a compiled language it will likely be fast enough anyway.

W-Stool3• 6 years ago

It is hard to emphasize enough now how the original Turbo Pascal was such a breakthrough in development tools for the PC. RIP Borland - for a while there you were really the business.

pjmlp17• 6 years ago

Having been there, I start to see some similarities the way JetBrains is attempting to go everywhere and replace OS vendors own IDEs and languages.

W-Stool3• 6 years ago

YES! Me too, I'm developing in Go now and their Goland IDE really reminds me of some of the best of the old days @ Borland.

laumars5• 6 years ago

RIP Pascal as well. Delphi wasn’t without it’s frustrations but Pascal was a far better language than people give it credit for these days.

edwinyzh• 6 years ago

Why? See how Free Pascal Compiler is alive: https://github.com/graemeg/freepascal/commits/master And its IDE: https://github.com/graemeg/lazarus/commits/upstream

And we have new versions of Delphi very year, with a free Community edition: https://beta.embarcadero.com/products/delphi/starter

PS, I myself write all my software with Delphi, and this is the newest one: https://docxmanager.com - something that turns MS Word into something like WordPress :)

eli• 6 years ago

I cut my teeth on Delphi 2. Didn't realize how good I had it! Solid IDE that Just Worked right out of the box with point and click GUI builder. And the builds were fast and IDE responsive even on "average" hardware of the day.

codeulike2• 6 years ago

And packaging and installation was a doddle, if I remember correctly. Everything just rolled up into one installable exe?

squarefoot• 6 years ago

Delphi was extremely fast, and later much heavier releases such as Delphi 4 still were a lot more fast back then on older machines than Lazarus/FreePascal is today on modern hardware.

To give some figures, I've installed an old non legit version of Delphi 7 on Linux through Wine, and timed some compilation tests, from start of compilation to application running. Well, on Lazarus an empty form takes like 28 seconds to compile first time, or uncached, while from 2nd time on it takes from 2 to 3 seconds. Another form filled with objects takes 3 seconds on Delphi 7 uncached, and about 1 second cached. All this under Wine, i5 machine, mechanical disk drive; the difference is astounding. I wish Lazarus/Freepascal received some optimizations to get more close to the speed of Delphi.

anta40• 6 years ago

Faster than FreePascal? And I thought FreePascal is already damn fast, well at least before I know Go.

pjmlp17• 6 years ago

Yes, hence why Go compile times, while welcomed, are just surprising for a generation lost in scripting languages and C++ compile times with crazy meta-programing tricks.

ibejoeb• 6 years ago

I loved Delphi. And Borland and Borland-progeny products.

I have a shrink-wrapped box of Turbo Pascal 7 for DOS.

It's been long enough since physical acquisition of software that I'm not even sure how to say that. "Box of Turbo Pascal" seems awkward.

randlet• 6 years ago

A gift (c. 1997?) from my parents of a "box" of Turbo Pascal is easily one of the most influential moments of my life. It was such a great programming environment and the docs (books!) were fantastic and quite accessible. I'm still chasing the dragon of the feeling of programming I had back then.

switchbak• 6 years ago

Absolutely. The rapid feedback from the near instant compile was so addictive. I would be in flow state for so long. If only I knew about unit tests back then.

I really only get that these days with toy challenge problems. That might also have a lot to do with the nature of programming now. So much is based on googling known solutions and scouring examples, etc. Probably a better use of time, but you don't get the ego trip of feeling like a wizard.

W-Stool3• 6 years ago

The first version wasn't even a box - a paperback book with floppy disks. Imagine that - printed documentation!

ygra• 6 years ago

My first foray into programming was reading the GW BASIC manual and then asking my father whether he could get me GW BASIC; I got QBasic instead, which nicely integrated all the text from that tome in the IDE. Right now I wonder what children will start with and how it would compare to my journey. Personally I feel, while JS in a browser is so much more capable, it's all but beginner-friendly and its main benefit to beginners is just ubiquity.

userbinator• 6 years ago

A more detailed answer (but still somewhat vague) for those wondering things like "how long are the lines" and "on what hardware" can be found in the linked thread: "110 cycles per source byte".

Of course, that can vary significantly based on what those bytes actually represent (e.g. scanning through comments should take far fewer cycles than parsing keywords, numerical constants, or other expressions) so the actual "texture" of code being compiled will make a difference.

...and as someone who has spent a lot of time decompiling binaries, the lack of (any!) optimisations Delphi has reflects itself in the code it generates: It's extremely fast because it generates code extremely stupidly. Redundant moves, duplicated instructions(!), and other perplexingly stupid things are frequently seen. I suppose some of that might be a reflection of the quality of the source it was compiled from, but normally those don't show through with C compilers even at O0.

bjoli• 6 years ago

I wrote a comment about a week ago in this very forum that a non-optimizing compiler should be able to compile about 1MLOC/s [0]. That seems to stay reasonably true a week later.

What is more interesting is what tradeoffs you make to produce fast code. Chez scheme produces code that is plenty fast compared to most other scheme compilers, and does so at almost 100KLOC/s on my computer (on generated code that is relatively simple and already macro-expanded). They have strict limits on the time complexity on optimization passes, and even though some people have whined about it it seems to have served chez scheme well.

[0] https://news.ycombinator.com/item?id=24660468

boznz• 6 years ago

Delphi programs are still mainly compiled for windows desktops, I have noticed the binary for the 120K line MPR system I developed for my client has creeped up from about 8MB to 20MB since 2007. My current delphi 10.2 takes 7.2 seconds to do a full compile or about 2 seconds if I just hit the run button and it only has to re-compile the modules I was working on, this has remained pretty consistent over the 13 years since I first wrote it, despite improvements to the hardware.

I think people can read too much in to your statement about the stupid source code the compiler generates (which I cannot confirm or deny), as the final exe binary is lightning fast without any optimisations, all performance issues I have ever encountered in Delphi go back to network calls such as REST APIs, MySQL libraries, printing, network drives, etc, good multi-threading can hide most. There are optimisation levels on Delphi but in 20 years I have never felt the need to go off the default.

As a developer, I will take near instant compilation over optimisation any day.

guenthert7• 6 years ago

As a developer, I will take near instant compilation over optimisation any day.

Not if your technical marketing department publishes results from performance tests comparing it with the competition.

I remember from my use of Turbo Pascal (way back), that it was impressively fast (CP/M version on a Z80A!) and produced at least reasonable good code (better than the awful Small C compiler of that time, partly due to the different calling convention). Moving on to C and later C++, I never had such fast turn around times anymore, but didn't miss them much in a statically typed language either.

rudedogg• 6 years ago

Tweet text for the Twitter haters:

I wrote a synthetic program generator that can target different languages so I can get measurements across a bunch of different languages and compilers while varying the generator parameters. So far the champ among modern compilers is TCC and Delphi among historical compilers.
Even when running under a Windows 98 VM, Delphi 2 can compile large .pas files at 1.2 million lines per second. TCC comes in at 0.7 million lines per second. This is on a 2.5 GHz Skylake laptop.
All the modern Pascal compilers I could find did very poorly on the same benchmark workloads. Lazarus/FreePascal at 55 kloc/sec, Embarcadero Delphi at 15 kloc/sec.

So 1.2 million lines/sec, running through a VM, on laptop hardware.

pwdisswordfish4• 6 years ago

Not surprising that TCC is slower; Pascal is much easier to parse then C.

FullyFunctional4• 6 years ago

More to the point, Wirth _designed_ Pascal to be one-pass translatable. Anders Hejlsberg took advantage of this in his succession of Pascal compilers: BLS Pascal (= Nascom Pascal), Compas Pascal, and Turbo Pascal. (Delphi is an evolution of Turbo Pascal but I don't know if he was involved).

yumaikas• 6 years ago

I suspect those modern compilers are also optimizing more than Delphi 2 was, and are probably parsing a somehow larger language.

Granted, it could be a case of a code base adapting to change poorly over time.

magicalhippo• 6 years ago

Due to certain language features that's been added, like generics, the binaries can also be a lot larger. So could very well be IO constraints.

At work we currently use Delphi 10.3 (10.4 was recently released), and it compiles and links ~1Mloc in less than 10 seconds, on my older 4770k with a Samsung 850 SATA SSD.

spatulon2• 6 years ago

I follow the tweet author (Per) and I know he's a big fan of building compilers in the style of Niklaus Wirth. I think the idea is that modern compilers generate very inefficient code first, and then have many expensive optimization passes, while Wirth advocated for simpler compilers that just generated reasonably efficient code in a single pass.

parsing a somehow larger language

That would also explain it, but I think it's appropriate to acknowledge the effect it has on compile times when you add complexity to the language. A lot of folks avoid C++ features (or the language entirely) simply because they would inflate compilation times too much, and it clearly wasn't a priority for the language committee when those features were added.

ReactiveJelly• 6 years ago

I can't think why Windows 98 would slow it down.

If the VM is using VM acceleration, it would be near full speed. The only reason 98 matters is that it's probably 32-bit not 64-bit. But if Delphi runs on Windows 98 then it probably is 32-bit too.

oso2k4• 6 years ago

FAT32 is not a very fast filesystem. Things like caching are necessary to make it performant. Also, the IO subsystems in Win98 sometimes chose slow paths or interfaces.

laumars5• 6 years ago

No probably about it. Win98 predates AMD64 so it is 32bit only. Delphi 2 would also be 32bit.

john_moscow5• 6 years ago

If you want to be able to compile a certain language fast, translation units need to be modular. I.e. if Source1 is referenced by Source2 and Source3, you should be able to compile Source1 once, save its public part into a binary structure with logarithmic access time, and then just load it when compiling Source2 and Source3.

This works splendidly with Pascal because each .pas file is split into interface and implementation sections. The interface section is a contextless description of what the module exports, that can be easily translated to a bunch of hash tables for functions, types, etc, that will be blazingly fast.

It's a whole different story with C/C++. In order to support preprocessor macros and C++ templates, referencing a module means recursively "including" a bunch of header files (i.e. reparsing them from scratch), meaning O(n^2) complexity where n is the number of modules. You can speed it up with precompiled headers, but you will still need to separately parse each sequence of references (e.g. #include <Module1.h> \n #include <Module2.h> and #include <Module2.h> \n #include <Module1.h> will need to be precompiled separately. C++20 modules do address this, but since C/C++ is all about backwards compatibility, it's still a hot mess in real-world projects.

That said, C# solves this problem near perfectly. Each .cs file can be easily translated to an mergeable and order-independent "public" part (i.e. hierarchical hash table of public types), and that part can be reused when building anything that references this file. It is also interesting how C# designers achieved most of the usability of C++ templates by using constrained generic types that are actually expanded at runtime (JIT IL-to-native translation to be more specific).

Galanwe5• 6 years ago

In order to support preprocessor macros and C++ templates, referencing a module means recursively "including" a bunch of header files (i.e. reparsing them from scratch), meaning O(n^2) complexity where n is the number of modules. You can speed it up with precompiled headers, but you will still need to separately parse each sequence of references

Not sure I really get your point here. Even if you remove macros and templates, reading headers is actually necessary just for the sake of knowing the size of structures, the offsets of attributes, etc.

How can _any_ language compile a unit passing a struct Foo on the stack without knowing the size of Foo (and thus having to read, say, foo.h)?

Now I agree that if you play with preprocessor to have conditional things in your headers, reparsing will be necessary, but I guess this has been solved by include guards/pragma once a long time ago. 99% of preprocessor usage is project wide configuration, so wrapping the whole headers is fine.

Not saying this is the best solution, but in practice, that shouldn't make much difference.

A subtle distinction that can make quite a difference though is to provide independent forward declarations. A lot of times, your compiler will just need to know the symbols and signatures (e.g. When passing by reference), and providing the full structure definition is overkill and slower. I don't see enough people taking care to that, which is a pity

theamk• 6 years ago

Pascal/Delphi do not use regular object files, instead they have DPU/TPU files which both contain parsed headers and object code.

Those files are not compatible between major versions, so this probably means they are designed to make them as easy to parse as possible, and map closely to internal compiler structures. This means including a unit is way faster than re-parsing the unit's text.

Additional speculation: those DPU files might contain a copy of relevant definition (like names of fields, sizes and offsets). This means if you have "program" which uses "my_unit" which uses "high_level_comms" which uses "Handle" defined in "low_level_comms", then definition of "Handle" could be copied directly into my_unit.DPU. So when you compile "program", and it includes "my_unit", all you need to read is "my_unit.DPU". You do not care about total size of "high_level_comms" and "low_level_comms" files.

Unfortunately, in C/C++, when people '#include <iostream>', they can now use "std::plus", "mbrtowc" and "timer_getoverrun". Which means including high-level modules has to bring tens of thousands of lines in translation units. (Yes, impl pattern, well-designed interfaces, forward declarations can fix this, but few people bother. Stdlib certainly does not)

coliveira2• 6 years ago

I guess this has been solved by include guards/pragma once a long time ago

include guards don't really solve this problem, because the preprocess needs to read every line to find the end of the include guard. The pragma once solution works, but it is hard to implement it for every system (what happens when a file has different names but same content)?

ddlsmurf• 6 years ago

How can _any_ language compile a unit passing a struct Foo on the stack without knowing the size of Foo (and thus having to read, say, foo.h)?

by having a runtime that has higher level instructions like "change that field" moved the onus of knowing where the field is onto the runtime. Another answer is that it's the difference between needing to parse text everytime and having some binary intermediary description (which both delphi and c# have, compare .obj to .dcu and an assembly). This means there is less work to do when a dependency changes in incremental compilation.

john_moscow5• 6 years ago

How can _any_ language compile a unit passing a struct Foo on the stack without knowing the size of Foo.

The idea is not to compile a unit without knowing the size of Foo. It's about making sure you figure out sizeof(Foo) in near constant time.

With C#/Pascal, it means:

* For each referenced module load its symbol table into RAM. If implemented cleverly, this is literally one read() call.

* For each referenced symbol, search each hash table until you find it. Since the hash tables are only built during compilation, you can auto-size them so that an average lookup takes just 1-2 steps.

* Bonus point: for libraries, you can merge the hash tables. So n is now a number of libraries, not number of files.

With C++ you are stuck reparsing megabytes of code at the beginning of each translation unit. It's millions of times slower than reading a couple of pages from disk to RAM.

higerordermap6• 6 years ago

Related question, how do C and Go compare on compilation speed in similar codebases? Neither of them have monomorphized generics, and codegen loads should be similar.

This will tell whether pragmas / include guards have largely solved the problem.

catfish17• 6 years ago

That said, C# solves this problem near perfectly.

Hadn't it already been solved in Java even better before? It doesn't look right to praise C# for resolving the problem when C# merely took that idea from Java. C# came up with the templates part though.

What C# didn't copy was the idea of turning every source file into a binary file. A library is just a zip archive of those .class binary files. What's the advantage for C# to not have .class files and to pack everything into a 'proprietary' library format? Why haven't they copied the zip-idea, too?

ckok• 6 years ago

No duplication. There's a single file where every type reference or method reference exists once. Note that it's not a library file. The compiled dll or exe has no relationship to the original way it was stored in .cs file. Instead it's a set of tables which hold all types, all members.

unnouinceput• 6 years ago

Gentle reminder that architect of C# was snatched by Microsoft from Borland. Before that he was main guy at Borland for Pascal/Delphi. So I'm not so sure he simply copied from Java anything.

https://en.wikipedia.org/wiki/Anders_Hejlsberg

john_moscow5• 6 years ago

The main reason is to have a library-scope name table and a bunch of global indexes. Can't beat that in terms of performance.

projektfu2• 6 years ago

You can look back at least as far as Ada83 to find a specification for a library manager as part of the system, where precompiled modules are stored in a format that lends itself to faster compilation.

sergeykish3• 6 years ago

Rob Pike on include files [0]:

Simple rule: include files should never include include files. If instead they state (in comments or implicitly) what files they need to have included first, the problem of deciding which files to include is pushed to the user (programmer) but in a way that's easy to handle and that, by construction, avoids multiple inclusions. Multiple inclusions are a bane of systems programming. It's not rare to have files included five or more times to compile a single C source file. The Unix /usr/include/sys stuff is terrible this way.

Plan 9 compilation is very fast. It is small but also it restricts recursive #include, no guards (example [2]), each header has corresponding library, headers included in C file only [1]:

    #include <u.h>
    #include <libc.h>

    void
    main(void)
    {
        ...

Remember Go language demo compilation time? Same authors.

[0] http://www.lysator.liu.se/c/pikestyle.html

[1] https://www.lysator.liu.se/c/plan9c.html

[2] https://github.com/brho/plan9/blob/master/sys/include/bio.h

rlkf• 6 years ago

A variant of this is to mandate that every header #define a documented symbol, and then have a #ifndef guard for this around the inclusion of the header.

john_moscow5• 6 years ago

That is a major usability setback. It gets worse when headers A and B both require header C. Let's say your source already includes A and C and you want to add B. Now you need to manually read through the comments to understand where exactly in the include list you need to plug it.

This will become completely unmanageable once your include count surpasses 20-something, which is normal for large projects.

raverbashing• 6 years ago

He's not wrong per se but this shows how utterly broken C is. And macros are a "bandage" that make the problem worse.

include files should never include include files

Cool, there are two possible outtakes to this:

1) Why aren't include files generated automatically from C files then? (If you can't include anything this means they shouldn't have no "code", so they can't call anything, so they can't include anything or reference anything else)

2) Why aren't they a compilation target? (yes I know modern GCC allows you to do that) but why doesn't C specify a binary representation for them.

simias3• 6 years ago

I would strongly recommend that people new to C and reading this comment do not follow this advice. It might have made sense back when it was written but it's not how modern C is typically written, and it would be very annoying for modern C coders to put up with these shenanigans.

Multiple inclusions are hardly a problem nowadays, with header guards it means that subsequent inclusions won't actually include anything and the performance impact is fairly negligible the vast majority of the time. C compilers are pretty damn fast these days and in my experience it's the optimization pass that slows things down the most, not parsing includes.

Also in general I tend to take what Rob Pike says with a grain of salt, he's a very smart guy and he definitely says interesting things but he has weird idiosyncracies. He's definitely worth listening to, but I wouldn't follow his advice blindly. See his weird take about how "syntax highlighting is juvenile" for instance.

avodonosov2• 6 years ago

Or use a language witn normal ʼimportʼ support.

avodonosov2• 6 years ago

Pascal also was originally designed for easy parsing and compilation - single pass compiler with simple recursive-descent parser.

Maybe Delphi compiler works the same way.

signaru3• 6 years ago

This is also what I am thinking. Even if I am a fan of Delphi/Lazarus for what they deliver, native GUI programs that generally have no dependencies, I think some parts of the Pascal language were designed for ease of the compiler and less for the programmer.

Here are a few features that prevent Pascal from being my go-to language:

* Having all function variables declared in var clauses at the start, far away from where they are first used. It eventually gets littered by loop indices and other temporary variables.

* "interface" sections that can easily grow (C/C++ header files are also somewhat similarly inconvenient).

But then again, these languages have been around when computers are not as powerful. And perhaps, keeping these rules is the price of not breaking what works.

Still, I doubt language design alone is enough to make compilation fast (i.e. why FPC is not as fast). There must have been a lot of sorcery in the Borland compilers that we will never know. Also they must have taken advantage of only supporting Windows (and only x86?) back then.

vintagedave• 6 years ago

single pass compiler with simple recursive-descent parser. Maybe Delphi compiler works the same way.

Delphi is indeed a single-pass compiler. It does not use a normal recursive-descent parser, but a hand-coded parser. Other than that, yes - the Delphi language today is still designed to be extremely efficient to parse and it compiles a million lines of code in seconds.

pjmlp17• 6 years ago

Visual C++ pre-compiled headers, alongside incremental compilation and linking make it relatively fast thought.

Plus on Windows shops we tend to compile C++ libraries into native artifacts, or COM libraries, so unless you are making the whole world from scratch, or doing crazy meta-programing without external templates, do the compile times become a problem.

VC++ modules support is showing quite promising.

Then again I do enjoy having to spend most of my time on Jav/.NET land in what concerns compile times.

eska• 6 years ago

I've seen demos of Jonathan Blow's language Jai where he shows how fast his current video game project in Jai compiles. He's doing the opposite of what you say: just give all input files to one compiler invocation without headers or incremental compilation, in order to let it handle concurrency properly. He still ends up compiling at 1mil/s. The added benefit is that his program can get access to the entire AST and modify it during the build.

bluedino• 6 years ago

Turbo Pascal compiled thousands of lines a second on a 286. When I moved to Turbo C I was shocked at how long it took to compile code. What took 3 seconds now took 15.

piinbinary• 6 years ago

If that scaled completely linearly - I'm sure it doesn't, but it might be close enough - it would mean that it could compile a few kloc in less time than most interpreters/VMs take to boot up.

For me, "instant" compiler and test feedback would be the ideal development experience. (Plus a good debugger)

I think sadly there are some features (e.g. HM-style type inference) that I want to have but would be an order of magnitude or two slower than this. But still, I'd love to see a compiler for a modern language use something like this as a goal. Even 10kloc/thread*sec would be quite good, now that we have 16+ thread CPUs readily available.

0823498723498722• 6 years ago

Back in the days of floppy drives, an interesting technical challenge was: write a system that boots, compiles itself, and enters its REPL before the drive mechanics manage to hit full RPM.

What would the equivalent be on current systems? I suppose it might be possible to write a system that boots in a single bandwidth-delay product, but somehow that doesn't have the same attraction.

ando wok fash nawit towsh nagut (running light without overbyte)

willcipriano• 6 years ago

Before the flash drive heat throttles itself?

e12e• 6 years ago

The "other" fast compiler (tcc) can do this:

https://bellard.org/tcc/tcc-doc.html

TCC can be invoked from scripts, just as shell scripts. You just need to add #!/usr/local/bin/tcc -run at the start of your C source:

  #!/usr/local/bin/tcc -run
  #include <stdio.h>

  int main() 
  {
    printf("Hello World\n");
    return 0;
  }

And famously, with some patches it can compile the Linux kernel at boot time (in reasonable time):

https://bellard.org/tcc/tccboot.html

psykotic4• 6 years ago

I'm the author of the tweet. Here's some more context:

The main purpose of the testing was to measure compile time scaling on simple code that has straightforward equivalents in all languages. This meant integer and float operations, compound expressions making use of the full range of arithmetic and bitwise operators, local variables, function definitions and calls. So the code wasn't trivial (unlike most of the marketing-oriented tests or benchmarks I came across), but I also wasn't claiming that this was directly representative of a real-world code base of comparable size.

I was working on a fast compiler (which generated machine code somewhere between gcc -O0 and -O1 in code quality) and wanted to have something to compare it across languages and compilers while being able to easily vary test parameters like total code size, size of each module, complexity of the module graph, identifier/whitespace/comment length distribution, etc.

"Lines of code" is a pretty poor metric for engineering but unlike "tokens of code" or "bytes of code" it's something for which programmers have an intuitive sense of scale, so it made more sense for a tweet. Tokens of code is the most useful code size parameter for measuring one-pass compiler performance if you have to pick a single number. In an expression like "x + 1" you can assign the cost of the parsing, type checking and code generation of the expression (separate from the sub-expressions "x" and "1") to the "+" token. Even the cost of lexing is often dominated by the per-token cost (the switch jump on the leading byte is usually a forced branch mispredict of ~15 cycles) if you do the per-byte handling for variable-length tokens like identifiers efficiently. [1] If you fix the token distribution, you get almost-linear scaling with token count. [2]

[1] Identifier bytes make up 60-70% of a typical code base, so micro-optimization can really pay off here if the rest of the compiler is fast. I used a SIMD method with a mispredict-free fast path for identifiers shorter than 16/32 bytes, with vectorized scanning and hashing, and the symbol table lookup/insertion was done at the same time and tuned such that it was mispredict-free 90% of the time for lookups and only had 1 mispredict for inserts which occur the first time a given identifier is seen in a module.

[2] Except for threshold effects when your working set starts pushing you out of a level of the cache hierarchy. There's two factors: the size of your symbol working set, and your utilization of symbol hash tables. E.g. if a region of code is using a tiny subset of a huge symbol table, each loaded cacheline from the hash table is only expected to contain one symbol from your working set due to the pseudo-random distribution of hashes, but that caps out pretty quickly. With 64-byte cachelines and interleaved key/value pairs of 16 bytes, this part can't get worse than 25% cache utilization. So the worst-case footprint from the symbol working set is one 64-byte cacheline per symbol in the working set plus whatever associated symbol data is accessed. This utilization is improved if you put more symbol data directly into the hash table cacheline but unfortunately that would mean you don't have stable pointers to that data when you need to rehash.

1wd• 6 years ago

I did a similar test some years ago: https://imgur.com/a/jQUav#xVgi2ZA (Have you tried plotting some data?) I found some interesting and perhaps surprising results. (But I also acknowledge that it was very far from real-world code, any conclusions drawn from that were only for fun.)

psykotic4• 6 years ago

Yeah, I remember seeing your measurements at the time.

I did plots, but for most of the compilers I only measured at a handful of points in the parameter space since it took forever to run and I wanted to be able to regenerate the measurements in a reasonable amount of time if I changed the generator or parameters. I did dense multi-parameter measurements and model fitting for my own compiler; that's how it started, so the comparative data for other languages and compilers came later.

josephg2• 6 years ago

Stats like this remind me how insanely slow the rust compiler is. Its possible to write a compiler which spends 110 cycles per source byte. How many cycles per source byte does the rust compiler consume? It seems like its 4-5 orders of magnitude slower - which is so crazy!

Why is it so hard to optimize? Are we just being lazy? Whats going on?

coldtea• 6 years ago

Are we just being lazy?

"We" being who here? I'm pretty sure the Rust devs work like crazy on the language and its features -- they're not being "lazy". At best, they deprioritize compiler speed work, which is not the same as laziness.

manfredo• 6 years ago

Perhaps a better question is, what are compiler authors optimizing for? A compiler that runs in 3 seconds that produces code that's half the speed as a compiler that runs in 3 minutes is a worse option than the latter in plenty of use cases. And if we really care about minimizing compile times (and if we're being a little pedantic) we can just use an interpreted language and achieve zero compile times, by virtue of not doing any compiling at all.

Rust and Pascal have different use cases in mind. I think a better question would be what are the different design philosophies between the two languages, and how this impacts compiler implementations.

samatman2• 6 years ago

There is an amount of time spent compiling which has a qualitative effect on my programming. I start to feel it around ten seconds, definitely by thirty; three minutes is way over the line.

I start to be reluctant to make small tweaks. I want to program in 'blocks', time compiling with bathroom breaks. My frame is just wrecked, and I'm fairly convinced that code quality suffers from this.

I like what Zig is doing, by taking such care to keep unoptimized builds as fast as possible. Release builds can run overnight for all I care, I'm fine with taking arbitrary amounts of time to get the fastest end product I can have.

But I firmly believe that a language which can't give me a build in a handful of seconds is missing out, and it's a real pity Rust is in that category.

It's possible that a language with type inference and a borrow checker simply must have slow compile times, that it's inherent. I doubt that somehow, though I concede that one-pass compiling a la Turbo Pascal is likely impossible.

0823498723498722• 6 years ago

Pascal's original role was as a teaching language. Students will invariably compile multiple times making many errors along the way, but never run their final iteration in production.

For those who don't remember "funny money" I'll point out that, not only did we wear onions on our belts, but CPU usage was charged back in the day.

:beratna owte wameku ere nebula:

saagarjha2• 6 years ago

Well, ideally you have both! For what I’m working on right now, a plain debug compile takes an hour. Since I usually interact with a debug build for just a few minutes (if I’m not playing tricks) I would really like a “make this faster to compile but slower to run” option. (I doubt one could exist, but you never know.)

pjmlp17• 6 years ago

Except you are forgetting that with many native compilers, I can choose to wait 3 seconds or 3 minutes, I am not stuck with a frozen compile time, because their toolchains allow me to choose how long I am willing to wait, including the option to use binary libraries on their package managers.

D, C++, Ada, Eiffel, Delphi,...

mhh__3• 6 years ago

Performing semantic analysis on a language like Rust is much harder than Pascal i.e. to compile a rust file you have to perform static analysis as part of the compilation.

It can be faster though. D is a very big language and I can compile the entire compiler in a second flat on my machine (i.e. it's cheap enough not to cache the resulting object file to include in my project)

zozbot2342• 6 years ago

Static analysis is a minor part of Rust compile cost. The main cost is from optimization, as well as from redundant work caused by monomorphized generic code or custom macros.

jml7c5• 6 years ago

This long series of blog posts ("How to speed up the Rust compiler") will be of interest: https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed...

I think they've all been discussed on HN at some point.

higerordermap6• 6 years ago

LLVM.

The race between most used compilers is in producing fastest code. There are only few folk who care about correctness and compile times.

LLVM, while its drawbacks are not highlighted, is a monolith and only slightly better than GCC in some areas. Compile times being one of them.

Not to forget "fast" compilers don't apply many optimizations.

There are some rust specific reasons too, like lack of binary dependencies.

utopcell• 6 years ago

I have fond memories of working in Turbo Pascal. Compiling and running a program felt instantaneous.

7kmph• 6 years ago

So what? compiler should catch bugs as soon as possible, as much as possible, at compile time, if it can do this fast, great! if not, then not that great, but far better than chewing through billions lines of code and do nothing, leaving you all your bugs to the run time.

cable26003• 6 years ago

There used to be a Borland Museum that had free copies of Turbo Pascal and Turbo C, but it is down now as every link I have for it doesn't work. I was hoping they'd release Delphi 2.0 or 1.0 because it is 16 bit Windows.

psykotic4• 6 years ago

Delphi 2 was the version that introduced the 32-bit compiler and ran on Windows 95. My impression is that Embarcadero (who bought and own the rights to Delphi) still have customers with legacy Delphi applications who pay them for their newer backward-compatible Delphi product, so they're unlikely to release the older versions for free. It's also a bit of a hassle to run on modern PCs. With Turbo Pascal you can just use DOSBox but you need to run Delphi on an old Windows version. If it runs in Wine, that might be the easiest option.

phonon• 6 years ago

https://archive.org/details/DelphiDeveloper2

cable26003• 6 years ago

Thanks

marcocantu• 6 years ago

The old museum site is currently offline, but if you visit the Delphi 25th anniversary site (https://delphi.embarcadero.com/) you can find in the menu at the top a link to download "Historic Delphi 1 Client/Server Install ISO"

TheJimMcKeeth• 6 years ago

Maybe we need to make a museum site museum.

stevefan1999• 6 years ago

It doesn't matter. Most of the time now is spent on code optimization. And it's becoming more significant everyday

pjmlp17• 6 years ago

And me having a Gtk-rs project that takes 18 minutes to compile from scratch with an empty frame and a couple of menu entries on a Core Duo.

My test project to validate compile time improvements on each Rust release.

The C++ original with Gtkmm takes less than 10 minutes.

Really miss Delphi like compile times, so then I just end up doing something on Qt, Lazarus or Eiffel Community instead.

DonHopkins2• 6 years ago

Reminds me of a comic I saw in an old Apple ][ magazine:

(One kid talking to another, with dad in the background hunched over an Apple ][.)

"Daddy's playing Pascal. That's where you try and see how many dots you can get before it beeps and you say nasty words."

codeulike2• 6 years ago

It was Delphi's 25th anniversary in February, here are a few articles

https://www.theregister.com/2020/02/14/25_years_delphi_progr...

https://delphi.embarcadero.com/delphi-infoworld-vb-killer/

pkphilip• 6 years ago

Free Pascal and Lazarus - the open source alternative to Delphi, is also extremely fast.

A demo that I put up sometime ago of developing a very simple GUI Hello World app from starting a fresh project to running it in less than 42 seconds.

https://www.youtube.com/watch?v=XsCDqzL3k7k

Havoc• 6 years ago

Yup. Delphi was always stupidly fast.

I recall first time using another IDE I thought the compiler had hung. Nope...just slow.

Delphi 2 can compile large .pas files at 1.2M lines per second

Related Stories