[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Low-level vs. High-level programming (was My First Computer)
In article <Xns939F982D4A0Ewildstar128hotmailco@216.168.3.44>,
wildstar <wildstar128@hotmail.com> wrote:
> When has high-level program actually outperform a well written low-level
> routine. Never has and never can when both system hardware level is the
> same. For one, Java like its predecessor grand-daddy token BASIC. Which
> JAVA calls byte-code is hardly more then tokens in BASIC. So you save
> files as mere tokens and then interpret tokens.
:-) ....not quite. I suggest you read up a little on how compilers
actually works. Converting source text to tokens is merely the very
first step performed by a compiler, and that's of course all a BASIC
interpreter does when you input the BASIC source (or load it in text
form). However, a Java compiler does much more than that: it analyzes
the logic of the code, does a lot of error diagnostics at compile
time. Equivalent errors wouldn't be caught until run time in
interpreted BASIC; some BASIC interpreters have no error diagnostics
at all during tokenization but merely replaces some character
sequences (the reserved words) with tokens; Applesoft Basic worked
like that.
The Java bytecode aren't merely tokens, but much more like machine
code for a virtual CPU: the JVM (Java Virtual Machine).
> There is still an interpretation. Until you can compile to CPU level
> binary,
Using your own logic: "For one, a compiler prodcing native code is
like its predecessor grand-daddy token BASIC. Which you call
machine code is hardly more then tokens in BASIC. So you save files as
mere tokens and then the CPU hardware interpret these tokens."
<evil grin>
Java bytecode is the machine code of a virtual CPU, which in
principle could be realized as a real hardware CPU. So if Java
bytecode is "tokens as in interpreted Basic", then so is native
machine code, because that's interpreted too, by the CPU hardware.
Now, if you want to look at some REAL machine code, then you'll
have to check out the microcode present in ROM's within many
CPU's....
> it is still slower.
That's just because there's no hardware CPU for Java bytecode.
Other kinds of machine code executes slower too, if interpreted.
BTW many JVM's today implement JIT (Just-In-Time) compilation,
which means that the Java bytecode of loops and other parts of
the code which executes frequently actually are translated to
native machine code, as needed, and then that native code is
executed instead. That makes Java bytecode a lot faster than
interpreted BASIC tokens....
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://www.stjarnhimlen.se/
http://home.tiscali.se/pausch/