|Languages of multiple abstaction firstname.lastname@example.org (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 email@example.com (Gene) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (glen herrmannsfeldt) (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (EJP) (2006-11-01)|
|Re: Languages of multiple abstaction DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (Brooks Moses) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (Walter Banks) (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (fermineutron) (2006-11-04)|
|[4 later articles]|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||1 Nov 2006 00:52:20 -0500|
> 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.
> 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
> 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.
Return to the
Search the comp.compilers archives again.