[Ilugc] Compiled/Interpreted languages
- From: ganesh@xxxxxxxxxxxxx (Ganesh Swami)
- Date: Mon, 5 Jan 2004 22:55:44 -0800
"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.
(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.
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.
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.
regards,
Ganesh
[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.
Other related posts:
