Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's compile like it's 1992 (2014)

fabiensanglard.net

Post reply on HN
Print view View original

31–40 of 84 posts

Re: Let's compile like it's 1992 (2014)

#31

Post by kqr »

badsectoracula wrote: post #20
0xcde4c3db wrote: post #18

Earlier quoted context omitted.

> TP was a lot faster Not surprising. As far as I know, Pascal doesn't have anything remotely as hostile to efficient compilation as the C preprocessor (oh look, changing that one constant in a header file rendered your entire project out-of-date because the compiler can't prove that it doesn't make arbitrary memory layout and AST changes in every file that indirectly #includes it).

FWIW this is the same with Turbo Pascal's (and modern incarnations of it, like Delphi and Free Pascal). If you modify a constant in a unit, the compiler will recompile all other units that use that unit. The only way to avoid that is to keep everything in memory and do background updates to the AST. At which point you might as well do background compilations anyway.

Pascal, Delphi and Ada are a lot better than C and C++ in that regard, though, by virtue of actually having some sort of sensible module system.

Re: Let's compile like it's 1992 (2014)

#32

Post by transitorykris »

GeertVL wrote: post #29
transitorykris wrote: post #12

I was super excited to play with this tonight but sadly it appears the Borland C++ URL is giving 404s. EDIT: Found Turbo C++ 3.0 and TASM and these work just fine!

Any links to the correct downloads?

https://s3-us-west-2.amazonaws.com/likeits1992/tasm.zip https://s3-us-west-2.amazonaws.com/likeits1992/turboc.zip

Re: Let's compile like it's 1992 (2014)

#33

Post by Hydraulix989 »

archimedespi wrote: post #15
pinum wrote: post #10

Earlier quoted context omitted.

This is interesting. How long does GCC take? Have you tried TCC?

tcc is blazingly fast, at least last time i used it. it's honestly fast enough that you could probably use it as an c interpreter

Any technical reasons in particular? I'm curious.

How many passes is it doing? I suspect they aren't doing much optimization then? Maybe they patch in differences in the ASTs at the IR level and work from there?

Re: Let's compile like it's 1992 (2014)

#34

Post by buserror »

archimedespi wrote: post #15
pinum wrote: post #10

Earlier quoted context omitted.

This is interesting. How long does GCC take? Have you tried TCC?

tcc is blazingly fast, at least last time i used it. it's honestly fast enough that you could probably use it as an c interpreter

I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine!

I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-)

https://github.com/buserror/simavr/tree/jit-wip

Re: Let's compile like it's 1992 (2014)

#35

Post by easytiger »

There was something about the visceral nature of the tc environment and editor and toolset that just felt like you were very mentally close to the code you were writing. Perhaps something about the bare simplicity. I can't help but feel i've been chasing it ever since in emacs.

Re: Let's compile like it's 1992 (2014)

#37

Post by tawayway »

Coincoin wrote: post #5

No mention of how much time it took to compile? I don't know if my memory is faulty but I remember Turbo C++ to be much much faster than today's C++ compilers.

I have no data to support it but I suspect the level of optimisation in modern compilers adds a lot of overhead.

Re: Let's compile like it's 1992 (2014)

#38

Post by leni536 »

badsectoracula wrote: post #28
tossaway1 wrote: post #23

Earlier quoted context omitted.

> The compiler is part of the IDE, not some external process that needs to start from a blank state for each file, needing to read the same files over and over... I suspect the difference is negligible in practice. In both cases, the files are likely to be cached in memory after they're read the first time, so you're not really reading it over and over.

Probably, but it can be a convenience to make some small modifications to try out things without saving them. From a performance standpoint the win comes from not having the compiler start from a blank state for each file but keep the compiled objects in memory and only update the changed files. I suppose a modern reimplementation of that idea (that has more memory to spare, after all the official BC++5 requirements…

Well, a more fine-grained approach would be a compiler-server with a fine grained API.

https://gcc.gnu.org/wiki/IncrementalCompiler

https://www.reddit.com/r/cpp/comments/59n8ya/what_happened_t...

I don't know how much effort is poured into these projects. There are some clang based servers like ycmd and rtags, but these are used for linting, refactoring and search (so no incremental compilation).

Re: Let's compile like it's 1992 (2014)

#39

Post by pjmlp »

badsectoracula wrote: post #20
0xcde4c3db wrote: post #18

Earlier quoted context omitted.

> TP was a lot faster Not surprising. As far as I know, Pascal doesn't have anything remotely as hostile to efficient compilation as the C preprocessor (oh look, changing that one constant in a header file rendered your entire project out-of-date because the compiler can't prove that it doesn't make arbitrary memory layout and AST changes in every file that indirectly #includes it).

FWIW this is the same with Turbo Pascal's (and modern incarnations of it, like Delphi and Free Pascal). If you modify a constant in a unit, the compiler will recompile all other units that use that unit. The only way to avoid that is to keep everything in memory and do background updates to the AST. At which point you might as well do background compilations anyway.

Not really, C++ build times are usually measured in hours for anything worthwhile using, e.g. Cocos2d-x as a possible example.

You wouldn't get such compilation windows with Pascal derived languages using their module systems.

The proof being that with VC++2017 using the incremental linker and C++ experimental modules, one also gets more human friendly compilation times.

https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-...

The Microsoft blog is only about the incremental linker, modules would speed it up even more.

Re: Let's compile like it's 1992 (2014)

#40

Post by pjmlp »

easytiger wrote: post #35

There was something about the visceral nature of the tc environment and editor and toolset that just felt like you were very mentally close to the code you were writing. Perhaps something about the bare simplicity. I can't help but feel i've been chasing it ever since in emacs.

I tried to chase it in Emacs during 10 years, back in the 90 - 2000's, until I came to the conclusion that Mac and Windows IDEs are still closer to the old Borland experience than anything else.

So nowadays I only use Emacs for Clojure or when I happen to access an UNIX server box.

Post reply on HN