Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!pacbell.com!pacbell!att!cbnewsc!lgm
From: lgm@cbnewsc.att.com (lawrence.g.mayka)
Newsgroups: comp.sw.components
Subject: Re: Need for multiple implementations
Message-ID: <1990Aug3.231110.9388@cbnewsc.att.com>
Date: 3 Aug 90 23:11:10 GMT
References: <82613@tut.cis.ohio-state.edu> <71800006@m.cs.uiuc.edu>
Organization: AT&T Bell Laboratories
Lines: 24

In article <71800006@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu writes:
>In fact, I find that I rarely need a different implementation of these
>basic abstractions.  Smalltalk has very good performance analysis tools,
>so I am easily able to find where the bottlenecks are in my programs.
>There have been a few times where I found that I needed to make a new
>definition of sequence or the almost constant function, so I am not
>saying that it never happens.  I am just saying that it is not nearly
>as big a deal as people make it out to be.

Compiler optimization can also play a major role in discouraging
homegrown implementations of basic abstractions.  For example, Common
Lisp implementations on both conventional and Lisp-directed processors
are typically designed to handle certain popular datatypes (e.g.,
small integers, lists, symbols) with high efficiency yet full safety.
Homegrown equivalents, even if specialized to the immediate problem,
may not actually exhibit better performance (or worse, sacrifice
safety).


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.