Re: Languages of multiple abstaction

fermineutron wrote:


> It is generally the belief that high level languages are slower than
> the low level languages. It seems to me that there are 2 possible
> reasons for it.


Maybe more.


> 1) The abstraction level of HLL is higher, hence the compiler, using
> todays technologies, can not create as clean code as it would from a
> language of lower level of abstraction.


I think this is close, but not exactly. One is that you can still code
at the lower level, and some people still do trying to get faster code.


As an example, since array expressions were added to Fortran, some
people have used them hoping for faster code. Often the result is
slower, sometimes requiring temporary arrays to evaluate.
Sometimes a simple HLL array expression will require much more
computation than a comparable expression coded at a lower level.


> 2) HLL allow the coding process to be easier, hence more inexperienced
> programmers code in HLL than in LLL, this naturally results in the
> poorly optimized code.


Maybe, but even more, less experienced programmers use less efficient
algorithms. Those algorithms, coded in any language, will be
inefficient. Sometimes they also use less efficient constructs of
higher level languages, as you say. But production code is more often
written by more experienced programmers.


> So the question becomes:
> If a code is written in HLL and great care is taken to write the code
> in such a way that the compiler will do as good of a job as it possibly
> can, and then another code with the same care is written in LLL, will
> the code originally written in HLL be that much slower?


A good optimizing compiler is supposed to recognize certain constructs
and generate efficient code for them. Often writing lower level code
will confuse such optimizers. Also, less experienced programmers often
don't understand which generate better code, and so might use less
efficient constructs.


> Naturally the abstraction introduced by syntax of HLL will result in a
> speed penalty, but it seems that it should not be as much as is the
> stereotype of speed comparisons of HLL and LLL.


There are stories about the first Fortran compiler, where its
designers knew they were competing against experienced assembler
programmers. They required a good optimizer in that first compiler.


One of the slower parts of many systems is the conversion routines
necessary for human readable I/O. (Converting between character
representation and internal representation.) Even more is the
graphical user interface of many systems today. It is the convenience
of the user that requires these systems.


> Naturally it is assumed that the code generated from HLL is NOT
> performing any additional tasks then the code generated from LLL at
> runtime, such as array boundary checking etc or array growing, while
> in LLL arrays are 100% preallocated.


> I am curious about the fraction of the speed penalty of HLL which in
> no way can be reduced by more inteligent programing or certain
> compiler swiches.


-- glen

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