Re: HLL design

"Wolfram Fenske" <int2k@gmx.net>
21 Oct 2006 13:57:14 -0400

          From comp.compilers

Related articles
HLL design free4trample@yahoo.com (fermineutron) (2006-10-21)
Re: HLL design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-10-21)
Re: HLL design pjb@informatimago.com (Pascal Bourguignon) (2006-10-21)
Re: HLL design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-10-21)
Re: HLL design int2k@gmx.net (Wolfram Fenske) (2006-10-21)
Re: HLL design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-10-21)
Re: HLL design free4trample@yahoo.com (fermineutron) (2006-10-21)
Re: HLL design danwang74@gmail.com (Daniel C. Wang) (2006-10-24)
Re: HLL design idknow@gmail.com (idknow@gmail.com) (2006-10-24)
Re: HLL design bjarke.walling@gmail.com (Bjarke Walling) (2006-10-24)
Re: HLL design amedlock@gmail.com (DavidM) (2006-10-24)
[2 later articles]
| List of all articles for this month |

From: "Wolfram Fenske" <int2k@gmx.net>
Newsgroups: comp.compilers
Date: 21 Oct 2006 13:57:14 -0400
Organization: Compilers Central
References: 06-10-080
Keywords: design, performance
Posted-Date: 21 Oct 2006 13:57:14 EDT

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


> This is somewhat of a theoretical question for the experts here. Most
> of easy to use languages are too slow for any serious computing while
> the languages like C and assembly are somewhat of a pain to use. The
> key issues that i identyfy as pain include but not limited to,
> variable declaration array boundary checking, strict data types
> etc. Most can be solved by using extended variables that carry key
> information about the data in the variable within the variable, for
> example using the 1st byte to designate the data type of a variable,
> int, float double etc. using second byte to designate the number of
> dimensions in the variable lets say its N, then using N 4-byte
> integers to store dimension sizes, and this header is followed by the
> data itself.
>
> Now my question is:
>
> Assuming that the system that is to work with such variables is
> inteligently designed, do you think it will be significantly slower
> than C? Is there a good reason why there is no "efficient" programming
> language which uses such or simmilar system to store variables?


About the claim that there was no "efficient" programming language
with these features:


OCaml is very fast. Its creators conservatively claim it's at least
50% as fast as a C++ program compiled by a good optimizing compiler,
but usually it's faster than that, in some occasions even faster than
C++. OCaml is a statically typed language but unlike C or Java it
doesn't require you to declare types because it uses type inference
[1]. It also has bounds checking.


Apart from OCaml, I hear that recent Common Lisp and Scheme native
code compilers (e. g. CMUCL, SBCL, Bigloo, Larceny, Allegro, and
Lispworks) produce very fast code. But to get the best performance
you usually have to declare variable types in critical functions,
which I gather you're trying to avoid.


Note that both OCaml and the Lisps support bignums.


As always, YMMV, because the performance of a particular language
depends greatly on the problem you're trying to solve.


Now about the "good reason" why most languages are slower than C part:


Basically, it's like this: to produce efficient code, a language has
to be pretty static, because if more work can be done statically by
the compiler, less work has to be done at runtime. Statically typed
languages like C or OCaml eliminate all type information during
compilation so they have no overhead whatsoever when reading or
writing variables. If OTOH your variables carry type information at
runtime, they are a) bigger and won't fit into a single machine
register like, e. g., an int in C, b) you usually need to dereference
a pointer, and c) an additional offset is needed to access the actual
value.


Another reason why C is so fast is that it doesn't do any safety
checks at runtime. Everything that could possibly require runtime
support or otherwise slow down the programm is "undefined behavior".
E. g. it has no grabage collector. Or when an integer overflow occurs
in a C program, the value just wraps around. In Lisp, OTOH, the
result would automatically be promoted to a bignum, but checking for
overflows after each arithmetic operation is of course much more
costly than the C solution.


> Basically i want a programming language which has the speed and
> flexibility of C, while user friendlenness of MatLab.


You have to find a compromise between speed and user friendliness.
You can't have it both ways. OCaml, because of it's type inference,
is able to produce very fast executables, and usually you get away
with much less lines of code than an equivalent C solution. In my
opinion, it's going to be very hard to beat OCaml if you want the
features you mentioned. But maybe you can beat MatLab, I don't know
how optimized it is, or whether it uses just in time compilation,
etc.. In one discussion, somebody claimed that he had reimplemented
the core of Mathematica in a couple lines of OCaml and it was faster
than the original. [2] But I don't know if there's any truth to it.


> I am thinking about starting a project to write such a language, but
> before i imbark of such a great crusade i want to hear what people who
> are by far more experienced than me have to say about it?
>
> Is it really impossible to design a compiler which translates higher
> level code than C into efficient assembly?


OCaml is much higher level than C, so I'd say it's possible. The
question is how much performance are you willing to sacrifice and how
much time/money/people you have to write and optimize the compiler.




Wolfram


Footnotes:
[1] <http://en.wikipedia.org/wiki/Type_inference>
[2]
<http://groups.google.com/group/comp.lang.functional/tree/browse_frm/thread/fd1b60fb63c230ff/2dea641e3a7d24b5?rnum=44>



Post a followup to this message

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