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

61–70 of 84 posts

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

#61

Post by badsectoracula »

gpderetta wrote: post #41
badsectoracula wrote: post #28

Earlier quoted context omitted.

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…

> Probably, but it can be a convenience to make some small modifications to try out things without saving them. Yes, I remember it being very pleasant when borland C++ crashed after running your application, losing your unsaved work. edit: that was on windows 95/98 time; so it is more likely that the application crashed the whole OS.

It sucked when that happened, which is how i developed a habit for saving my files even when i'm doing nothing and even pressing the save shortcut key several times :-P.

But at the same time it can be a convenience if you dont want to save but instead make a small change to try something out.

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

#62

Post by badsectoracula »

leni536 wrote: post #38
badsectoracula wrote: post #28

Earlier quoted context omitted.

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

TBH i was thinking more in the lines of having the text editor associate source code lines with C functions and declarations so that the IDE can recompile only the bits changed while working in the code (something like a more advanced edit-and-continue).

But yeah, i do not see much effort going on in improving these areas. I think people are just used to "patchwork IDEs" and find them good enough.

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

#63

Post by badsectoracula »

pjmlp wrote: post #39
badsectoracula wrote: post #20

Earlier quoted context omitted.

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/1…

I was referring to the given example, i actually use Free Pascal and Lazarus for my own tools and a big reason is how fast both the IDE (Lazarus) and the compiler (Free Pascal) are compared to anything C++ (well, anything except Borland C++ 5 i mentioned above and C++ Builder, but that isn't exactly fair considering the age of those programs :-P).

But even in Turbo/Borland/Free Pascal modifying a unit means that you have to recompile the other units that need that unit.

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

#64

Post by badsectoracula »

sehugg wrote: post #21
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).

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

Yeah, this was another reason why it was so fast - disk i/o was very slow (especially if -like me- you had no hard disk).

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

#66

Post by bluedino »

laumars wrote: post #42
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 I'm pretty sure Borland used to separate out the IDE executables from the compilers and a couple of other tools tool. I don't have a copy to hand to prove this but I'm sure I used to occasionally invoke Turbo Pascal's compiler from the command line outside of the IDE (due to it being a separate .exe / .co…

>> I'm pretty sure Borland used to separate out the IDE executables from the compilers

Turbo C was like that, but not the first few versions of Turbo Pascal.

The whole goal with Turbo Pascal was to have everything in one small program so you could code/compile/test as fast as possible. It used a one-pass compiler and didn't have a heavy linker. It was fast even on a 8088. Anders Hejlsberg was the original author of Turbo Pascal (yes, the same guy from MFC, J++, C#, TypeScript...)

The original TURBO.COM file was very small. This was great because you could fit the whole thing on one floppy disk including your own code. No swapping floppies. Plus it was only $49.95 USD!

Pascal compiled way faster than C because there was less to do. No #includes to chew through. But Turbo C was even a fast compiler back then. A hundred thousands of lines per minute according to the ads. Imagine how slow I found DJGPP and other compilers when I finally moved to 32-bit programming.

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

#67

Post by pjmlp »

badsectoracula wrote: post #63
pjmlp wrote: post #39

Earlier quoted context omitted.

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/1…

I was referring to the given example, i actually use Free Pascal and Lazarus for my own tools and a big reason is how fast both the IDE (Lazarus) and the compiler (Free Pascal) are compared to anything C++ (well, anything except Borland C++ 5 i mentioned above and C++ Builder, but that isn't exactly fair considering the age of those programs :-P). But even in Turbo/Borland/Free Pascal modifying a unit means that you…

Ah, ok.

Actually I find those cascading of build dependencies quite productive.

Sometimes I wonder if Pascal variants had gotten more love from gamedevs (TP was my Unity), if they would be always coming up with tricks to speed up their build times or force reloading of C++ code.

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

#68

Post by badsectoracula »

pjmlp wrote: post #67
badsectoracula wrote: post #63

Earlier quoted context omitted.

I was referring to the given example, i actually use Free Pascal and Lazarus for my own tools and a big reason is how fast both the IDE (Lazarus) and the compiler (Free Pascal) are compared to anything C++ (well, anything except Borland C++ 5 i mentioned above and C++ Builder, but that isn't exactly fair considering the age of those programs :-P). But even in Turbo/Borland/Free Pascal modifying a unit means that you…

Ah, ok. Actually I find those cascading of build dependencies quite productive. Sometimes I wonder if Pascal variants had gotten more love from gamedevs (TP was my Unity), if they would be always coming up with tricks to speed up their build times or force reloading of C++ code.

I think Pascal didn't got much love from gamedevs for more or less the same reason it didn't got much love from everyone else - there was only a single company with a popular Pascal compiler (Borland) and that self-imploded by trying to chase after enterprise markets while ignoring the masses of developers that made them popular in the first place. For the entirety of the 90s, people who wanted to write Pascal on a mainstream platform (ie. DOS and Windows) had very limited options.

Official SDKs and OS APIs written in C didn't help either too, although that was a minor issue. But still created friction.

Of course with Free Pascal that isn't the case anymore, FPC is the compiler with the second number of supported platforms (after GCC) and architectures, but the stigma and public perception of the language still prevails (for example many things that people laud D and Rust for are things that Free Pascal did for years).

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

#69

Post by badsectoracula »

bluedino wrote: post #66
laumars wrote: post #42

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 I'm pretty sure Borland used to separate out the IDE executables from the compilers and a couple of other tools tool. I don't have a copy to hand to prove this but I'm sure I used to occasionally invoke Turbo Pascal's compiler from the command line outside of the IDE (due to it being a separate .exe / .co…

>> I'm pretty sure Borland used to separate out the IDE executables from the compilers Turbo C was like that, but not the first few versions of Turbo Pascal. The whole goal with Turbo Pascal was to have everything in one small program so you could code/compile/test as fast as possible. It used a one-pass compiler and didn't have a heavy linker. It was fast even on a 8088. Anders Hejlsberg was the original author of T…

> the same guy from MFC

Maybe you meant Windows Forms? AFAIK MFC was made years before Anders left Borland to join Microsoft.

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

#70

Post by pjmlp »

badsectoracula wrote: post #68
pjmlp wrote: post #67

Earlier quoted context omitted.

Ah, ok. Actually I find those cascading of build dependencies quite productive. Sometimes I wonder if Pascal variants had gotten more love from gamedevs (TP was my Unity), if they would be always coming up with tricks to speed up their build times or force reloading of C++ code.

I think Pascal didn't got much love from gamedevs for more or less the same reason it didn't got much love from everyone else - there was only a single company with a popular Pascal compiler (Borland) and that self-imploded by trying to chase after enterprise markets while ignoring the masses of developers that made them popular in the first place. For the entirety of the 90s, people who wanted to write Pascal on a m…

Pretty much my opinion as well.
Post reply on HN