🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #3195

Re: Dynamic typing -- To Have and Have Not (was Runti

#3195
From: Chris Dollin
Date: Tue, 26 Mar 1991 11:11
42 lines
2980 bytes
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."
Technical Details
Message-ID: <KERS.91Mar26111126@cdollin.hpl.hp.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers
References: <KERS.91Mar19082354@cdollin.hpl.hp.com> <17928:Mar2012:22:5491@kramden.acf.nyu.edu> <KERS.91Mar21121931@cdollin.hpl.hp.com> <16

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <KERS.91Mar26111126@cdollin.hpl.hp.com>
Date: 26 Mar 91 11:11:26 GMT
References: <KERS.91Mar19082354@cdollin.hpl.hp.com> <17928:Mar2012:22:5491@kramden.acf.nyu.edu> <KERS.91Mar21121931@cdollin.hpl.hp.com> <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