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

21–30 of 84 posts

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

#21

Post by sehugg »

0xcde4c3db wrote: post #18
boznz wrote: post #11

Earlier quoted context omitted.

Used both. TP was a lot faster but TC was no slouch. A Few years ago I managed to copy an old DOS diskette onto DOS VM and compiled and run a space invaders game I wrote. TC said it compiled but just kept returning me to the IDE when it executed! I eventually tweeked the VM speed down by about 100 at which point I saw the very fast invaders move to the bottom in about 2 seconds and kill my defender!

> 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).

Also TP would usually link in-memory without creating .obj files (and it had real modules/units which made dependency analysis simple).

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

#22

Post by pvg »

hvs wrote: post #6
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.

In 1992 it probably wouldn't have had templates nor much of much else (it wasn't standardized until 1998). Modern C++ is barely the same language anymore.

The source is also plain C. Id/Carmack didn't switch to C++ until Doom 3.

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

#23

Post by tossaway1 »

badsectoracula wrote: post #8
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.

That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…

> 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.

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

#24

Post by cyberferret »

boznz wrote: post #11
quantumhobbit wrote: post #7

Earlier quoted context omitted.

I don't know about c++, but turbo pascal compiled so fast that it felt like an interpreter back in the day.

Used both. TP was a lot faster but TC was no slouch. A Few years ago I managed to copy an old DOS diskette onto DOS VM and compiled and run a space invaders game I wrote. TC said it compiled but just kept returning me to the IDE when it executed! I eventually tweeked the VM speed down by about 100 at which point I saw the very fast invaders move to the bottom in about 2 seconds and kill my defender!

Haha - I remember creating many games in Turbo Pascal etc. which used internal loops rather than the PC clock to time things like movement and speed.

Experienced the same thing when PC's came out with the 'Turbo' button. I recall having to turn off Turbo many times to make games semi playable again on new PCs.

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

#26

Post by setpatchaddress »

tossaway1 wrote: post #23
badsectoracula wrote: post #8

Earlier quoted context omitted.

That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…

> 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.

You're forgetting about dependency management. The win for in-ram cache on incremental builds is real.

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

#28

Post by badsectoracula »

tossaway1 wrote: post #23
badsectoracula wrote: post #8

Earlier quoted context omitted.

That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…

> 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 were 16MB of RAM) would be able to have a more fine-grained approach.

Post reply on HN