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

11–20 of 84 posts

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

#11

Post by boznz »

quantumhobbit wrote: post #7
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 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!

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

#14

Post by throewai »

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.

It's basically an ugly Python now.

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

#15

Post by archimedespi »

pinum wrote: post #10
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…

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

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

#16

Post by badsectoracula »

pinum wrote: post #10
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…

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

GCC 6.2.0 under MSYS2 takes 6.302s for a full debug build and 10.499s for a full optimized build. With make -j8 this is down to 1.997s for a full debug build and 6.942s for a full optimized build.

I haven't tried TCC, i think i tried at the past but it was missing some libs.

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

#17

Post by throewai »

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…

Post your 3D engine's GitHub.

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

#18

Post by 0xcde4c3db »

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!

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

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

#20

Post by badsectoracula »

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

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.
Post reply on HN