From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: What is wrong with OO ? Date: 1997/01/12 Message-ID: #1/1 X-Deja-AN: 209379941 references: <5acjtn$5uj@news3.digex.net> <32D11FD3.41C6@wi.leidenuniv.nl> <32D53473.4DAA423A@eiffel.com> <5b3kpk$2gba@uni.library.ucla.edu> <5b4vuf$24s8@uni.library.ucla.edu> organization: New York University newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-12T00:00:00+00:00 List-Id: Jay said "Here is an even more ignorant question: Why is compilation time still a driving factor? (excluding hardcore optimizations) Obviously it still is as I watched large systems compile lately. But wait, wasn't Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC faster than VC++ on my P5-100. For fun I compiled old programs with vintage a Turbo Pascal Compiler and it seems to compile these suckers instantanously!" Yes, but the quality of code turned out by your "vintage Turbo pascal compiler" is truly horrible. If you don't mind that then fine, it is certainly possible to turn out compilers that compile lousy code fast. It is even possible to make compilers that generate pretty good code locally and are very fast (e.g. Realia COBOL). But almost in the same breath you were talking about intelligent global optimziation, and interunit IGO at that! Global optimization, even at the level of simply worrying about good global register allocation and good scheduling across basic blocks, is non-trivial, and tends to eat up large amounts of computing resources. Furthermore, anything approximating optimal algorithms tends to be super-linear --- at least quadratic sometimes worse -- we know of course that truly optimal code generators are NP complete in time complexity -- but we don't go that far). Still this super-linear behavior means that if you try doing global optimziation across the entire program, you are liable to use very large amounts of computing resources. The MIPS compiler did link time register allocation, and even just doing that resulted in very long link times. Of course this thread is NOT about intellignemt global optimziation, it is about something much more trivial, which is simply doing inlining. I won't comment on the issue of "parroting" BS on inlining in the past, but the fact of the matter is that all compilers today implement inlining, and that was true when Ada 83 was designed. As I have repeatedly pointed out, the pragma Inline of Ada 83 is not about asking the compiler to inline, it is about *permitting* the compiler to establish the body dependency necssary to inline. Doing all possible inlining is certainly not that hard, but it is likely to be time consuming, since it creates a large number of body dependencies. In a million line program, there is a lot of stuff to wade through to find out lots of cases where inlining will NOT work, and I still suspect that the benefits of such unrestricted searching for inlining opportunities are dubious, especially given normal Ada style in which people do write pragma Inlines where there is some possibility of interunit inlining being useful. Note that interunit inlining is not one iota more difficult than intraunit inlining. The issue here is simply one of restricting how much stuff the compiler must look at.