Re: Languages of multiple abstaction

fermineutron wrote:


> 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 wouldnt say "clean", but "appropriate".
Appropriate in the sense of taking into account
knowledge about actual details (for example, will
a list have 10 elements or 10 million elements).


> 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.


Inexperienced users would write inappropriate code
in any language they use, not just HLL.


> 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?


On the average, the run-time efficieny may be comparable.
But in real life, it is often the corner cases that make
the difference.


Let me give an example: Some weeks ago, we adopted
a software unit (named Tellar) that had been used
by others successfully for some years on several
platforms. But when _we_ started using it, this same
software turned out to be a nightmare in terms of
CPU time. This software worked perfectly with moderate
amounts of data. But we used it to handle several GB
of data each day in many thousands of files. Under
these circumstances, the "well-proven software package"
failed.


> 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.


After some time of using a convenient HLL, you start
to ignore efficiency considerations while writing.
You tend to ignore the length of a list (10s or millions
of elements). A program written in a LLL is usually
streamlined to the amount of data to be processed.


> 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.


Some years ago, some CPU designer from IBM examined the
amount of inefficiency introduced by HLL (C++) vs. LLL (C, FORTRAN).
I remember these reasons for performance penalties:


1. C++ is about 30% slower than an original C design because
the compiled C++ code is physically allotted/distributed
over the address space. Invoking virtual functions causes
too much jumping around between code chunks


2. The same is true for data. "Objects" in the sense of
object-oriented programming are sprinkled all over the
address space. Today's CPUs lose much of their efficiency
when data is not compact/contiguous. The penalty for this
may easily be a tenfold. Numerical data processed by
FORTRAN routines is traditionally very compactly concentrated
in arrays (and therefore easily processed by cache-prefetch
mechanisms).


3. Assembly-level branch instructions spoil CPU performance as well.
In an LLL, the programmer has a better feeling for the assembly
code that will be produced from a line of code. That's why Linus
Torvalds was stuck so long with the old GCC 2.7 compiler and refused
to switch to newer GCC versions.

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