Xref: utzoo comp.lang.misc:7075 comp.object:2887 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc,comp.object Subject: Re: Dynamic typing -- To Have and Have Not (was Runti Message-ID: Date: 26 Mar 91 11:11:26 GMT References: <17928:Mar2012:22:5491@kramden.acf.nyu.edu> <16 Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 42 In-Reply-To: brnstnd@kramden.acf.nyu.edu's message of 25 Mar 91 16:17:52 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Dan responds: In article [one of mine] Chris Dollin writes: > OK, but I'm still puzzled as to why you included the option of dearer > compile-time costs at all. Can you illustrate a case where a compiler for a > dynamically-typed language is *slower* than a compiler for a statically typed > language - when the compiler is written in the same language for both (ie, > we're comparing apples and apples)? Many people have spent many years trying to optimize dynamically typed languages (i.e., to get rid of the dynamic typing in the object code), with some success. When a compiler *doesn't* optimize a dynamically typed language, the final code is hellishly slow (as in most Lisps). Sorry, Dan, but this doesn't answer my question - can you tell us about a case where a compiler in language L for a dynamically typed language D was slower than a compiler in L for a statically typed language S, because of the absence of compile-time type-testing? As for ``the final code is hellishly slow'' when the compiler does not attempt to optimise out dynamic typing, what sort of factor are you talking about? 2? 10? 100? [I'm prepared to pay a factor of 2, I'd be reluctant about a factor of 10, and would regard a factor of 100 as dreadful.] As one of my earlier postings remarked, the Pop compiler (written in Pop11, a DTL) compiles Pop code about 5 times faster than an HP-UX ANSI C compiler (written in C, an STL). All other things are grossly unequal, of course, because the C compiler is repeatedly re-reading header files because of separate compilation, and because we are liberal with our use of repeated include files; if all that accounts for a factor of 5 I'd be surprised. I presume you mean that ``optimising out dynamic typing can be slow''. Sure. Optimising compilers can be slow - gcc takes what seems an outlandishly long time compiling one of my modules, because it's a single 800 line procedure. (The Acorn C compiler is even slower on this example.) More will follow when I've time to gather my thoughts ... -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."