Fast/Slow langs/implementations (formerly other things)

In article <1990Jun15.033356.2061@esegue.segue.boston.ma.us>, holub@violet.Berkeley.EDU writes:
    ...
|> Though implementation details, of course, control the speed of two
|> compilers that implement the same language, some languages are intrinsicly
|> slower or faster than others. ...


Some language *features* are intrinsicly slower than others; a traveling
salesman solver is going to be slow, whether it's a language primitive or
not. But it is quite possible to create a language which only makes you pay
for the features you use, when you use them. Mr. Holub's comments primarily
deal with these kinds of features:


|> ... Nroff provides a case in point. Nroff lets you assemble a
|> variable name in a string at run time, and then access the variable through
|> that string. ...


So Nroff provides a form of built-in hash tables. This doesn't imply that
normal variable accesses have to go slowly.


|> ... Other examples: LISP usually has to do garbage collection whether
|> or not it's compiled,


This is the one global feature mentioned. Although one can imagine a LISP
system that didn't do any hidden consing, and thus allowed the programmer to
do their own memory management using arrays... :-)


|> ...and all LISP programs are not compilable since LISP
|> code can be self modifying.


Many people claim the ability to redefine, e.g., CONS makes normal LISP code
inherently slow, but this ain't so; it is possible to shift the burden to the
compiler, and make redefining CONS the (terribly) slow feature. More
frequently, LISP systems (and the latest COMMON LISP proposal) simply make it
an error to redefine CONS.


|> ... Nroff and vanilla LISP both have to do loops with
|> recursion...


The compiler can turn loops written with recursion into loops using gotos.
This optimization has been in the literature for at least 10 years.


|> ... C++ takes time to do the indirection
|> implicit in a virtual-function call.


Only if you use virtual-functions. C++ is an excellent example of a language
which only makes you pay for the features you use. By the way, the
``indirection implicit in a virtual-function call'' is trivial compared with
the rest of what goes on around a typical function call interface (it
acquires signficance if one is trying to do inter-procedural optimization,
since it means one doesn't always know at compile time just which function is
being called).


|> Of course, all
|> of the slower languages have features that often make up for the speed trade
|> offs, but if you don't need these features, there's no point in programming
|> in a language that has them.


One might only need the features once in a while. More likely, one might
only need ``fast'' but dangerous features very rarely, in the 10% of the code
that takes up 90% of the run time, and prefer slightly slower and much safer
features in the other 90% of the code. The ability to get at the machine can
be important for some applications, and C is certainly better than Pascal for
writing operating systems; but why not use Modula-2 and get the best of both
worlds? (This is VERY different from putting unsafe optimizations in the
compiler; I'll just condemn that on general principles here, see ``Compiler
Support for Floating-point Computation'', Vol. 18 No. 7 of
Software---Practice and Experience, if you want more details on how compilers
can screw up in a limited domain).


|> As for power, has Mr. Marti ever tried to write an operating system or a
|> compiler in IBM/PC BASIC or in Pascal?


I don't understand the reference to BASIC, although just for the record I
have written a compiler for LOGO in BASIC before (it compiled to byte codes,
which were interpreted). I have also written a (toy) compiler in Pascal, and
it wasn't that traumatic. Modula-2 is certainly an improvement.


To be fair, I doubt a LISP system will ever run as fast as it ``should'';
LISP is simply too big. In that sense, LISP may be inherently slow, although
that is really a software-engineering issue regarding its implementation, not
a problem with the language itself. And as I recall, the original languages
under consideration were C and Pascal, not C vs. NROFF and LISP...


    /charlie <farnum@sequoia.berkeley.edu>
--

Return to the comp.compilers page.
Search the comp.compilers archives again.