The death of optimizing compilers [pdf]

I wish this was given in a better format instead of just slides, hopefully the talk is actually better. Here&#x27;s what I think the talk is about:<p>The pervasive view of software performance is that compilers are better than humans at optimizing code, but the few humans who optimize important bits of code to the maximum extent disagree Similarly, computer programs today are increasingly diverging into a state where there is a tiny amount of extremely performance critical code, and a large amount of code where performance is so good on our hardware today that even horribly unoptimized code has no noticeable effect on performance.<p>Thus, optimizing compilers are useless on the first type of code (humans are better), and useless on the second (performance doesn&#x27;t matter). So what good are they at all?<p>If optimizing compilers aren&#x27;t useful, what system should we use instead for making performant code? The author and collaborators&#x27; experience suggests that the reasons a compiler can&#x27;t optimize code as well as a human when it matters is that our current programming languages don&#x27;t give the compiler enough information about the intent of the code to optimize it. Therefore we should design programming languages that on the surface look very unoptimized, but specify enough information that compilers can do a really good job. It sounds like no one knows what such a programming language would look like.

The talk was given to a packed room at ETAPS, a European computer science conference leaning more on the theoretical side (I suppose everyone was curious how optimizing compilers were dying). All in all, the audience did not bust out the pitchforks, although one might say that &quot;domain-specific compilers&quot; is basically the direction academia has already been heading. I doubt any of the people in the audience who were working on compilers&#x2F;JITs are planning to stop working on them, though it did make for some fun dinner discussion.<p>There was one mid-talk exchange was one professor asking djb upfront whether or not he thought, in ten years, Mike Pall (author of LuaJIT) would be out of a job--after all, JITs are basically optimizing compilers. Well, the original question was more diplomatic than that, but eventually he pushed it enough that he got djb to not deny that this would be the case.<p>The talk was somewhat marred by a very large digression into an undergrad level primer of computer architecture (it probably would have been better served by an extended Q&amp;A session), although the sorting example he finally built up to was pretty cute.

I really like the conversation with the compiler approach. I had the good fortune to write some code for one of these: <a href="http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Cray_XMT" rel="nofollow">http:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Cray_XMT</a> which is a multi socket TB-scale shared memory machine with 128 hardware thread contexts per socket. It has an autoparallelizing C compiler that attempts to parallelize mostly for loops where it thinks it can (really quite a clever thing), but you can also tell it where to do things and give it hints through compiler pragmas. The compiler infrastructure will print out annotated copies of the code that tell you where it did and didn&#x27;t parallelize and why. The effect is that you have this conversation with the compiler in which each of you tries to tell the other how to make the code more parallel (which in the case of the XMT means better and faster). It&#x27;s very simple but the result can be orders of magnitude improvement.

Some bits of Fran Allen in Coders At Work book: <a href="http:&#x2F;&#x2F;www.codersatwork.com&#x2F;fran-allen.html" rel="nofollow">http:&#x2F;&#x2F;www.codersatwork.com&#x2F;fran-allen.html</a><p>&quot;We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization. The nubbin of the debate was Steve’s defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer’s issue&quot;<p>&quot;We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are . . . basically not taught much anymore in the colleges and universities. &quot;

I attended djb&#x27;s ETAPS talk and am still not true if he was deliberately provocative or genuine. Assuming the latter, I disagree with several of his points. Here I want to bring one to the readers&#x27; attention and it&#x27;s to do with the economics of correctness proofs.<p>One of his key arguments was that compiler optimisations are difficult to prove correct, and that&#x27;s one of the reasons why optimising compilers will be replaced by a combination of simple compilers + assembly hand-written by domain experts. It is true that such proofs are (currently) expensive, but misses the point of the economics of correctness proofs: Correctness proofs are difficult, but proving compilers correct amortises that cost over all subsequent uses. In contrast, program specific correctness proofs are typically of comparable difficulty, but don&#x27;t amortise in this way. Therefore it seems to be cheaper in the long run, to focus on the correctness of optimising compilers. Moreover, as compilers and optimisations are quite a restricted class of algorithms, hence it is more likely that we can reuse (parts of) correctness proofs and prover technology for compilers.

To finish the Don Knuth quote: &quot;There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. &quot;<p>&quot;Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.&quot;

I often boggle at people who claim that compilers are magic and outperform humans-- perhaps thats true for unimportant code that you&#x27;d pay no attention to, or with developers who aren&#x27;t familiar with the underlying micro-architecture at all.<p>It&#x27;s pretty usual for me to see a factor of 2 performance for the same algorithm implemented in the same manner when moving from SIMD intrensics (which almost directly map the underlying platform) to hand coded ASM.<p>Even non-SIMD code can result in some pretty stark changes.<p>A non-SIMD example from a crypto library I work on which isn&#x27;t (yet) very well optimized for ARM, benchmarked on my novena (with GCC 4.9.1 -O3):<p>ecdsa_verify: min 1927us &#x2F; avg 1928us &#x2F; max 1929us<p>And a hand conversion of two hot inner functions (which are straight line multiple and add lattices, no control flow) into arm assembly:<p>ecdsa_verify: min 809us &#x2F; avg 810us &#x2F; max 811us<p>Again, same algorithm.<p>(The parallel change for x86_64 is still significant, but somewhat less extreme; in that case converting the same functions is only a 15% speedup overall, partially because the 64bit algorithm is different).<p>When thats a difference which results in 2x the amount of hardware (or 15% for that matter) for a big deployment; it can justify a LOT of optimization time.<p>(Or in my case, the performance of this code will have a material effect on the achievable scale and decentralization of the Bitcoin network.)<p>From a straight development time vs performance perspective I&#x27;d use even more hand written code; ... but there is a maintenance&#x2F;auditing&#x2F;eview&#x2F;verification overhead too. And often the same code that you cannot tolerate being slow you also cannot tolerate being wrong.

Copied from lobste.rs since I think it&#x27;d be interesting to the audience here as well<p>---<p>This “dialogue with the compiler” bit that djb lands on is in some sense obviously the right way to go forward. I’ve found this to be the case not in optimization—though I’m not in the least bit surprised to see it there—but instead in the world of dependent types. The language that the program writer writes in is often just a skeleton of the genuine information of the program. For instance, in a dependently typed program it’s often very difficult for an author to immediately write all of the complex intermediate types required to drive proofs forward, but it’s much easier to achieve this in collaboration with the compiler (really the typechecker, and e.g. via a tactics language and interactive proof general-like interface). The ultimate result, the “elaborated” program, contains much, much more information than the skeletal program the programmer originally wrote. It has been annotated by the collaboration of the compiler and the program writer to extract more of the programmer’s intention.<p>The same kind of thing could clearly arise from a “collaboration” over optimization. It’s even quite possible that these are the same dialogue as dependent types certainly provide much more information to the compiler about the exact properties the code ought to substantiate—in a nice, machine readable format even.

An optimizing compiler may not be better than me at optimizing hot code paths, but my time is a very limited resource. The compiled version may only be 75% as fast as my hand optimized version, but writing that hand optimized version will likely take several times longer. Sometimes it is worth spending the extra time for that performance, but usually it is not.

Very related, but surprisingly not covered, I&#x27;ll point out what was covered in depth at Mike Acton&#x27;s CppCon14 keynote &quot;Data-Oriented Design and C++&quot;<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rX0ItVEVjHc" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=rX0ItVEVjHc</a><p><a href="http:&#x2F;&#x2F;www.slideshare.net&#x2F;cellperformance&#x2F;data-oriented-design-and-c" rel="nofollow">http:&#x2F;&#x2F;www.slideshare.net&#x2F;cellperformance&#x2F;data-oriented-desi...</a><p>And that is: Because of the ever-growing disparity between ALU vs IO speeds, the vast majority of time spent waiting on computers is because of issues that <i>the compiler can not optimize</i>. In general, compilers have very few opportunities to rearrange your data structures without your explicit, manual input. They can&#x27;t help your CPU stall on memory&#x2F;disc&#x2F;network IO less by any significant amount. They can only help when your CPU actually has the data it needs to proceed --which often is less than 20% of total execution time.<p>In that case, no matter how smart GCC gets, it probably can&#x27;t ever speed up your existing code by over 20% than it does today. It&#x27;s not allowed to by the spec. I&#x27;m not aware of any general-purpose language where this is an option to any significant degree (silent AOS-to-SOA, hot-vs-cold data segregation, tree clustering, etc...)<p>If your program is too slow, it&#x27;s almost certainly because you haven&#x27;t done the hard, still-manual work of optimizing your data access patterns. Not just your Big-O&#x27;s (N^2) vs (NlogN), but also your Big O&#x27;s hidden, implicit K. The K that academia actively ignores and that most people rarely think about because it is mostly composed of cache misses that are implicit and invisible in your code. x = sqrt(y) is super cheap compared to x = *y. But, the same people who fret over explicit ALU costs usually think very little of x-&gt;y-&gt;z.

If you agree with the author&#x27;s conclusion that we need better languages that allow us to give the compiler more information about the optimization needs of our program, then I think you have to look in the direction of languages like Haskell, Idris, etc. Fortran can be faster than C because C has aliasing that limits the optimizations that the compiler can perform. Similarly, strongly typed and pure languages like Haskell give you even more. You can do a lot with types, but on top of that Haskell allows you to define rewrite rules that tell the compiler how things can be optimized. This allows the compiler to automatically convert things like this:<p><pre><code> map f (map g items) </code></pre> ...into this:<p><pre><code> map (f . g) items</code></pre>

There are a few basic optimizations we should routinely have in compilers today, but don&#x27;t always find there.<p>-- Multidimensional array optimizations. Basically, get to the level of subscript calculation overhead seen in FORTRAN compilers of 50 years ago.<p>-- Subscript checking optimization. Work on Pascal compilers in the 1980s showed that about 95% of subscript checks could be eliminated or hoisted out of inner loops without loss of safety. This was forgotten during the C era, because C is vague about array sizes. Go optimizes out checks for the simple cases; Rust should and probably will in time. Optimization goal: 2D matrix multiply and matrix inversion should have all subscript checks hoisted out of inner loops or eliminated. Compilers that don&#x27;t have this feature lead to users demanding a way to turn off subscript checking. That leads to buffer overflows. (Compilers must know that it&#x27;s OK to detect a subscript check early; it&#x27;s OK to abort before entering a loop if there will inevitably be an subscript error at iteration 10000.)<p>-- Automatic inlining. If the call is expensive relative to the code being called, inline, then optimize. Ideally, this should work across module boundaries.<p>-- Atomic operations and locking. The compiler needs to know how to do those efficiently. Calling a subroutine just to set a lock is bad. Making a system call is worse. Atomic operations often require special instructions, so the compiler needs to know about them.<p>-- Common subexpression elimination for pure functions. Recognize pure functions (where x=y =&gt; f(x) = f(y) and there are no side effects) and routinely optimize. This is essential in code with lots of calls to trig functions.

More discussion from a month ago <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9202858" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9202858</a>

&quot;For some reason we all (especially me) had a mental block about optimization, namely that we always regarded it as a behind-the-scenes activity, to be done in the machine language, which the programmer isn&#x27;t supposed to know. This veil was first lifted from my eyes when I ran across a remark by Hoare that, ideally, a language should be designed so that an optimizing compiler can describe its optimizations in the source language. Of course!&quot;<p>That sounds like he wants some sort of homoiconic assembly or machine language to target. Does such a thing even exist?

He actually quotes my rebuttal comment - &quot;“Except, uh, a lot of people have applications whose profiles are mostly flat, because they’ve spent a lot of time optimizing them.”<p>and his response is &quot;this view is obsolete, and to the degree it isn&#x27;t, flat profiles are dying&quot;.<p>Oh great, that&#x27;s nice, i guess i can stop worrying about the thousands of C++ applications google has built that display this property, and ignore the fact that in fact, the profiles <i>have gotten more flat over time</i>, not less flat.<p>Pack it up boys, time to go home!<p>Basically, he&#x27;s just asserting i&#x27;m wrong, with little to no data presented, when i&#x27;m basing mine on the results of not only thousands of google programs (which i know with incredible accuracy), but <i>the thousands of others at other companies that have found the same</i>. I&#x27;m not aware of him poring over performance bugs for many many thousands of programs for the past 17 years. I can understand if he&#x27;s done it for his open source programs (which are wonderful, BTW :P)<p>He then goes on to rebut other comments with simple bald assertions (like the luajit author&#x27;s one) with again, no actual data.<p>So here&#x27;s some more real data: GCC spent quite a while optimizing interpreter loops, and in fact, did a better job than &quot;the experts&quot; or whatever on every single one it was been handed.<p>So far, as far i can tell, the record is: If GCC didn&#x27;t beat an expert at optimizing interpreter loops, it was because they didn&#x27;t file a bug and give us code to optimize.<p>There have been entire projects about using compilers&#x2F;jits to supplant hand-written interpreter loops.<p>Here&#x27;s one: <a href="https:&#x2F;&#x2F;code.google.com&#x2F;p&#x2F;unladen-swallow&#x2F;wiki&#x2F;ProjectPlan" rel="nofollow">https:&#x2F;&#x2F;code.google.com&#x2F;p&#x2F;unladen-swallow&#x2F;wiki&#x2F;ProjectPlan</a><p>While the project was abandoned for other reasons, it produced 25+% speedups over the hand written interpreter versions of the same loop by doing nothing but using compilers.<p>Wake me up when this stops happening ....<p>He then goes on to make further assertions misundertanding compiler authors and what they do:&quot;A compiler will not change an implementation of bubble sort to use mergesort. ... they only take responsibility for machine-specific optimization”.<p>This is so false i don&#x27;t know where to begin. Compilers would, if they could, happily change algorithms, and plenty do. They change the time bounds of algorithms. They do in fact, replace sorts. Past that, the problem there is not compilers, but the semantics of languages often do not allow them to safely do it.<p>But that is usually a programming language limitation, and not a &quot;compilers don&#x27;t do this&quot; problem.<p>For example, the user may be able to change the numerical stability of an algorithm, but the programming language may not allow the compiler to do so.<p>Additionally, it&#x27;s also generally not friendly to users.<p>As an example: ICC will happily replace your code with Intel performance primitives where it can. It knows how to do so. These are significant algorithm changes.<p>But because users by and large don&#x27;t want the output of ICC to depend on Intel&#x27;s Math Kernel Library or anything similar, they don&#x27;t usually turn it on on by default.<p>GCC doesn&#x27;t perform quite as much here, because even things like replacing &quot;printf&quot; with &quot;puts&quot; has caused tremendous amounts of annoyed users. Imagine the complaints if it started replacing algorithms.<p>Past that, i&#x27;d simply suggest he hasn&#x27;t looked far enough into the history of optimizing compilers, because there has been <i>tons</i> of work done on this. There are plenty of high level language optimizers that have been built that will completely rewrite or replace your code with rewritten algorithms, etc.<p>I stopped reading at page 50.

His vision:<p><i>The time is clearly ripe for program-manipulation systems... The programmer using such a system will write his beautifully-structured, but possibly inefficient, program P; then he will interactively specify transformations that make it efficient.</i><p>But what if the answers the programmer gives the compiler turn out not to match reality, and some weird bug is introduced that has no representation in the source? The compiler&#x27;s decisions need to be somehow spelled out in debuggable form.<p>There is another approach (that can also be complementary). The programmer specifies in advance various specific scenarios, and a JIT compiler guesses which of the scenarios is in effect and optimizes for that (e.g. a certain condition, like input size is always true), but adds a guard (that hopefully adds negligible overhead). If the scenario does not match reality, the JIT deoptimizes and tries another. This process itself, of course, adds overhead, but it&#x27;s warmup overhead, but it&#x27;s more robust. This is the approach being tried by Graal, HotSpot&#x27;s experimental next-gen JIT (and Truffle, Graals complementary a programming language construction toolkit aimed at optimization): <a href="https:&#x2F;&#x2F;wiki.openjdk.java.net&#x2F;display&#x2F;Graal&#x2F;Publications+and+Presentations" rel="nofollow">https:&#x2F;&#x2F;wiki.openjdk.java.net&#x2F;display&#x2F;Graal&#x2F;Publications+and...</a>

Even if DJB wrote some very effective code, now when he &quot;goes meta&quot; he comes somehow in the strange area of being &quot;not even wrong.&quot; Or maybe we miss his ideas when we read the slides instead of hearing him at the talk.<p>People who make compilers used in the production know: if the naive users claim that &quot;optimizing compilers don&#x27;t matter&quot; it&#x27;s because the optimizing compilers are so good in doing what they&#x27;re doing.<p>There&#x27;s the argument which is here buried deep in the discussions and which I think DJB missed to address, nicely stated by haberman:<p>&quot;If you want to argue that optimizing compilers are dead, you&#x27;d have to show that you can remove optimizing compilers from your toolchain, and have nobody notice the difference.&quot;

Compiler optimization is obviously a sleeping field currently. There&#x27;s nothing that&#x27;s made it into practical compilers to address the bottlenecks shifting from ALU work to data storage and layout considerations.<p>Consider all the gnashing of teeth and wringing of hands that goes on in C++ circles about inefficient data layout &amp; representation by inferior programmers, and the stories of victorious manual data layout refactorings by performance heroes.<p>DJB&#x27;s slides don&#x27;t address the data side because he only does crypto, and that&#x27;s one of the fields where the ALU twiddling is still relevant. But crypto is also rarely a bottleneck.

So, Mel Kaye got the last word in?<p><a href="http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Story_of_Mel" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;The_Story_of_Mel</a>

Interacting with a compiler sounds horrible. Think of the questions it might need to ask: &quot;Hey! I could use AVX2 instructions here, after I inline a bunch of stuff and eliminate some dead code, but it requires doing a bunch of memory copying. Is that a good idea?&quot;. How would you answer a question like that?<p>And then, since optimizations are target dependent, you would need to go through this exercise for each target. Sounds fun.

So just for a start: Which optimizing compiler actually properly solves the optimization problems? I know of none.<p>When I look at the list of optimization solvers for constrained linear or non-linear programming models (i.e. <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_optimization_software" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_optimization_software</a>) and the list of compilers the intersection is still zero.<p>All optimizers are still using their own ad-hoc versions of oversimplified solvers, which never fully explore their problem space. Current optimizing compilers are still just toys without a real-world solver. And it&#x27;s clear why so. Current optimizable languages are still just toys without a real world solvable optimization goal.<p>You can think of strictly typed, sound declarative languages where solvers would make sense, or you can think of better languages, like fortress or functional languages, which are not encumbered by not-properly optimizable side-effects and aliasing which harm most modern language designs.

I&#x27;d be happy if C and C++ had 2,3,and 4 element vectors as built in types, along with cross and dot product operations. There are intrinsics, and GCC has it&#x27;s own intrinsics that can be used across architectures. But the languages need to have these. They are so fundamental to so many things.<p>There are many more things to wish for, but I&#x27;m starting with one of the simplest.

Here&#x27;s a compiler which uses program synthesis to target a mesh network type architecture: <a href="http:&#x2F;&#x2F;pl.eecs.berkeley.edu&#x2F;projects&#x2F;chlorophyll&#x2F;" rel="nofollow">http:&#x2F;&#x2F;pl.eecs.berkeley.edu&#x2F;projects&#x2F;chlorophyll&#x2F;</a> . It uses a guided process like is implied in the last slides.

The original abstract for the talk (which summarizes the slides) were posted by the author here:<p><a href="http:&#x2F;&#x2F;blog.cr.yp.to&#x2F;20150314-optimizing.html" rel="nofollow">http:&#x2F;&#x2F;blog.cr.yp.to&#x2F;20150314-optimizing.html</a>

This is very good. I&#x27;ve been working towards something similar to what DJB is talking about. (Nice to know I&#x27;m in good company. :)<p>In a nutshell, although automated systems will be good (are already and getting better) there will always be aspects that require humans in the loop (unless and until the machines actually become sentient, defined in this context as gaining that <i>je ne sais quoi</i> that humans do seem to have.)

The cases where optimizing compilers aren&#x27;t good enough are where Java Hotspot Compiler and similar techniques really shines. Combined with novel superoptimization techniques, hotspot optimization could far outperform hand-optimization (although AFAIK that hasn&#x27;t happened in practice yet).

Isn&#x27;t that why people advocates C ? Isn&#x27;t C just that type of language you can tell the compiler how to optimize ?<p>C might not give very explicit information on how to optimize, but isn&#x27;t it simple and bare enough to let the compiler do a better job ?

audio of the talk: <a href="http:&#x2F;&#x2F;cr.yp.to&#x2F;talks&#x2F;2015.04.16&#x2F;audio.ogg" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;talks&#x2F;2015.04.16&#x2F;audio.ogg</a>

What a waste of time.<p>Yes, specialists can squeeze the last performance improvements in ASM compared to C. Doesn&#x27;t mean that -O2&#x2F;-O3, auto-vectorizing can&#x27;t do a nice job and get to 90% of that<p>Optimizing DO matter. Just compare -O0 and -O1. Really. It&#x27;s not because CPUs are fast that people shouldn&#x27;t do that and compilers shouldn&#x27;t optimize a bare minimum.<p>It&#x27;s <i>even better</i> that the compiler do that because ASM optimizing by hand is very error prone.<p>And compilers get better every day. Just look at LLVM.

Room for optimizing compilers = distance between programming languages and CPU instructions&#x2F;microarchitecture

He is soooo spot on! This &quot;dialogue with the compiler&quot; is going to be really big in the next decades, but it&#x27;s in no way a death of automatic optimization, it&#x27;s just the beginning of it.<p>Here&#x27;s a simple example how I expect it to work: You write a code that uses a list-like data structure. The compiler then instruments the code and you run some tests. The tests will then be evaluated and the (post?)compiler selects what kind of data structure is to be used (let&#x27;s make example simple, choices are array vs. list). For instance, if you need to look up elements a lot (based on the evidence from testing), an array will be chosen as the underlying data structure.<p>And you actually get (if you want to see it, normally this information will be hidden) a little box in the IDE, where the variable is used, that tells you: &quot;Here, an array will be used.&quot; You can then with one click say: &quot;I don&#x27;t want array, make it a list.&quot; So for all the possible optimizations, there are two viewpoints presented: The viewpoint of the compiler (based-on evidence from the tests or static analysis) and the viewpoint of the programmer (which allows for confirmation or override in case there are some unknown assumptions).<p>And if the specifications change (say, we chose list earlier but now we have actually a lot of direct access to elements), you can just recompile the same code with the previously-agreed compiler choices removed! And without changing any line of code, a different and more fitting data structure will be used.<p>You can easily see this can apply to many things, not just data structures. You can also see that different ways how the dialogue can be implemented are possible, once we syntactically separate the &quot;what&quot; from the &quot;how&quot; in the programming language. In the future, I believe, we will program just with abstract data types, and the concrete type specification will be selected based on the evidence from the running program (or static analysis augmented with that information). So the dialogue will not happen just with the programmer, but the compiler will also observe the real world behavior of the program and facilitate adaptation to that.<p>In this way, it&#x27;s even possible to input assumptions that doesn&#x27;t have to be provably correct. This approach can potentially bridge the static vs dynamic types divide, and others.<p>Finally, Haskell and functional languages are very nice, but I don&#x27;t think they are final word in programming. If we wanted the above, they have syntactical problems such as mixing of concrete and abstract types (type classes). Also, there are limits to static analysis in the real world. The future will be lot more interesting.

The birth of an optimizing assembler.

I would prefer death to the font-size: 2^1000px

Trying to read this gave me cancer