|Languages of multiple abstaction email@example.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 firstname.lastname@example.org (Gene) (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (glen herrmannsfeldt) (2006-11-01)|
|Re: Languages of multiple abstaction firstname.lastname@example.org (EJP) (2006-11-01)|
|Re: Languages of multiple abstaction DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-11-01)|
|Re: Languages of multiple abstaction email@example.com (2006-11-01)|
|[7 later articles]|
|Date:||29 Oct 2006 09:26:10 -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.
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.
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?
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.
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
Return to the
Search the comp.compilers archives again.