5 ms·
Here's some thinking outside the box. Traditional compilers are focused on building an executable as fast as possible, throwing away an enormous amount of state
by stevedonovan 10y ago
Here's some thinking outside the box. Traditional compilers are focused on building an executable as fast as possible, throwing away an enormous amount of state each time. The new rustc incremental compilation attempts to re-use some of that computed state, although still early days. If however the compiler's state remains persistent (it is running as a daemon) then small code changes should usually be pretty fast - it's analogous to the code scanners of Eclipse. If the target of the compiler isn't a native executable, but a continuously updated image containing code, then the link gets pretty fast as well. The result will not be fast, but it will be _fast enough_ to test changes.
- amelius 10y agoYes, and it would be even nicer if such techniques would be available outside the compiler community. In fact, it could perhaps even be a language feature.
- deleted 10y ago[deleted]
- pjmlp 10y agoYou mean like Lisp, Smalltalk?
- vanderZwan 10y agoThe new kid on the Smalltalk block is Pharo: http://pharo.org/ http://pharo.org/
- adamrezich 10y agoAlso that language Jonathan Blow is working on https://www.youtube.com/watch?v=HLk4eiGUic8 https://www.youtube.com/watch?v=HLk4eiGUic8
- grokys 10y agoI think the Roslyn compiler does something similar to what you're suggesting. http://www.dotnetcurry.com/csharp/1258/dotnet-platform-compiler-roslyn-overview http://www.dotnetcurry.com/csharp/1258/dotnet-platform-compi... > Every time a developer changes a single character in any of the files, a new copy of all the data structures is created, leaving the previous version unchanged. This allows a high level of parallelism and concurrency in the Roslyn engine, as well as in its consumers, thereby preventing any race conditions to occur. Of course, in the interest of performance, these operations are highly optimized and reuse as much of the existing data structures as possible. Again, those being immutable makes this possible!
- stevedonovan 10y agoRight! That's a compiler designed to be used as a service! Most compilers are usually in a terrible hurry to build that executable before people start playing with light sabers or thinking about new programming languages [1]. I first thought about this when working on UnderC, a hopelessly over-ambitious C++ interpreter. Functions could be recompiled, because there was an indirect reference to the actual code. And this is of course exactly how Lisp people used their compiler. (The 'image' reference of course is to Smalltalk) [1] https://commandcenter.blogspot.co.za/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.co.za/2012/06/less-is-exponen...
- pas 10y agoScala's new compiler (dotty) also tries to go that way (first of all using streaming AST-s for better cache locality). The problem is, that usually this "keep state and just percolate changes" is easier said than done. But we're getting there. See also: https://www.youtube.com/watch?v=TS1lpKBMkgg#t=23m38s https://www.youtube.com/watch?v=TS1lpKBMkgg#t=23m38s (scalac performance) https://www.youtube.com/watch?v=TS1lpKBMkgg#t=37m53s https://www.youtube.com/watch?v=TS1lpKBMkgg#t=37m53s (what do we really need from "computing science" to do programming) https://d-d.me/talks/scalaworld2015/#/49 https://d-d.me/talks/scalaworld2015/#/49
- barrkel 10y agoThe Delphi compiler, when hosted in the IDE, has done this since 1996 or so. The symbol table, generated code etc. for every compilation unit is kept in memory and only discarded if the source is modified. All imports across compilation units are done via a double indirection, so the symbols can be unlinked and relinked more easily. (Sub-second recompiles in Delphi are the norm, not the exception. In large projects, most of the time during dev builds is linking, and that's usually only a few seconds.)
- pjmlp 10y agoWhich is why I kind of think that it is a bit sad when millennials think Go compilation speed is some kind of achievement. Specially given Delphi features vs Go ones.
- adrianN 10y agoEspecially given the CPUs used in the computers back when Delphi was popular.
- pjmlp 10y agoYeah that as well, and even Turbo Pascal was already quite fast on MS-DOS systems (I was using it with MS-DOS 5.0).
- jerf 10y agoI've said a couple of times that new language designers should thank their lucky stars that C++ has set the bar for "fast compilation" so low. Coming out of the gate with a compiler that's "faster than C++!" is pretty doable even for a relatively compile-time heavy language. If you had to come out of the gate with something as fast as Delphi to be taken seriously, we wouldn't get very many new languages. (I mention this in the context of my observation that the minimum bar to be taken seriously for a language is going steadily up. You certainly need a standard library that is powerful out of the gate, whether or not it is necessarily "part" of the language, and we're getting perilously close to the language being required to ship some heavy-duty HTTP stuff, possibly a server implemented in the language, before it stands a chance. Rust may have snuck in under the wire on that, though of course that stack is developing apace even so.)
- pjmlp 10y agoBesides the sibling comments, this is how Lisp, Smalltalk, Ada and Eiffel environments work. Even C++ had such tools in the past via Energize C++ and VisualAge for C++ v.40. Microsoft is now kind of following this path with /fastlink and improved database backend for code metadata. EDIT: Typo
- flukus 10y agoTraditional as in c? Object files would maintain state and build incrementally.