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

Incremental Compilation

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Incremental Compilation

#61

Post by Manishearth »

coldtea wrote: post #60
Manishearth wrote: post #52

Earlier quoted context omitted.

I don't see where in pcwalton's comment he alludes that the Delphi compiler's definition of incremental compilation doesn't match his own. He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". (He does say that production compilers don't have incremental compilation, but that's not a matter of definition, and I read that to mean "usually don't")

> He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". He also says that merely using the separate files to deduce this (which the parent says is what Delphi does) is not incremental compilation.

It doesn't "merely use the separate files", it traverses the use statements.

There's no manual splitting of .cpp and .h files. No manual management of dependencies.

Re: Incremental Compilation

#63

Post by barrkel »

Manishearth wrote: post #61
coldtea wrote: post #60

Earlier quoted context omitted.

> He explicitly says "Incremental compilation is when the compiler automatically figures out what needs to be recompiled". He also says that merely using the separate files to deduce this (which the parent says is what Delphi does) is not incremental compilation.

It doesn't "merely use the separate files", it traverses the use statements. There's no manual splitting of .cpp and .h files. No manual management of dependencies.

Rust is going down the path where recompilation is done on a finer granularity than files. I was objecting to setting that as the bar to meet for incremental compilation. It's technically impressive, but it will only be a win if the average compilation unit takes a noticeable amount of time to compile (this was rarely the case with Delphi). It may well be the case for Rust+LLVM.

Re: Incremental Compilation

#64

Post by Manishearth »

barrkel wrote: post #63
Manishearth wrote: post #61

Earlier quoted context omitted.

It doesn't "merely use the separate files", it traverses the use statements. There's no manual splitting of .cpp and .h files. No manual management of dependencies.

Rust is going down the path where recompilation is done on a finer granularity than files. I was objecting to setting that as the bar to meet for incremental compilation. It's technically impressive, but it will only be a win if the average compilation unit takes a noticeable amount of time to compile (this was rarely the case with Delphi). It may well be the case for Rust+LLVM.

Fair. I think Delphi counts, and I don't think that was the bar being set (but it's easy to see how it could be read that way). The C++ header file model is quite different in the amount of burden placed on the programmer over the Delphi use-statement model.

Re: Incremental Compilation

#65

Post by dllthomas »

Retra wrote: post #31
dllthomas wrote: post #26

Earlier quoted context omitted.

"C++ did it right" seems a separate position from that put forward by the parent comment. I definitely think there's benefit to being able to view interface as separate from implementation, although that might well be better supported by tooling (editor folding, documentation generation) than manual maintenance - which you seem to be doing well. I don't know whether there is benefit to being able to edit interface se…

Usually if you edit the interface, you also have to edit the implementation. The only time I've ever wanted to edit an interface alone is when there wasn't any implementation written yet, which makes it a moot point anyway.

If you make substantive changes, for sure.

It's possible that you may want to make cosmetic changes (or maybe change how you're specializing something where the implementation is more polymorphic?).

Still, I certainly don't see much of an argument that being able to edit the two separately has much value. I'm just not entirely convinced of non-existence.

Re: Incremental Compilation

#66

Post by Ace17 »

guessmyname wrote: post #47

Off topic — I am surprised to find this statement [1] in the blog post considering how negative were my teachers in university with the "trial and error" approach of solving a problem. They always said that you should design a solution before the implementation, and I agree that it makes sense but there are cases where you need to put a print and exit to debug something; and if you think about it, that is what a debu…

> So is trial-and-error bad or not?

It depends.

Efficient trial-and-error should help you acquire a good understanding of the solution. When your program finally works, are you really sure why? If not, you might be doing it wrong.

You might want to google "test driven development". Basically, it's a programming discipline which heavily relies on shortening your feedback loops (i.e reduce the time between the moment you make an error and the moment you detect it). While it certainly is controversial, it can be seen as a serious formalization of "trial and error".

Re: Incremental Compilation

#67

Post by harveywi »

Does anyone know if there has been any work in formalizing incremental compilation? It would be great to have some sort of theoretical framework to use as a guide when implementing various incremental compilation strategies.

There is some (ongoing?) work on low-cost incremental computation by differentiating lambda calculi [1] [2] [3], and it seems like an incremental compiler could maybe be a good use case for it.

[1] http://www.informatik.uni-marburg.de/~pgiarrusso/ILC/

[2] http://bentnib.org/posts/2015-04-23-incremental-lambda-calcu...

[3] http://ps.informatik.uni-tuebingen.de/research/ilc/

Re: Incremental Compilation

#68

Post by pcwalton »

enitihas wrote: post #41
pcwalton wrote: post #23

Earlier quoted context omitted.

> Whole program optimization isn't generally something you want on dev builds, which is where incremental compilation is useful. By "whole program optimization" I also include things like generic/template instantiation. Whenever you use, say, a HashMap, you have to recompile the implementation of the HashMap specialized to the size, alignment, destructor, etc. of types you're using with it. > For a production build w…

Do Java generics work like that? I thought the JVM did not know about the generics as the types are erased at compile time.

Rust generics do. Java's don't.

Re: Incremental Compilation

#69

Post by pcwalton »

skybrian wrote: post #32
pcwalton wrote: post #27

Earlier quoted context omitted.

The tricky part is the dependencies between files. This is what C++ uses header files for, but Rust doesn't have those.

Languages like Go and Java can do separate compilation by reading header information out of the object files of imported packages/classes.

Rust has been doing that since day one.

What makes this incremental compilation different from that of, say, Go, is that it works inside a package. Before incremental compilation, Rust and Go had the exact same model: package-at-a-time compilation. With incremental compilation, Rust is more fine-grained than that: Rust can compile specific parts of a package while leaving the other parts untouched.

Re: Incremental Compilation

#70

Post by pcwalton »

berkut wrote: post #34
dllthomas wrote: post #26

Earlier quoted context omitted.

"C++ did it right" seems a separate position from that put forward by the parent comment. I definitely think there's benefit to being able to view interface as separate from implementation, although that might well be better supported by tooling (editor folding, documentation generation) than manual maintenance - which you seem to be doing well. I don't know whether there is benefit to being able to edit interface se…

Writing applications which have an API other people write plugins against is one: commercial apps ship the .h files, against which plugin-writers only have those and build plugins for the host apps. Yes you still obviously have to keep them in sync, but the point is you (as a commercial software vendor) can ship just the headers and keep the internal implementation details secret and change how things work completely…

You can do this in Rust just fine. The compiler can determine all the types and signatures from the tables stored in binary code. No separate .h file needed.
Post reply on HN