[Ilugc] Compiled/Interpreted languages

  • From: askgopal@xxxxxxxx (Gopalarathnam V.)
  • Date: Tue, 06 Jan 2004 13:02:32 +0530

Ganesh Swami said the following on 01/06/04 12:25:

"GV" == Gopalarathnam V <askgopal@xxxxxxxx> writes:

    GV> C runtime doesn't interpret the executables, they contain
    GV> implementations of common functions like strcpy(), strcat(),
    GV> etc.  You can easily compile C programs as a static binary
    GV> (gcc -static), which doesn't require any runtime for running,
    GV> but the size purely depends on the functions you've used in
    GV> the program.

Did you actually read my post ? Maybe you missed the "NOT" part. I did
say that static binaries don't require runtime libraries.

Not about static binaries, but the glibc runtime doesn't interpret 
binaries generated by the GNU C compiler.

(offtopic at this point, but my native binaries compiled with GCJ
gives me *HUGE* binaries. A hello world program gives me a SEVEN
MEGABYTE binary. It's obvious that it links the ENTIRE java class
library in.)

    GV> Bytecodes can *never* run faster than native executables (not
    GV> VB ;-)

Yes they can.

A JIT has better understanding of the runtime environment than a
compiler (ahead-of-time) and can therefore better optimize the
generated native code.

Are you trying to say JITs can optimize native executables??   Why 
should native executables be optimized by JIT?  They don't require any 
Just-In-Time support anyway, they're just "interpreted" by the processor.

I came across an excellent paper a while back, but unfortunately can't
remember the source now. STFW-ing with "bytecode faster native java"
throws up a couple of hits.

Note that I'm talking of tight loops (numerical algorithms) that even
an half assed JIT will be equivalent to its compiler (except for the
first iter, which doesn't weigh much).

I generally think that compiler research hasn't had much lime light
as other traditional computing science fields.

GCC 3.2.3 and other later versions code optimizations are comparable 
with Intel compilers now... they do all those branch optimizations, CSE 
optimizations, etc...

I'm not talking about compilers for languages like Java which don't 
generate native executables.

I need to run, so I couldn't read through most of the links, but [0]
tells "...portable way to obtain a Java program that runs faster than
compiled serial C code.", though "serial C code" doesn't help prove
my point much.


[0] http://www.extreme.indiana.edu/hpjava/papers/native/node6.html

Ganesh Swami

If you want to get laid, go to school;
If you want to get educated, go to the library.
       -- Frank Zappa.

<askgopal at sify period com>

#include <std/disclaimer>

Other related posts: