Re: Are these all really true ?

graham.matthews@pell.anu.edu.au writes:
> >* Performance is a language problem.
>
> One of my pet topics! ... Another example is OO computing. Adding OO to a
> language certainly increases the expressiveness of the language, but at
> the cost of performance (the dynamic lookups that go on). The list of
> ways in which semantics effects performance is endless. Hence performance
> is a language problem.


I think this is an example of blaming the language for a design or
implementation mistake.


One of *my* pet topics is that people who blame virtual-function lookups
for performance problems are not comparing apples to apples. If you are
using virtual functions (i.e., dynamic lookup), then you should only do so
if there is something to look up. In other words, if the dynamic lookup is
*always* going to call the same function, why are you using virtual
functions in the first place?


On the other hand, if the dynamic lookup really does call different
functions for different data, then it's not fair to compare the performance
to code that does a statically bound function call. Either the code would
have to contain explicit tests (a switch statement, say) to decide which
function to call, or the called function has to be more complex and make
its own decisions about what operation is desired.


So, it's not the language that is causing the performance problem. It is
either the design, the implementation, or unrealistic expectations (that
is, the expectation that performance will be as good as a (mythical?)
program that solves a much simpler problem).


> >* Compilation is better than interpretation.
>
> What does "better" mean? Compiled code certainly runs quicker than
> interpreted code (the asymptotic lower bound on the speed of interpreted
> code is the "equivalent" compiled code).


Not necessarily. If the language requires a lot of runtime decisions, you
can actually get higher performance if those decisions are centralized in
the interpreter rather than replicated throughout the generated code.
I'm not saying this will *always* be true, but it might be.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

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