Re: Languages of multiple abstaction

torbenm@app-0.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
1 Nov 2006 00:53:47 -0500

          From comp.compilers

Related articles
Languages of multiple abstaction free4trample@yahoo.com (fermineutron) (2006-10-29)
Re: Languages of multiple abstaction Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-11-01)
Re: Languages of multiple abstaction gene.ressler@gmail.com (Gene) (2006-11-01)
Re: Languages of multiple abstaction gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-11-01)
Re: Languages of multiple abstaction esmond.pitt@bigpond.com (EJP) (2006-11-01)
Re: Languages of multiple abstaction DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-01)
Re: Languages of multiple abstaction torbenm@app-0.diku.dk (2006-11-01)
Re: Languages of multiple abstaction bmoses-nospam@cits1.stanford.edu (Brooks Moses) (2006-11-01)
Re: Languages of multiple abstaction walter@bytecraft.com (Walter Banks) (2006-11-01)
Re: Languages of multiple abstaction free4trample@yahoo.com (fermineutron) (2006-11-04)
Re: Languages of multiple abstaction gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-11-05)
Re: Languages of multiple abstaction gduzan@acm.org (Gary Duzan) (2006-11-05)
Re: Languages of multiple abstaction marcov@stack.nl (Marco van de Voort) (2006-11-08)
[1 later articles]
| List of all articles for this month |

From: torbenm@app-0.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 1 Nov 2006 00:53:47 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 06-10-126
Keywords: design, performance

"fermineutron" <free4trample@yahoo.com> writes:


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


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


The question is a bit more complex than that. Arguably, you can't
beat programming in assembler for speed of execution, since any
compiler for a HLL will compile to assembler (or, equivalently, binary
machine code). LLLs are closer to machine code, so you can expect the
code generated from those to be closer to hand-written machine code
than code written in HLLs. This need, however, not be the case: LLLs
often maintain very weak invariants, so the compiler will have to
assume the worst, e.g., in terms of aliasing, which prohibits certain
optimizations and, hence, makes the generated code unlike hand-written
assembly except for the simple cases where aliasing and such is not an
issue.


HLLs are often designed to maintain strong invariants in the program.
This is most evident in functional languages where the invariant is
that variables will never be overwritten in their life-time, which
makes aliasing mostly moot. Strong invariants also allows complex
code transformations (such as specialisation and finite differencing)
without complex analyses to establish such invariants in code that
does not a priori guarantee these. All of that will allow a compiler
for a HLL to potentially get closer to hand-written assembler than
compilers for LLLs.


But there are other issues: HLLs often advocate programming at higher
levels of abstraction and use of flexible data structures in order to
make programs small and easy to write. But these levels of
abstraction and data structures cost in terms of execution speed, and
not all of that cost (in particular, not the data structure cost) can
be optimized away. So, you often end up comparing a program in a HLL
that uses high-level data structures and abstractions to a program in
a LLL that uses low-level abstractions (if at all) and data structures
(typically arrays). This will give the impression that the LLLs are
faster than the HLLs, while it is usually possible to get equivalent
or even faster speeds from the HLLs if you code using less abstraction
and data structures that are tuned to the specific task -- you still
have the stronger invariants, which helps the compiler. And you still
have the benefit of the high-level abstractions due to the 80:20 rule
(80% of the time is spent in 20% of the code), so you can use the
high-level abstactions and data structures in most of the code.


That said, it is not all HLL structures that strengthen invariants --
OOP and AOP (in their most common forms) actually weaken them.


Torben



Post a followup to this message

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